Why Are People Moving Away From Kubernetes?
We were six months into a Kubernetes migration when I realized we'd built a distributed systems problem to solve a deployment problem.
The team was proud. We had a custom operator. A service mesh. Three different CRDs. And the application? Still a monolith serving 2,000 requests per minute.
I'm Nishaant Dixit. I run SIVARO, a product engineering company that builds data infrastructure and production AI systems. We've deployed Kubernetes in anger. We've also pulled it out of stacks. And I've watched a genuine shift happen across the industry: people are moving away from Kubernetes.
Not because Kubernetes is bad. Because the cost of admission exceeds the value for most teams.
Let me show you what I mean.
What Does Kubernetes Actually Do?
Before we talk about why people leave, let's get clear on the thing itself.
Kubernetes (Overview) is a container orchestration platform. It schedules containers across machines, handles networking, manages storage, and tries to keep your application running when things break.
Red Hat defines it as "a portable, extensible, open-source platform for managing containerized workloads and services." Google calls it "an open-source platform for automating deployment, scaling, and management of containerized applications" (Google Cloud).
Practical translation: you give it a YAML file describing your app, and it makes sure that app runs somewhere, restarts if it crashes, and scales if you tell it to.
What exactly is kubernetes used for? At scale: running microservices, batch jobs, CI/CD pipelines, and stateful workloads that need to move between machines. At small scale: impressing investors during technical interviews.
Here's the problem most people discover too late: Kubernetes doesn't solve your actual problems. It creates new ones.
The Real Cost Nobody Talks About
I was on a call last week with a startup founder. They run 8 microservices on a 5-node cluster. They have three people managing it. Two of them spend 60%% of their time on the cluster, not the product.
"If we just used Heroku," he said, "we'd be shipping daily."
He's right.
A 2023 survey by the Cloud Native Computing Foundation found that 45%% of organizations cited "complexity" as their biggest challenge with Kubernetes. But here's what that number hides: complexity isn't just a learning curve. It's a tax you pay every single day.
The tax shows up in:
- Time spent debugging networking (why won't this ingress route correctly?)
- Storage management (why did my PVC get stuck in "Pending"?)
- Version upgrades (we're still on v1.24 because upgrading breaks everything)
- RBAC configuration (why can't the CI pipeline deploy to production?)
One team at a mid-sized SaaS company I know spends four weeks per year upgrading Kubernetes versions. Four weeks. That's two sprints. For what? So they can keep their existing setup running.
This is why you see posts like "I Didn't Need Kubernetes, and You Probably Don't Either" on Hacker News with hundreds of upvotes. It resonates because people feel the pain.
The Migration That Cost More Than The Product
Ona, a company that builds data tools for global health, published their story about leaving Kubernetes (We're leaving Kubernetes). They had a team of 20 engineers. They spent months migrating to Kubernetes.
Then they left.
Their reason? "Our application doesn't have high traffic. It doesn't need to scale quickly. We were paying the complexity tax for features we never used."
I've seen this pattern repeat at least a dozen times. Companies adopt Kubernetes because:
- It's the "industry standard"
- They're planning for future scale
- Their cloud bill is high and they think Kubernetes will fix it
None of these are good reasons.
Why are people moving away from kubernetes? Because they adopted it for reasons that had nothing to do with their actual needs.
What's Replacing Kubernetes?
The alternatives fall into three buckets:
1. Serverless (Lambda, Cloud Run, Fly.io)
Teams realize they don't need to manage servers at all. Just deploy a container. The platform handles scaling.
2. PaaS (Heroku, Railway, Render)
Same abstraction level as Kubernetes, but someone else does the operations. You give them code. They give you a URL.
3. Simplified orchestration (Nomad, Docker Compose on VMs)
HashiCorp's Nomad is the most honest alternative: it does what Kubernetes does for 20%% of the complexity. Docker Compose on a single VM handles 90%% of use cases.
I ran a comparison for a client last year:
| Setup | Monthly cost | Team overhead | Deployment time |
|---|---|---|---|
| 5-node K8s cluster | $1,200/mo | 1.5 FTE | 30 min |
| Docker Compose on VM | $300/mo | 0.2 FTE | 2 min |
| Cloud Run | $400/mo | 0.1 FTE | 30 sec |
The Docker Compose setup was faster, cheaper, and easier to debug. The Kubernetes setup had more "enterprise features." Neither mattered because the app served 500 requests per second max.
The CI/CD Question Nobody Asks
Here's something weird: people often ask is kubernetes ci or cd? And the answer is "neither, but you'll need both."
Kubernetes is a runtime platform. CI/CD is a separate concern. But Kubernetes adoption creates a trap: you need CI/CD to deploy to Kubernetes effectively, and you need to manage that too.
Teams end up running:
- A CI system (GitHub Actions, GitLab CI)
- A CD system (ArgoCD, Flux)
- A container registry (Docker Hub, ECR)
- Image building pipelines
- Helm chart repositories
- Secret management systems
All of this is overhead. All of it has to be maintained. And every time your CI pipeline breaks, your deployments stop.
At one point we had a client where the CI/CD pipeline for their K8s cluster failed because a Helm chart had a breaking change. Three days of debugging. Three days of no deployments. The actual application code had changed by 2 lines.
When Kubernetes Actually Makes Sense
Let me be clear: Kubernetes is not bad. It's just oversold.
Kubernetes makes sense when:
- You run 50+ microservices
- You have a dedicated platform team (not "the DevOps guy")
- Your traffic patterns are unpredictable
- You need multi-cloud or hybrid-cloud deployment
- You're running at Google/Facebook scale
What is Kubernetes? originally designed for exactly these scenarios. Google built Borg, then open-sourced Kubernetes, to solve problems Google had.
Google's problems are not your problems.
I've worked with a company running 200 microservices across 3 cloud providers. Kubernetes saves them money and time. They have 8 platform engineers. The ROI is clear.
But that's the exception, not the rule.
The Hidden Cost: Tooling Explosion
When you adopt Kubernetes, you don't just adopt Kubernetes. You adopt an ecosystem.
- Networking: Calico, Cilium, or Flannel?
- Ingress: NGINX, Traefik, or Istio?
- Monitoring: Prometheus, Grafana, and alertmanager
- Logging: ELK stack or Loki?
- Storage: CSI drivers, persistent volumes, storage classes
- Service mesh: Istio, Linkerd, or Consul Connect?
- Secrets: Vault, External Secrets, or Sealed Secrets?
- CD: ArgoCD or Flux?
Each tool has its own configuration language. Its own upgrade cycle. Its own failure modes.
A team at a company called Resend wrote about their migration away from Kubernetes. Their team of 5 was spending more time managing the tooling than building features.
I've seen teams with 3-person engineering orgs running:
- 4-node cluster
- ArgoCD
- Prometheus + Grafana
- ELK stack
- NGINX ingress with cert-manager
- HashiCorp Vault
That's 6+ major systems. For 3 engineers. To run a CRUD app.
The HN thread on leaving Kubernetes has a comment I keep thinking about: "We spent 6 months building our platform on Kubernetes. Then we spent 6 months maintaining it. Then we spent 3 months migrating off it."
The Simpler Path
For most teams, the better approach is:
- Start simple: Deploy to a single VM with Docker Compose
- Add complexity only when it hurts: Need horizontal scaling? Add a load balancer. Need zero-downtime deploys? Add a second VM.
- Choose managed services: Use Cloud Run, Fly.io, or Render before considering self-hosted Kubernetes
- Skip the service mesh: You probably don't need it. Seriously. Most teams don't.
- Batch jobs? Use AWS Batch or Google Cloud Batch: Don't build a CronJob infrastructure
I built systems that process 200K events per second. One of them runs on a single beefy VM with Docker Compose. It handles spikes fine. The other runs on Kubernetes because it needs to scale across regions.
The difference? I measured before I chose.
FAQ
Is Kubernetes dying?
No. Kubernetes is growing in enterprise adoption. But the rate of new teams adopting it is slowing as alternatives mature. The "SMB Kubernetes" wave is receding.
What exactly is kubernetes used for in production?
Running containerized applications at scale. Common uses include microservice deployments, scheduled batch jobs (CronJobs), CI/CD worker pools, and stateful applications like databases when you need portability across infrastructure.
Why are people moving away from kubernetes?
Three reasons: complexity cost exceeds operational value, simpler alternatives (serverless, PaaS) have matured, and teams realize they don't need the scaling Kubernetes provides.
Is kubernetes ci or cd?
Neither. It's a container orchestration platform. CI/CD pipelines deploy to Kubernetes. The question itself reveals a common confusion — people lump deployment target with deployment process.
What does kubernetes actually do better than alternatives?
Multi-cloud portability (same YAML works on GKE, EKS, AKS), auto-scaling for unpredictable traffic, self-healing (auto-restarts failed pods), and running 50+ services on shared infrastructure with resource constraints.
Can I run Kubernetes with 2 people?
You can. You'll spend 70%% of your time managing it. If you have a product to build, you probably shouldn't.
What replaces Kubernetes for small teams?
Cloud Run (GCP), Fly.io, Railway, Render, or just Docker Compose on a VPS with automated deploys. All handle the same use case with 90%% less operational cost.
When should I absolutely not use Kubernetes?
When you have less than 10 services, when your traffic is predictable, when you don't have a dedicated platform person, and when your deploy frequency is weekly or less.
My Take
Five years ago, I would have told you to adopt Kubernetes. It was the future. It was scaling. It was how the big companies did it.
I was wrong.
Not about Kubernetes being powerful. About the tradeoffs being worth it for everyone.
The industry is swinging back toward simplicity. Teams are realizing that operational excellence isn't measured in CRDs and operators. It's measured in shipping velocity and uptime. If Kubernetes helps you ship faster, use it. If it slows you down — and it does for most teams — run.
We're seeing the same pattern we saw with monoliths vs microservices. The pendulum swung too far toward distributed everything. Now it's coming back to center.
Build what you need. Nothing more.
Nishaant Dixit — Founder of SIVARO. Building data infrastructure and production AI systems since 2018. Built systems processing 200K events/sec.