Skip to main content

​
Why Migrate from Kubernetes?

Kubernetes is powerful but complex. If you’re spending more time managing infrastructure than building features, Monk offers a better way.

​
Common Kubernetes Pain Points

Complexity overload:
  • Steep learning curve
  • Endless YAML files
  • Complex networking (Ingress, Services, Network Policies)
  • Constant troubleshooting
Operational burden:
  • Managing control plane
  • Upgrading clusters
  • Certificate management
  • RBAC configuration
  • Storage provisioning
Developer friction:
  • Developers need K8s knowledge to deploy
  • Long feedback loops
  • Context switching between code and infrastructure
  • Difficult local development
Multi-cloud challenges:
  • Different K8s flavors per cloud (EKS, GKE, AKS)
  • Complex migration between clouds
  • Provider-specific configurations

​
What Monk Offers Instead

  • No Kubernetes — Monk uses its own distributed orchestrator
  • No YAML engineering — Natural language operations
  • Autonomous management — Monk handles operations
  • Multi-cloud native — Deploy anywhere without reconfiguration
  • Developer-friendly — No K8s knowledge required
  • Your infrastructure — BYOI model, you control everything
Monk doesn’t use Kubernetes under the hood. It has its own distributed orchestrator that eliminates K8s complexity while providing the same container orchestration capabilities.→ Does Monk use Kubernetes or Terraform?

​
What Monk Reads from Your K8s Setup

Monk analyzes your Kubernetes configurations to understand your application:

​
Kubernetes Artifacts Monk Understands

Manifest files:
  • Deployments
  • StatefulSets
  • DaemonSets
  • Services (ClusterIP, NodePort, LoadBalancer)
  • Ingress rules
  • ConfigMaps
  • Secrets
  • PersistentVolumeClaims
Helm charts:
  • Chart definitions
  • Values files
  • Dependencies
  • Templates
Kustomize:
  • Base configurations
  • Overlays
  • Patches
Operators:
  • Custom Resource Definitions (CRDs)
  • Operator configurations
Monk uses these files to understand your application, but doesn’t require them. You can give Monk raw source code with no K8s configs, and it figures everything out.

​
Migration Steps

1

Install Monk

Install Monk in VS Code, Cursor, or Windsurf.→ Installation Guide
2

Open Your Application Code

Open your application source code (not just K8s manifests) in your IDE. Monk needs your actual application code to understand and deploy it.
3

Export Configurations

Extract any critical configurations from K8s: - Environment variables from ConfigMaps - Secrets - External service endpoints - Custom settings You’ll provide these to Monk during deployment.
4

Tell Monk to Deploy

Open Monk chat (Cmd+Shift+M): deploy this application to AWS Monk doesn’t need your K8s manifests — it analyzes your code directly.
5

Monk Analyzes Your App

Monk examines: - Source code and dependencies - Dockerfiles (uses or optimizes them) - docker-compose.yml (if present) - Kubernetes configs (for understanding) - Service dependencies
6

Answer Monk's Questions

Monk may ask about: - Deployment preferences (managed vs self-hosted databases) - Replica counts - Resource requirements - External service configurations
7

Provide Cloud Credentials

Give Monk credentials to provision resources. These stay on your machine. → Security
8

Monk Deploys Everything

Monk autonomously: - Containerizes your services (no K8s) - Provisions infrastructure - Deploys and orchestrates containers - Configures networking and load balancing - Sets up monitoring and logging - Wires everything together
9

Test New Deployment

Monk provides URLs to access your application. Test thoroughly while your K8s cluster continues running.
10

Migrate Data

For stateful workloads: - Export data from K8s PersistentVolumes - Import to new Monk-managed storage - Or keep databases on original infrastructure initially → Working with Databases
11

Switch Traffic

Update DNS or load balancer to point to Monk-managed deployment.
12

Decommission K8s Cluster

After confirming everything works, shut down your Kubernetes cluster. Monk never touches it — you’re in control.

​
Kubernetes to Monk Translation

​
What Monk Replaces

Kubernetes ConceptMonk EquivalentHow It Works
DeploymentContainerized serviceMonk orchestrates containers natively
StatefulSetStateful containerMonk handles persistence automatically
ServiceNetworking configAutomatic service discovery
IngressLoad balancerAutomatic routing
ConfigMapEnvironment variablesConfiguration management
SecretSecure secretsEncrypted secret storage
PersistentVolumeClaimStorage volumesAutomatic volume provisioning
HorizontalPodAutoscalerAuto-scalingAutonomous scaling
NamespaceIsolated environmentMulti-environment support
Helm Chart—Not needed, Monk analyzes code
kubectlMonk chatNatural language operations

​
Operations Translation

Kubernetes commands: 
kubectl apply -f deployment.yaml
kubectl scale deployment my-app --replicas=3
kubectl logs deployment/my-app -f
kubectl get pods
kubectl rollout restart deployment/my-app
kubectl port-forward svc/my-app 8080:80
Monk equivalents: 
deploy this application
scale to 3 replicas
show me the logs
show running services
restart the application
access my-app on port 8080
Natural language. No memorization. Monk executes autonomously.

​
Example Migration

​
Your Current K8s Setup

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-server
spec:
  replicas: 3
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api
    spec:
      containers:
        - name: api
          image: myregistry/api:latest
          ports:
            - containerPort: 3000
          env:
            - name: DATABASE_URL
              valueFrom:
                secretKeyRef:
                  name: db-secret
                  key: url

---
apiVersion: v1
kind: Service
metadata:
  name: api-service
spec:
  type: LoadBalancer
  ports:
    - port: 80
      targetPort: 3000
  selector:
    app: api

​
With Monk

You: deploy this application to AWS with 3 replicas

Monk: Analyzing application...
      Found: Node.js API server on port 3000
      Detected: PostgreSQL dependency

      I'll deploy:
      - API server (3 replicas, containerized)
      - Load balancer (port 80 → 3000)
      - PostgreSQL database

      Need DATABASE_URL environment variable. Provide or use managed RDS?

You: use managed RDS

Monk: Provisioning AWS RDS PostgreSQL...
      Deploying API servers (3 replicas)...
      Configuring load balancer...

      ✓ Deployment complete
      URL: https://api.yourapp.com
No YAML. No kubectl. Just conversation.

​
What Gets Better with Monk

​
Simplified Operations

With Kubernetes:
  • Write YAML manifests
  • Apply with kubectl
  • Debug pod failures
  • Manage Ingress controllers
  • Configure service meshes
  • Handle certificate rotation
  • Upgrade clusters
With Monk:
  • Chat with Monk in natural language
  • Monk handles everything autonomously
  • No manual infrastructure management
  • Automatic updates and maintenance
→ Autonomous Operations

​
True Multi-Cloud

With Kubernetes:
  • EKS for AWS (different from GKE, different from AKS)
  • Rewrite ingress controllers per cloud
  • Different storage classes
  • Provider-specific annotations
  • Complex migration process
With Monk:
  • Same experience on any cloud
  • No cloud-specific configuration
  • Migrate with one command: migrate this app to GCP
  • No rewriting required
→ Multi-Cloud Support

​
Developer Friendliness

With Kubernetes:
  • Developers need K8s knowledge
  • Complex local development (minikube, kind)
  • Long feedback loops
  • Difficult troubleshooting
With Monk:
  • Developers use natural language
  • No K8s expertise needed
  • Fast deployments
  • IDE-native troubleshooting

​
Cost Efficiency

Monk advantages:
  • No control plane costs (Monk orchestrator runs on your VMs)
  • Efficient resource usage
  • Real-time cost tracking
  • Easy provider switching for savings

​
Common Kubernetes Migration Questions

​
Do I need to rewrite my Dockerfiles?

No. Monk uses your existing Dockerfiles or generates optimized ones if you don’t have them.

​
What about my Helm charts?

You don’t need them anymore. Monk reads them to understand your app, then deploys directly without Helm.

​
Can I keep some workloads on K8s?

Yes. Migrate incrementally:
  1. Deploy one service with Monk
  2. Connect it to K8s workloads
  3. Migrate more services gradually
  4. Complete when confident

​
What happens to my StatefulSets?

Monk handles stateful workloads automatically. Persistent storage is provisioned as needed.

​
Can I use my existing container images?

Yes. Monk can pull from any registry (Docker Hub, ECR, GCR, ACR, private registries).

​
What about service meshes (Istio, Linkerd)?

Not needed. Monk provides automatic networking and encrypted service-to-service communication.

​
How do I handle custom Operators?

Monk may not support custom operators directly. For specialized workloads, consider:
  • Keeping those on K8s
  • Migrating the rest to Monk
  • Connecting Monk services to K8s operators

​
After Migration

​
What You Get

  • No Kubernetes complexity — Monk’s orchestrator, not K8s
  • Autonomous operations — Chat-based management
  • Multi-cloud freedom — Deploy anywhere
  • Faster deployments — Minutes instead of hours
  • Better developer experience — No K8s knowledge needed
  • Cost transparency — Real-time tracking

​
Next Steps

​
Comparison Table

AspectKubernetesMonk
Learning CurveSteep (weeks to months)Minutes (natural language)
ConfigurationYAML manifestsCode analysis, no config needed
Operationskubectl commandsChat interface
Multi-cloudComplex, provider-specificNative, seamless
DeploymentManual applyAutonomous
ScalingManual or HPAAutonomous
Control PlaneRequires managementRuns on your VMs
CostControl plane + nodesJust your VMs
NetworkingComplex (Ingress, Services)Automatic
StoragePVC + Storage ClassesAutomatic provisioning
CI/CDExternal tools requiredBuilt-in automation
MonitoringPrometheus + Grafana setupBuilt-in

​
Need Help?

Ask Monk directly: 
how do I migrate from Kubernetes?
Monk understands your K8s setup and guides you through migration. Support:

​
Start Migrating

Ready to leave Kubernetes behind?
  1. Install Monk
  2. Open your application code in your IDE
  3. Tell Monk: deploy this application
Monk figures out the rest. No YAML required.