Why Are People Moving Away From Kubernetes?

The honeymoon is over.

In 2020, I watched a team of twelve spend six months migrating their Rails monolith to Kubernetes. They wanted "cloud native." They wanted "scalability." What they got was a PagerDuty alert at 3 AM because a node autoscaler misconfigured the VPC CNI plugin.

That's not an edge case. That's the new normal.

I run SIVARO. We build data infrastructure and production AI systems. Every month, I talk to founders and CTOs who are asking the same question: why are people moving away from kubernetes? Not as a rhetorical jab. As a genuine calculation. They're weighing the operational tax against the convenience. And more of them are pulling the lever toward "get this thing off my cluster."

Let me show you what I've seen.

The Collapse of the "One Platform" Promise

Kubernetes sold us a vision: one control plane to rule all workloads. Stateless APIs, batch jobs, stateful databases, even VM workloads via KubeVirt. All managed with the same YAML, same RBAC, same API.

Here's what actually happened.

Most teams I work with run Kubernetes for one primary workload — usually a stateless HTTP service. Maybe some background workers. That's it. Everything else requires contortions.

Stateful workloads are still painful. Running PostgreSQL on Kubernetes requires operators like CloudNativePG or Zalando's operator. They work, but they add a layer of complexity that most small teams can't absorb. I've seen teams burn two weeks debugging a PVC that wouldn't detach from a crashed node. Two weeks. For storage.

We're leaving Kubernetes - Ona documented this exactly. They ran Kubernetes for years. Then they asked: "What are we actually getting from this?" Their answer was "not enough." They moved to simpler infrastructure. They're not alone.

The Complexity Tax Is Real

Let me give you a concrete number.

A well-tuned Kubernetes cluster requires at least 14 control plane components. That's not counting the CNI plugin, the CSI driver, the ingress controller, the service mesh sidecar, the metrics exporter, the logging agent, and the alert manager.

Each component has its own failure modes, its own upgrade cadence, its own configuration quirks.

I visited a startup in Bangalore last year. Their entire platform was Kubernetes. The CTO told me their DevOps team of three spent 60% of their time just keeping the cluster alive. Not shipping features. Not improving developer experience. Keeping etcd from crashing during leader elections.

Why People Hate Kubernetes captures this tension perfectly. The article argues that Kubernetes haters aren't wrong — they're just frustrated with a tool that solves problems most of them don't have.

The Overhead-to-Value Ratio Most Teams Get Wrong

Here's the uncomfortable truth. Kubernetes makes sense if:

You have >50 microservices
You need multi-region failover
You run workloads with unpredictable scaling patterns
You have a dedicated platform team of at least 3-5 people

If you don't check those boxes, Kubernetes is probably a net negative.

I talked to a founder at a YC company in 2023. They had 8 engineers. 4 microservices. They deployed Kubernetes because "it's what everyone does." Their deployment pipeline went from a 15-minute Heroku push to a 3-hour ordeal involving Helm charts, ArgoCD sync policies, and a GitOps workflow that broke every other week.

They migrated back to a single VM with Docker Compose. Deployment time: 2 minutes. Cost: $40/month.

I Didn't Need Kubernetes, and You Probably Don't Either is a Hacker News thread that became a confessional. One comment summed it up: "Kubernetes is the most expensive way to run a hobby project."

Where Kubernetes Actually Fails

I've identified four specific failure modes where Kubernetes stops being useful and starts being a liability.

1. Stateful Workloads

Databases on Kubernetes work. But they work the same way that riding a unicycle to work works. It's possible. It's impressive. It's rarely the right choice for getting to the office on time.

Running MySQL or PostgreSQL on Kubernetes means dealing with:

Backup and recovery through a separate operator
Storage provisioning that varies wildly between cloud providers
Network latency introduced by the CNI layer
Upgrade procedures that can take down your database

Reddit's Kubernetes thread had a top comment that said straight: "Don't put your database on Kubernetes unless you have a dedicated team that understands both Kubernetes and databases deeply."

2. CI/CD Pipelines

I see teams running their CI/CD on Kubernetes. Build agents, test runners, all inside the cluster.

You know what happens when the cluster goes down? The CI/CD goes down. And now you can't deploy a fix because the deployment system is part of the failure.

It's circular dependency hell.

3. Developer Experience

Every Kubernetes cluster I've audited has a bottleneck: the person who knows kustomize. Or Flux. Or ArgoCD. Or whatever flavor-of-the-month tooling the team chose.

That person goes on vacation. No one else can fix a broken Helm values file. Deployments stall. Tempers flare.

Kubernetes introduces a learning curve that doesn't pay back dividends until you're operating at serious scale. For most teams, it's a tax on every developer who wants to ship code.

4. Cost

Running Kubernetes adds a 20-40% overhead to your cloud bill just from the control plane nodes, tooling infrastructure, and operational waste (orphaned PVCs, over-provisioned node pools, misconfigured HPA).

One AWS user showed me their bill. They were paying $800/month for three m5.large instances just to run the control plane on EKS. That's before any application workload.

When Does Kubernetes Make Sense?

I'm not anti-Kubernetes. I'm anti-wrong-tool-for-the-job.

Kubernetes excels at:

Multi-tenant platforms where you need strong isolation between workloads
Heterogeneous workloads running everything from batch ML training to real-time APIs
Teams with platform engineering resources who can absorb the complexity
Organizations at scale — think 200+ microservices across multiple regions

What is Kubernetes? describes it as "production-grade container orchestration." That's accurate. It's production-grade. It's also factory-grade. It requires a factory floor, not a garage.

What is Kubernetes? by Red Hat emphasizes the declarative configuration approach. That's the secret sauce. If you need to declare infrastructure as code and let the system converge toward that state, Kubernetes is unmatched.

But most teams don't need that. They need a Docker Compose file that just works.

The Alternatives People Are Choosing

I'm seeing a clear pattern in 2024. Teams aren't abandoning containers. They're abandoning the orchestration layer.

Option 1: Plain VMs with Docker Compose

This is the most common migration path I see. Teams move from Kubernetes to a single VM (or a handful of VMs) running Docker Compose.

Pros:

10x simpler
No control plane to manage
Anyone on the team can understand it
Costs less

Cons:

No built-in autoscaling
No self-healing
No rolling deployments without extra tooling

For teams with fewer than 5 microservices and <10K requests/second, this is almost always the right call.

Option 2: Serverless Containers (AWS Fargate, Google Cloud Run)

I'm seeing a lot of adoption here. Cloud Run in particular handles scaling, networking, and deployments without exposing the control plane.

Do You Actually NEED Kubernetes? breaks this down well. The video argues that most teams should start with serverless containers and only migrate to Kubernetes when they hit specific constraints (like GPU workloads or strict latency requirements).

Option 3: Managed Kubernetes with Abstraction Layers

Some teams stay on Kubernetes but wrap it in an internal platform. They build a PaaS on top of K8s using tools like:

Railpack — for zero-config deploys
Kratix — for internal developer platforms
Waypoint — for consistent deployment workflows

This approach keeps Kubernetes underneath but hides it from developers. The platform team absorbs the complexity. The feature teams ship code.

How to Know if You Should Stay or Go

Here's a decision framework I use with clients. Answer these questions honestly.

How many microservices do you run?
<10: Probably don't need Kubernetes.
10-50: Maybe, depending on other factors.
50+: Kubernetes starts to make sense.
Do you have a dedicated platform/DevOps team?
No: Don't use Kubernetes.
Yes, 1-2 people: You'll struggle.
Yes, 3+ people: You can make it work.
What's your deployment frequency?
Few times a week: Kubernetes is overkill.
Multiple times daily: Kubernetes helps.
Do you need multi-region or multi-cloud?
No: Simplified solutions work.
Yes: Kubernetes is one of the few viable options.
What's your team's Kubernetes expertise?
Beginners: Don't start with Kubernetes.
Intermediate: You'll be slow but functional.
Expert: You know already.

My Take

I think the pendulum is swinging back.

For the last five years, Kubernetes was the default answer. "How do we deploy this?" "Kubernetes." That was the conversation. It wasn't a decision. It was an assumption.

Now teams are asking harder questions. Why are people moving away from kubernetes? Because they realized they were paying platform-scale costs for application-scale problems.

Kubernetes Overview is honest about what it is — "a portable, extensible, open source platform for managing containerized workloads and services." Notice what it doesn't say. It doesn't say "simple." It doesn't say "for every team."

The teams that are moving away aren't failing. They're optimizing. They're realizing that operational complexity is a liability, and they're choosing to carry less debt.

Some will come back to Kubernetes when they grow. Some won't. That's fine.

FAQ

Is Kubernetes dying?

No. Kubernetes is not dying. It's becoming more focused. The hype cycle is cooling down, and teams are making more rational decisions about when to use it. The technology is solid. The overuse was the problem.

What's the biggest reason teams leave Kubernetes?

Operational complexity. Most teams can't justify the time and cost of maintaining a Kubernetes cluster when simpler alternatives exist. The complexity tax eats into feature development.

Can you run stateful workloads on Kubernetes?

Yes, but it's harder than stateless workloads. Tools like StatefulSets, Operators, and CSI drivers make it possible, but each database (PostgreSQL, MySQL, Redis) has its own quirks and failure modes.

Should I use Kubernetes for a small startup?

Probably not. Start with a single VM, Docker Compose, or serverless containers. Add Kubernetes only when you hit specific scaling or multi-service orchestration problems.

What's a good alternative to Kubernetes?

For small deployments: Docker Compose. For serverless: Google Cloud Run, AWS Fargate. For platform engineering: Nomad by HashiCorp, or a managed Kubernetes service with a PaaS abstraction on top.

When does Kubernetes become worth it?

When you have multiple teams deploying multiple services in a multi-region environment, and you need consistent deployment, scaling, and networking policies. Usually >50 microservices and a dedicated platform team.

Is Kubernetes too complex for most teams?

Yes. The learning curve is steep, the failure modes are many, and the operational overhead is real. Only use it if you have the team and the need.

Nishaant Dixit — Founder of SIVARO. Building data infrastructure and production AI systems since 2018. Built systems processing 200K events/sec.