When Kubernetes is the wrong answer

Kubernetes is genuinely good technology that solves genuinely hard problems. It is also adopted constantly by teams who do not have those problems, and the cost of that decision is paid every day afterwards by whoever operates it.

This is not an argument against Kubernetes. It is an argument for adopting it in response to a problem rather than in anticipation of one.

The problems it actually solves

Scheduling across many machines. Deciding which of fifty nodes should run which workload, and rescheduling when a node fails. This is a real and hard problem at that scale, and Kubernetes solves it well.

Declarative desired state with reconciliation. You describe what should be running and a controller continuously works to make reality match. Powerful, and genuinely different from imperative deployment scripts.

Self-healing. Failed containers restarted, failed nodes drained, workloads rescheduled, without human intervention.

A standard interface across environments. The same manifests describe workloads whether they run on a laptop, on premises or in three different clouds.

Independent deployment by many teams. Namespaces, quotas and policies let a lot of people share infrastructure without coordinating every change.

If you have several of these problems, Kubernetes is a good answer and the complexity is warranted.

What it costs

A large amount to learn. Pods, deployments, services, ingresses, config maps, secrets, persistent volume claims, storage classes, service accounts, role bindings, network policies, resource quotas, taints and tolerations. Each is reasonable; together they are a substantial body of knowledge, and troubleshooting requires most of it.

A control plane to run or pay for. Managed control planes remove much of this and cost money. Self-managed control planes are a serious operational commitment.

Persistent operational work. Cluster upgrades, node upgrades, API deprecations between versions, certificate rotation, and the ecosystem components you inevitably add: an ingress controller, a certificate manager, monitoring, log shipping, a secrets integration. Each is another thing to upgrade and another way to break.

Deep failure modes. When something breaks, the cause may be in your application, in the workload definition, in the scheduler, in networking, in storage provisioning, or in a controller. Diagnosis requires understanding the whole stack.

Cost that is easy to lose track of. Requests and limits set generously, nodes half empty, and the bill drifting upward without anyone able to attribute it.

Simpler things that solve most of the same problems

Before concluding you need an orchestrator, consider what the actual requirement is.

“We need reliable deployments.” A container running under the host’s service manager with a restart policy, deployed by a script, achieves this on one machine.

“We need zero-downtime deployments.” A load balancer with health checks and connection draining in front of two instances achieves this without any orchestration.

“We need to scale.” A managed autoscaling group behind a load balancer scales instances without you learning a scheduler.

“We need containers.” Containers are useful on one machine. They do not require Kubernetes.

“We need to run several services.” A compose file on one reasonably-sized machine runs a surprising number of services, and one machine can be quite large.

“We need it to survive a failure.” Two machines in different zones behind a load balancer, with infrastructure defined in code, covers this.

“We might need to move clouds.” Containers plus infrastructure as code gives most of the portability. Kubernetes moves the workload definitions and leaves the cloud-specific parts, storage classes, load balancers, identity integration, still needing work.

Reasonable signals that it is time

Adopt it when several of these are true, not one:

• More than roughly ten to fifteen services with real interdependencies.
• Multiple teams deploying independently and needing isolation from each other.
• Genuine need to schedule across many nodes with efficient bin packing.
• Workloads that legitimately need to move between nodes automatically.
• Someone whose job includes operating the cluster, rather than everyone doing it occasionally.
• A concrete problem you have tried and failed to solve more simply.

That last one is the real test. “We might need it later” is not a reason. Later is when you adopt it, and by then you will understand your requirements far better.

If you do adopt it

Use a managed control plane unless you have a specific reason not to. The upgrade and availability work you avoid is the largest single share of the operational burden.

Start with a small number of workloads rather than migrating everything. Set resource requests and limits from the beginning, because retrofitting them across a busy cluster is unpleasant. Budget real time for learning, and expect the first three months to be slower than what you replaced.

And keep a written note of the problem you adopted it to solve, so that when someone asks in a year whether the complexity is worth it, there is an answer.

The same reasoning applies across providers. The catalogue of cloud accounts sets out where each one fits, if you are still deciding which to build on.

For the vendor’s own reference on the services involved here, see the DigitalOcean documentation.

None of this takes long to try once you have somewhere to run it. Our DigitalOcean accounts come in six configurations from $20, and the cloud account catalogue shows the nine other providers we carry.

Questions people ask