Do You Need Kubernetes? An Honest Answer

Kubernetes is excellent software that solves genuine problems. It is also adopted by a great many teams who do not have those problems yet, and who pay its operational cost daily in exchange for capability they do not use.

The honest question is not whether Kubernetes is good. It is whether your constraints are the ones it addresses.

What it genuinely solves

• Bin-packing many workloads onto shared capacity efficiently.
• Declarative desired state with continuous reconciliation — the cluster works to match your specification.
• Self-healing. Failed containers restart, failed nodes have their workloads rescheduled.
• Rolling deployments and rollback as a built-in primitive.
• Service discovery and load balancing inside the cluster.
• A common platform contract across many teams, so each does not reinvent deployment.

That last point is the one people underrate. Kubernetes is at its most valuable as an organisational tool — a shared contract between many teams — rather than as a technical one.

What it costs

• Conceptual surface. Pods, deployments, services, ingresses, config maps, secrets, RBAC, network policies, persistent volume claims, storage classes, admission controllers. That is a body of knowledge before you deploy anything.
• Operational surface. Cluster upgrades, node pool management, certificate rotation, CNI and CSI plugins, resource quota tuning.
• Debugging complexity. Failures acquire more layers between symptom and cause.
• Cost overhead. Control plane charges on some providers, plus the system components on every node.
• Security surface. RBAC, network policies and pod security standards are real work and are frequently left at permissive defaults.

None of this is an argument against Kubernetes. It is the price, and it is worth naming so the trade is deliberate.

Simpler options that cover most cases

A load balancer, two application instances and a managed database cover an enormous range of production workloads, with a fraction of the moving parts. That architecture is described in the web application hosting guide.

Signals that you have outgrown the simpler path

These are specific, and none of them is "it feels more professional":

• Many services, many teams. Kubernetes shines as a shared contract once you have more services than people can hold in their heads.
• Genuinely bursty workloads where bin-packing produces real savings.
• Complex deployment topologies — canaries, per-tenant deployments, many environments.
• You are already building the pieces. If you have written your own scheduler, service discovery and rolling deploy tooling, you are building a worse Kubernetes.
• Your ecosystem assumes it. Some software now ships primarily as Helm charts and operators.

If two or more of those are true, adopting it is probably the right call. If none are, it is likely premature.

Adopting it sensibly

If you do go ahead:

1. Use a managed control plane. GKE, EKS, AKS, DOKS, LKE or an equivalent. Self-managing the control plane is a specialist job with no business value. GKE Autopilot goes furthest by removing node management too, which is a large part of why teams already committed to Kubernetes often prefer a Google Cloud account for it.
2. Do not run your primary database in it initially. Stateful workloads are where Kubernetes is hardest. Use a managed database and revisit later, if ever.
3. Set resource requests and limits from the beginning. Without them, scheduling is guesswork and one workload can starve others.
4. Use namespaces and RBAC properly from day one. Retrofitting isolation is painful.
5. Apply network policies. Default-allow between all pods is the Kubernetes equivalent of a flat network.
6. Define everything in Git. The declarative model is the point; clicking in a dashboard discards it. Infrastructure as code applies here directly.
7. Plan upgrades. Kubernetes releases frequently and support windows are short. Upgrading is routine work that has to be scheduled.

Frequently asked questions

Is Kubernetes cheaper than instances? Only when bin-packing many varied workloads onto shared capacity. For a handful of steady services it usually costs more once the control plane and system overhead are counted.

Can I run it on independent providers? Yes. Several offer managed Kubernetes with no control-plane charge. The surrounding ecosystem is thinner than the hyperscalers', but the core works.

What about serverless containers instead? Cloud Run, Container Apps and similar services cover a large share of container workloads with far less overhead. For stateless HTTP services they are frequently the better answer.

When is it clearly wrong? A single application with one or two services, one team, and steady traffic. That is a load balancer and two instances.