Kubernetes is justified once you have multiple services that need to scale independently, a team large enough to dedicate someone to cluster operations, and workloads with real, variable load. Below that line, a managed container service or a single well-sized VM does the same job with less to operate and fewer people required to keep it running. The tell isn't your growth ambitions — it's whether the operational problems Kubernetes solves are ones you actually have today.
What Kubernetes Is Actually For
Kubernetes earns its keep when you have enough moving parts that manual coordination breaks down. Three signals matter more than any others:
- Independent scaling needs. You have a checkout service that spikes at 50x normal traffic during a sale while your admin dashboard sits flat. Running them on the same fixed infrastructure means over-provisioning one or starving the other.
- A team that can own it. Someone has to be responsible for the cluster itself, not just the apps on it. That's realistic once you have a platform or DevOps function of at least two or three engineers — one person going on vacation shouldn't mean nobody can safely apply a security patch.
- Load that's genuinely unpredictable. Not "we might grow," but traffic that actually swings by the hour or day in ways a fixed number of servers can't absorb efficiently.
If you have ten or more services, each with different scaling profiles, deployed by different teams, Kubernetes gives you a consistent way to schedule, network, and roll out all of them without hand-building that consistency yourself. That consistency is the actual product. Autoscaling, self-healing, and rolling deployments are useful, but you can get versions of all three from a managed platform without running Kubernetes at all.
When It's Overkill
Most companies evaluating Kubernetes are not in the situation above. A team running four or five services with predictable daily traffic doesn't have a scheduling problem — it has a deployment problem, and that's a much smaller thing to solve. A single VM sized for peak load, or a managed container platform like AWS App Runner, Google Cloud Run, or Azure Container Apps, handles that case with a fraction of the configuration.
The practical difference shows up immediately in what you have to write and maintain. A Cloud Run service goes from a Dockerfile to a running URL with one deploy command and no YAML beyond a build config. The equivalent Kubernetes setup needs a Deployment manifest, a Service, an Ingress or Gateway resource, resource requests and limits tuned by hand, a Horizontal Pod Autoscaler if you want real autoscaling, and network policies if you care about pod-to-pod traffic rules. None of that is wrong to build. It's just work that a five-person engineering team doing predictable traffic doesn't get anything back for.
The Ongoing Cost Nobody Puts in the Proposal
The sales pitch for Kubernetes stops at "it's the industry standard." What it leaves out is that adopting it means adopting a second job: running Kubernetes itself.
- Upgrades. Kubernetes ships a new minor version roughly every four months, and each one deprecates old APIs on a fixed timeline. Falling two versions behind turns a routine upgrade into a multi-week project of rewriting manifests and testing for breakage.
- Security patching. The control plane, the node OS, the container runtime, and every add-on (ingress controller, service mesh, cert manager) all need patching on their own schedules. Managed Kubernetes offerings handle the control plane; nodes and add-ons are still yours.
- Debugging the orchestration layer. When a pod won't schedule, or DNS resolution inside the cluster is flaky, or a rolling deployment hangs, the cause is often in the orchestration layer itself, not your application code. That's a distinct skill from application debugging, and it takes real time to build.
This isn't a one-time setup cost. It's a standing headcount cost, whether that's a dedicated platform engineer or a slice of your best backend engineer's week, indefinitely.
Two Teams, Two Outcomes
A 12-person startup we worked with adopted Kubernetes at launch because it was the default recommendation from a contractor. They ran three services. Six months in, no one on the team could explain why pods were being evicted under moderate load, and the one engineer who understood the Helm charts became a bottleneck for every deploy. They migrated to Cloud Run over two weeks and cut their deploy time from 40 minutes to under 5, with nobody dedicated to infrastructure anymore.
A logistics company we worked with had the opposite profile: 14 backend services, a platform team of four, and routing traffic that varies by time zone and shipping season, with peak load 8x the daily average. Kubernetes let them scale each service independently and roll out updates to one region without touching another. Moving to a simpler platform would have meant rebuilding, by hand, most of what Kubernetes already gave them for free.
How to Decide
Count your services, count your infrastructure headcount, and look at your actual traffic pattern over the last quarter — not the one you're planning for. If you can't name two services with genuinely different scaling needs, or you don't have anyone whose job includes owning the cluster, start simpler. You can move to Kubernetes later, once the problems it solves are ones you're actually running into, rather than ones you're anticipating.