Kubernetes is genuinely good at what it does. It is also a distributed system you now operate in addition to the one you were trying to ship, and that cost is permanent rather than one-off.
The problems it solves well
- Scheduling across many machines. You describe what should run; it decides where. Below roughly a handful of nodes this is a problem you did not have.
- Declarative desired state. The cluster continuously reconciles reality against a manifest in version control.
- Rolling deploys with health gating and automatic rollback, as a built-in rather than a script.
- Service discovery and internal networking for many services that need to find each other.
- A common substrate for many teams, so platform decisions are made once.
The tax
- A new vocabulary and failure surface: ingress, CNI, RBAC, admission controllers, resource limits, evictions.
- Upgrades of the cluster itself, on the provider’s cadence, forever.
- Debugging that now spans the application, the container, the pod, the node and the network policy.
- Cost, both for the control plane on some providers and for the nodes that must exist for the system components themselves.
- An expertise dependency. A cluster with one person who understands it is a single point of failure with a payroll number.
Signals you actually need it
- More than a handful of independently deployable services, maintained by more than one team.
- Genuine variable load where automatic scaling of the workload — not just the machine — is doing real work.
- Multiple environments that must be provably identical.
- Batch and long-running services competing for the same pool of machines.
- A compliance or platform requirement that already mandates it.
Signals you do not
- One application and a database.
- Traffic that is steady, or spiky in a way one larger machine absorbs.
- A team where nobody has operated a cluster before and nobody wants to.
- “It is what serious companies use” — an argument about identity rather than requirements.
What sits between
The gap between a single container host and Kubernetes is well covered:
- Compose on one or two servers with a registry and a reverse proxy.
- A provider’s managed container service, which runs containers without exposing an orchestrator.
- Serverless for event-driven or bursty components.
- A simple deployment pipeline onto instances behind a load balancer, which handles rolling deploys perfectly well.
If you do adopt it, use a managed control plane
Running the control plane yourself adds substantial work and removes none of the above. Every major provider offers a managed option; take it, keep the node pools small at first, and set resource requests and limits from the beginning — omitting them is the most common cause of a cluster that behaves unpredictably under load.
Where to go next
- Containers on a cloud account
- Autoscaling: what it fixes and what it hides
- How to choose a cloud provider
Questions
Frequently asked
Is Kubernetes overkill for a single application?
Generally yes. Its strengths are scheduling across many machines and coordinating many services; with one application and a database it adds a system to operate without solving a problem you have.
Should I run my own Kubernetes control plane?
Rarely. Managed control planes remove a large amount of upgrade and availability work and change nothing about how you use the cluster.
What is the simplest step up from a single container host?
Two hosts behind a load balancer, or a provider's managed container service. Both cover rolling deploys and redundancy without an orchestrator.