Do You Need Kubernetes?
Kubernetes is a distributed workload orchestration platform. The first question is not how to use it but whether the orchestration problem it solves is one you actually have.
The question, the obvious approach, and why it breaks
Every lesson starts where the work starts: an operational problem, a first attempt that is entirely reasonable, and the way production disagrees with it.
Before learning any of it — is orchestration complexity justified for this system?
Kubernetes solves placement, restart, discovery, rollout and scaling for many workloads across many machines. Teams adopt it before they have many workloads or many machines, and take on a distributed control plane's failure modes in exchange for problems they did not have.
Treat Kubernetes as the definition of production. Everyone credible appears to run it, every job posting lists it, and every tutorial ends there — so the platform decision is settled before anyone writes down the requirements.
The operational surface arrives immediately and the benefit arrives later. On day one you own cluster upgrades, node pools, RBAC, ingress controllers, certificate rotation and a YAML supply chain, in exchange for scheduling three containers that fit on one machine.
- The operational surface arrives immediately and the benefit arrives later. On day one you own cluster upgrades, node pools, RBAC, ingress controllers, certificate rotation and a YAML supply chain, in exchange for scheduling three containers that fit on one machine.
- Debugging gets a new layer. "The service is down" now has candidate causes at the application, pod, node, scheduler, network policy and ingress layers, and a small team has to learn all of them under time pressure.
- The abstractions leak in ways that need genuine expertise: OOM kills that look like crashes (OOMKilled: Over the Memory Limit), CPU throttling that looks like slow code (CPU Throttling: The Latency With No Error), liveness probes that turn a dependency outage into a restart storm (Probes: Readiness, Liveness and Startup).
- The reliability story often gets worse before it gets better. A single VM with a process supervisor has a small, well-understood set of failure modes. A cluster has those plus its own.
- Cost rises in a way that is easy to miss: control plane charges, node headroom for scheduling, and the engineering time that goes into the platform instead of the product.
What is actually happening
Underneath the tooling, which is the part that survives a change of tool.
- Kubernetes is a reconciliation engine over a cluster of machines. You declare desired state; controllers observe actual state and act to close the gap (Reconciliation: The Loop Under Everything). That is the whole product; everything else is an object type that participates in it.
- The value of that engine scales with how many independent decisions it makes on your behalf. Where should this workload run, given current capacity? What should happen when a machine dies? How does traffic find the replacements? How do I replace all of them without dropping requests?
- If you have one workload on one machine, the engine makes almost no decisions and you are paying its full cost. If you have forty workloads across thirty machines with different resource shapes and independent release cadences, doing this by hand is worse.
- The honest threshold is about number of independent workloads and rate of change, not about traffic. A high-traffic single service is a scaling problem, not an orchestration problem. Twenty low-traffic services owned by six teams is an orchestration problem.
What it actually gives you, and what it does not
Kubernetes is worth describing by capability rather than by reputation. The left column is what the reconciliation engine genuinely does for you. The right column is what people believe it does, and then discover it does not.
Nothing in the right column is a criticism of the platform. They are simply different problems, owned by different lessons in this domain — and a team that expects Kubernetes to solve them will be surprised at the worst possible moment.
| Kubernetes does | Kubernetes does not | Who owns the second column |
|---|---|---|
| Place workloads onto machines with capacity | Decide how much capacity you need | Building a Capacity Model, Requests and Limits |
| Restart crashed containers and reschedule off dead nodes | Make an unreliable service reliable | Backend design and What Can Fail Between Commit and User |
| Give a changing set of pods one stable address | Handle a dependency that is down | Timeouts and circuit breakers in the caller |
| Replace pods gradually toward a new desired state | Tell you whether the new version is good | Canary Analysis: Compared Against What?, A Successful Deploy Is Not Evidence of a Healthy System |
| Change replica counts on a signal | Fix a bottleneck that is not the replica count | How Autoscaling Fails |
| Attach storage to a workload | Give you a correct database | Why Stateful Workloads Are Harder, Backup Operations |
| Enforce declared desired state | Prevent you declaring something wrong | Policy as Code, review |
The threshold question, with honest costs
This is the decision the module exists to make explicit. There is no winner in the list below; there is a workload shape that each option fits, and a bill each one sends.
The most common real mistake is not picking the wrong option — it is picking the last option without ever having considered the first four.
You have a containerised service and a team that has to operate it. What is the smallest platform that meets the requirement?
when One or two deployable units, one team, downtime measured in minutes is acceptable during a machine failure.
cost Machine failure is manual until you add a second. Deploys are your own script. Scaling is vertical until it is not.
when Event-driven or bursty work, no long-lived connections, cold start is tolerable.
cost Execution model constraints, connection management to databases, and a fairly hard limit on how much of the platform you can inspect.
when A handful of long-running services, standard HTTP shape, and you want rollouts and health checks without a cluster.
cost Less control over networking, placement and sidecars; provider-shaped abstractions you cannot fully escape.
when Many independent workloads, several teams, real need for uniform rollout, discovery and policy across them.
cost The full object model, cluster upgrades, RBAC, ingress and network policy — as ongoing owned work, not a one-off setup.
when A regulatory, on-premise or hardware requirement that no managed offering meets.
cost Everything above plus control plane operations, etcd backups and upgrade choreography. This is a platform team's full-time job.
Why "because everyone uses it" is an interview red flag
This is worth stating plainly because it comes up in interviews constantly. Asked why a system runs on Kubernetes, a weak answer says production systems use Kubernetes. That answer contains no requirement, no alternative considered and no cost acknowledged — which is exactly what the question is testing for.
A strong answer names the orchestration problem: how many workloads, how many machines, what happens on node failure, what the release cadence is across teams, and what the smaller option would have failed to do. It also names what the choice cost.
The same standard applies inside your own team. If nobody can answer the question without appealing to what other companies do, the decision has not been made yet — it has been inherited.
"We run on Kubernetes because that is what production systems run on, and it gives us scalability and reliability."
"We had eleven services across four teams, each with its own deploy script and its own idea of health checks. We moved to managed Kubernetes for uniform rollout and discovery. It cost us a quarter of platform work and we still run the database as a managed service outside the cluster."
The second answer can be wrong — that is what makes it an answer. It states a threshold that was crossed, an option that was rejected, and a boundary that was deliberately drawn. The first is a description of the industry, not of a system.
How to do it properly
Most important first.
- Write the requirement before the platform: how many deployable units, how often do they change, how many teams touch them, what has to survive a machine failure, and what is the recovery target.
- Start at the lowest-ceremony option that meets those requirements, and move up only when a concrete operational problem forces it. A managed container service or a PaaS covers a very large fraction of real systems.
- If you do adopt it, adopt it managed. Running the control plane yourself is a separate discipline with its own on-call burden, and it is almost never the differentiating work.
- Decide deliberately what stays outside the cluster. Managed databases, queues and object storage outside Kubernetes are a normal, defensible architecture (Why Stateful Workloads Are Harder).
- Budget the platform work honestly. If nobody has time to own upgrades, RBAC and ingress, you do not have the capacity for a cluster, whatever the architecture diagram says.
How much can this affect
Every production change has a blast radius. Stated as a scale so it is comparable between changes rather than adjectival — and paired with what actually contains it, because a wide scope with a real containment mechanism is a different situation from a wide scope with none.
Nothing contains a platform choice once workloads depend on it — the exit cost grows with every service added, which is why the decision belongs before adoption rather than after.
What can go wrong
- Adopted for hiring or resume reasons, then owned by nobody. The cluster drifts, upgrades are deferred, and the first serious incident is also the first time anyone reads the node logs.
- Adopted and then used as a worse VM: one giant deployment, no requests or limits, manual
kubectlchanges, and none of the reconciliation benefits. - Rejected for the wrong reason — "too complex" — on a system that genuinely has forty services and now has forty bespoke deploy scripts instead.
- Adopted correctly and then treated as the reliability strategy. A cluster restarts crashed pods; it does not make a badly designed service reliable.
- "Production means Kubernetes." It does not. Production means real traffic, real data, real failure and continuous change (Why Local Success Predicts So Little). Plenty of serious production systems run on VMs, a PaaS, or serverless.
- "Kubernetes makes systems reliable." It restarts failed containers and reschedules them off dead nodes. It cannot fix a service with no timeouts, a database with no backups, or a rollout with no verification.
- "We will need it eventually, so we should start now." Sometimes true, often an argument for paying a cost years early. The containerisation transfers; the cluster operations do not.
- "It is simple once you learn it." The object model is learnable in a week. The failure modes take much longer, and they are the part that matters at 3am.
Operating it
Evidence is the signal, not the intention. Rollback is sometimes 'you cannot, and that is the point'.
- You can state the specific operational problem the platform is solving, in a sentence that does not contain the word "standard" or "industry".
- The number of production incidents caused by the platform is falling rather than rising over the first two quarters.
- Engineers ship changes without needing to understand cluster internals, which is the whole promise (Golden Paths).
- Somebody is named as the owner of cluster upgrades, and the last upgrade happened on schedule.
- Leaving Kubernetes is far harder than adopting it, because manifests, ingress behaviour, service discovery and secret plumbing all become dependencies. Treat adoption as a mostly one-way door and price it accordingly.
- What is genuinely reversible: containerising your workloads. Container images run on plenty of platforms, so the containerisation work is not wasted if you choose something simpler (The Container Lifecycle).
- If you must leave, leave one service at a time behind a load balancer that can point at both, and keep the cluster running until the last consumer moves.
- Automate cluster creation and node pool configuration as code from the first day, so the cluster is reproducible rather than an artifact of a console session (Infrastructure as Code).
- Automate the boring parts of the adoption decision's consequences: manifest linting, policy checks, resource defaults.
- Do not automate the adoption decision itself, and do not delegate it to a template repository. It is a capacity and ownership judgement about your team.
- The right answer is genuinely scale-dependent, which is unsatisfying. There is no size at which Kubernetes becomes correct for everyone, and no size at which it is always wrong.
- Choosing something simpler can mean a migration later. That is a real cost — but a migration you can afford later is usually cheaper than a platform you cannot operate now.
- Managed Kubernetes removes the control plane burden and adds provider coupling in node pools, load balancer integration and IAM (Workload Identity).
Where this applies
This domain is unusually tool- and organisation-dependent. These labels say what each claim is specific to, and what a different platform, provider or organisation does instead.
- KUBERNETES-SPECIFICThe costs listed here are the cost of running a Kubernetes cluster specifically. A PaaS or managed container service charges you a different bill: less control over placement and networking, no control plane to operate, and no cluster upgrade cadence to own.
- SCALE-SPECIFICBelow roughly a handful of deployable units on a handful of machines, the orchestration engine makes almost no decisions for you and its operational cost dominates. The balance shifts as independent workloads and independent release cadences multiply.
Where the depth lives
This domain teaches delivery and operation, and hands the mechanism off to the domain that owns it.
- — System Design — sizing the system before choosing the platform that runs it.