The Day Kubernetes Was the Wrong Tool
· Sourabh G Kulkarni
Kubernetes is not the default answer. Here is when a single container or a VM is enough, and when a cluster is actually worth the operational cost.
Kubernetes is a good tool for a specific problem: many services, frequent deploys, and a real need to reschedule work when a machine dies. It is a poor default for everything else. I have run clusters on managed Kubernetes and on machines we operated ourselves. I have also watched a single API, used by one team, inherit the operational cost of a platform it did not need.
This is about when not to use Kubernetes. If you are deciding between a cluster and a simpler runtime, the expensive mistake is adopting the cluster because it looks like the grown-up choice.
The moment a cluster was more work than the app
The application was one service. It had a health check, a database, and a deploy every few days. What it gained from Kubernetes was a Deployment, a Service, an Ingress, a certificate issuer, resource requests we had to keep tuning, and a list of controllers to upgrade.
What it lost was an afternoon every time the cluster itself needed attention. The product did not fail over between regions. It did not autoscale across dozens of replicas. The Kubernetes operational cost was real. The benefit was mostly the feeling that we were doing it properly.
That is Kubernetes overkill. The app would have been healthier on a smaller runtime with a boring rollback.
What Kubernetes is good at
Use a cluster when several of these are true:
- You have many services, and they need a shared way to roll out and roll back.
- You deploy often enough that hand-operated VMs are the bottleneck.
- A node can die and the workload must come back without someone SSHing in.
- You already have, or are willing to hire, people who will own upgrades, policy, and the add-ons.
In that world, Kubernetes vs Docker is the wrong framing. Docker builds and runs the container. Kubernetes schedules those containers across machines and gives you a control loop. You want the control loop when the number of machines and services makes the loop cheaper than scripts.
A paved way to ship those services is a separate decision. I wrote about that in golden paths without the buzzwords. A cluster with no path is just a more complicated place to put one-off YAML.
What it costs even when the app is small
A small cluster still has a control plane, node upgrades, etcd or the managed equivalent, ingress, DNS, certificates, and storage classes. Managed Kubernetes removes some of that and leaves the rest. You still own the manifests, the requests and limits, the network policy you meant to write, and the version skew between the cluster and the tools in CI.
Do I need Kubernetes is a cost question, not a prestige question. If the people who can fix a bad rollout are the same two who are building the product, the cluster is competing with the product for their time.
A simple rule
One service and one server does not need a cluster.
If you cannot name the failure that a second node would absorb, you do not need the second node yet. If you cannot name a second service that must share the same deploy mechanism, you do not need a scheduler for a fleet. Put the container on a VM or run it with Compose. Spend the saved time on backups, a real health check, and a rollback you have practiced.
What to run instead
| Situation | A better default |
|---|---|
| One service, one machine | A VM with Docker, or Docker Compose |
| A few services, still one box | Compose with a reverse proxy and automated deploys |
| You want less OS patching, not a platform | A managed container service that runs a single image |
| Many services, real failover, a team to own it | Kubernetes, managed if you can |
Single VPS vs Kubernetes is an easy comparison when the traffic fits on one machine. The VPS loses when that machine is a single point of failure you cannot tolerate, or when the deploy process has become a pile of shell scripts nobody wants to change. Until then, the VPS is the smaller blast radius.
Image size still matters on that VPS. A 1 GB image is slow to pull whether a kubelet or docker compose is doing it. The notes in why your Docker image is 1 GB apply before you ever write a Deployment.
The signals that you have outgrown the simple setup
Move toward a cluster when the simple setup is the constraint:
- Deploys collide because too many services share one hand-built host.
- You need to move work off a sick node without a maintenance window.
- The same YAML or Compose file has been copied so many times that fixes do not propagate.
- You have someone whose job is the platform, not a product engineer borrowing nights to upgrade it.
Those are reasons. "The job posting mentioned Kubernetes" is not.
Keep the door open
Choosing not to use Kubernetes this year is not a permanent identity. It is a decision you can reverse when the workload earns it. Write down what would change your mind: a second region, a service count, an on-call load. When those show up, adopt the cluster on purpose.
Until then, run the smallest thing that deploys, rolls back, and lets you sleep. A cluster can be that thing. A lot of the time, it is not.