You still do not need Kubernetes

Kubernetes is genuinely good software. It solves a real problem well. It has an enormous ecosystem and a large pool of people who know it.

It is also, for a majority of the teams running it, a substantial amount of complexity in exchange for benefits they do not receive, and saying so is still mildly heretical.

the problem it actually solves#

Kubernetes was built for: many services, many teams, heterogeneous workloads, on a fleet of machines, where you want bin-packing efficiency and declarative self-healing, and where the platform is operated by people whose job that is.

If you have all of those, it is the right answer and there is no close second.

what it costs#

A permanent learning tax. Pods, deployments, services, ingresses, configmaps, secrets, persistent volume claims, storage classes, service accounts, roles, network policies, resource quotas, and a YAML dialect for each. Every engineer who deploys anything must learn a meaningful fraction of it.

Operational surface. Control plane upgrades, node upgrades, CNI plugin, CSI driver, ingress controller, cert manager, metrics server, log shipper. Each is a component that can break and that must be upgraded on someone else's schedule.

Debugging distance. "Why is my service not reachable" has a dozen possible answers across five layers, and diagnosing it requires understanding all of them.

Cost, frequently. A managed control plane plus nodes sized for the platform's own overhead plus the observability stack it needs is often more than the equivalent capacity on simpler infrastructure.

Resume-driven adoption. This is real and worth naming. Kubernetes on your CV is worth money. That is a genuine incentive pointed away from the simplest solution that works.

the honest threshold#

You probably want Kubernetes if:

• More than roughly fifteen to twenty distinct services, deployed independently.
• More than a handful of teams that need to deploy without coordinating.
• You have someone whose job includes operating the platform, not as a side task.
• Genuinely heterogeneous workloads with different scaling characteristics.
• Multi-tenancy requirements with real isolation needs.

You probably do not if:

• Under ten services.
• One or two teams.
• Nobody owns the platform.
• Traffic is predictable.
• You are running one application with a database.

what to do below the threshold#

The options are better than they were, and all of them are boring:

A platform-as-a-service. Push code, it runs. This is the correct answer for a very large number of applications and the reason people avoid it is usually aesthetic.

Containers on a managed container service without the orchestrator — the various "run this container, scale it, load balance it" products every cloud offers. You get containers, autoscaling, and rolling deploys without the platform.

A couple of servers and a process manager. Systemd units, a reverse proxy with automatic certificates, and a deploy script. This runs an enormous amount of traffic, is trivially debuggable, and every engineer already understands it.

Docker Compose on one machine. For staging, for internal tools, for anything where a single host is enough. Unfashionable, works.

the migration-path argument#

"We will need Kubernetes eventually, so we should start now."

This is the most common justification and it is usually wrong, for two reasons.

First, the complexity cost is paid every day from now until then, and "eventually" frequently never arrives.

Second, containerizing your application is the actual hard part of a future migration, and you can do that without an orchestrator. A containerized application running under a simple process manager can move to Kubernetes later in a couple of weeks.

Build the container. Skip the platform until you have the problem it solves.

the position I will defend#

The teams I have seen most successfully run Kubernetes are large organizations with dedicated platform teams, where it is genuinely the right tool.

The teams I have seen most damaged by it are small ones where a single engineer set it up, that engineer left, and the remaining team is operating a system nobody understands and is afraid to touch.

That second failure is common, expensive, and entirely predictable from the staffing at adoption time. If nobody's job is going to be operating the platform, you should not have a platform.