Containers package an application with its dependencies so it runs the same everywhere. Orchestration is what you need once you have more than a handful of them: something that decides where each container runs, restarts it when it dies, and routes traffic to it.
Kubernetes is the dominant orchestrator and is frequently adopted by teams who would be better served by something simpler. This is an attempt at an honest comparison.
What orchestration actually does
Five jobs, which is a useful checklist when evaluating alternatives.
- Scheduling. Deciding which machine runs which container, based on resource requirements and constraints.
- Self-healing. Restarting failed containers and replacing failed machines.
- Scaling. Adding and removing instances based on load.
- Service discovery and load balancing. Letting containers find each other as they move.
- Rolling updates. Replacing one version with another without downtime, and rolling back when it goes wrong.
If you need all five, you need an orchestrator. If you need two of them, you may not.
When Kubernetes is justified
Several conditions, and the case is strongest when most apply.
You run many services — at least a dozen — with varied resource profiles. You have engineers who will own the platform as part of their actual job. Workloads are genuinely variable, so bin-packing across a cluster saves real money. You need portability across environments for a concrete reason. Or your team already knows Kubernetes well, which is a perfectly good reason on its own.
When it is not
A single application with a web tier and a database. A team of fewer than ten engineers with no platform specialist. Workloads that are steady and predictable. Any situation where “we might need it later” is the main argument.
The cost of adopting Kubernetes prematurely is not the licence — it is free — but the operational attention it takes from a team that has other problems.
The simpler alternatives
Managed container services. The cloud providers all offer a service that runs containers without exposing a cluster: you define a task, it runs, it scales, it heals. This covers the five jobs above for most workloads at a fraction of the operational cost.
Platform-as-a-service. Push code, get a running service with TLS, scaling and logging included. Excellent until you need something the platform does not offer, at which point migration is a real project.
Serverless functions. Good for event-driven and spiky work. Constraints around execution duration, cold starts and local testing make them a poor fit for everything.
Virtual machines with a process manager. Unfashionable and perfectly adequate for a stable application with modest scaling needs. Many profitable software businesses run this way.
What running Kubernetes actually costs
Even with a managed control plane, the cluster is yours to operate.
Upgrades. Versions reach end of support roughly annually. Each upgrade needs planning, testing and often manifest changes for deprecated APIs. This is recurring work, not a one-off.
Networking. Ingress controllers, network policies, DNS and service meshes are where most of the hard-to-diagnose problems live.
Storage. Persistent volumes are the most common source of production surprises for teams new to the platform.
Access control. The permission model is powerful and easy to configure badly, and default configurations are frequently more permissive than teams realise.
Ecosystem churn. Add-ons for ingress, certificates, secrets, monitoring and autoscaling each have their own release cycles and breaking changes.
A reasonable estimate for a production cluster is half to one full-time engineer’s attention once it is established, more during adoption.
If you do adopt it
Four decisions that save a lot of trouble.
- Use a managed control plane. Running the control plane yourself is a specialist undertaking with no business benefit for most organisations.
- Keep the add-on list short. Each one is a dependency to upgrade and a thing that can break. Start with ingress, certificates and monitoring.
- Define everything declaratively from the start, in version control, applied by a pipeline. Clusters configured by hand become unreproducible quickly. See infrastructure as code.
- Set resource requests and limits on everything. Without them, scheduling is guesswork and one misbehaving pod can destabilise a node.
The honest middle path
For most teams below about thirty engineers, the sensible progression is: containers for packaging, a managed container service for running them, and Kubernetes only when a specific limitation of that service becomes a real constraint.
This keeps the main benefit of containers — consistent packaging and deployment — without the platform overhead. Moving to Kubernetes later is a migration, but a tractable one, because the containers themselves do not change.
Teams that skip this step often spend their first year operating a platform instead of building a product, which is a poor trade when the product is the thing that is not yet proven.
The questions to answer before adopting
A short checklist that tends to settle the argument honestly.
- Who owns the cluster? A named person or team with it in their objectives. “Everyone” means nobody, and upgrades will not happen.
- What specific problem does it solve that the simpler option does not? Written down, concretely. If the answer is about future flexibility, that is not a current problem.
- What happens at 3am? Can the person on call diagnose a pod stuck pending, or a failing readiness probe? If not, the platform has made incidents longer, not shorter.
- What is the upgrade plan? Who does it, how often, and what is the test procedure.
- What is the exit? If this proves to be a mistake, what would moving off cost?
Teams that can answer all five usually succeed with it. Teams that cannot answer the first two usually end up with a cluster that is three versions behind and that nobody wants to touch.
Containers without the platform argument
It is worth separating two decisions that get bundled together.
Adopting containers is almost always a good idea. Consistent packaging, identical behaviour between a laptop and production, and a clean dependency boundary are valuable regardless of how the containers are run.
Adopting an orchestration platform is a separate decision with its own cost. Plenty of teams run containers on a managed service, or even on virtual machines with a simple supervisor, and get most of the packaging benefit with none of the platform overhead.
Keeping the two decisions apart makes it much easier to have a calm conversation about the second one, because nobody is defending containers themselves.
What to do with an inherited cluster
Many teams did not choose Kubernetes; they inherited it. The situation is common enough to deserve its own answer.
Start by establishing what version it runs and how far behind support it is, because an unsupported control plane is a security problem with a deadline. Then inventory the add-ons and identify who, if anyone, owns each. Then check whether the cluster can be recreated from code — if not, that is the first project, because a cluster nobody can rebuild cannot safely be upgraded.
Only after those three is it worth asking whether to keep it. A migration away from a working cluster is a real project, and the honest comparison is against a maintained cluster rather than against the neglected one in front of you.
Frequently asked questions
Is Kubernetes overkill for a startup?
Usually, unless the team already knows it well. The operational cost is real and competes directly with product work at exactly the stage when product work matters most.
Do I need containers without orchestration?
Yes. Containers are valuable for packaging and environment consistency on their own. Orchestration solves a separate problem that you may not have.
What is a service mesh and do I need one?
A layer handling service-to-service traffic — encryption, retries, traffic splitting, observability. Valuable at significant scale, and a substantial addition to operational complexity below it.
Can Kubernetes reduce cloud costs?
It can, through better bin-packing of variable workloads. For steady workloads the savings are small and often outweighed by the cluster overhead and the engineering time. See cloud cost optimization for approaches with better returns.
