Kubernetes: What It Solves, and When You Don't Need It

Kubernetes is the default answer to "how should we run our containers", and for a large number of organisations it is the wrong one.

That is an unusual way to open a guide about it. But the most expensive Kubernetes mistake is not a misconfigured deployment — it is adopting it for a workload that never needed it, then spending the next two years paying for the complexity in engineer-hours you could have spent on the product.

So this guide covers what Kubernetes genuinely solves, how it works, and the honest test for whether you should use it.

The problem it solves#

You have containers. Now something has to decide which machine each one runs on, restart them when they crash, replace them when a machine dies, route traffic to the healthy ones, and roll out new versions without dropping requests.

Doing that by hand across three servers is tedious. Across three hundred it is impossible.

Kubernetes is the software that does it. You describe the desired state — "I want six copies of this container, reachable at this address, using this configuration" — and it continuously works to make reality match. If a machine dies at 3am, replacements start elsewhere without anyone waking up.

That reconciliation loop is the whole idea. Everything else is detail.

The concepts that actually matter#

You can be productive knowing six things.

Pod — one or more containers that run together and share an address. Almost always one container. This is the smallest thing Kubernetes schedules.

Deployment — "keep N copies of this pod running, and here is how to roll out a new version." This is what you write most often.

Service — a stable address for a set of pods. Pods come and go with changing IPs; the Service stays put and load-balances across whatever is currently healthy.

Ingress — routes outside traffic to Services. Where your domain names and TLS certificates live.

ConfigMap and Secret — configuration and credentials, kept out of the image so the same image runs in test and production.

Namespace — a boundary for grouping and access control.

That is enough to run real workloads. The remaining hundred-odd resource types are for cases you will know when you hit.

What it actually costs#

This is the part usually left out.

A control plane, either managed (a monthly fee per cluster) or self-run (more machines, and someone who understands etcd backups).

Idle capacity. You cannot run a cluster at 100% utilisation — you need headroom for rescheduling. Expect to pay for meaningfully more compute than your workload strictly uses.

Specialist knowledge. Networking, storage, RBAC, resource limits, ingress controllers, certificate management. This is a genuine specialism, and it does not overlap much with application development.

Upgrade work, forever. Kubernetes releases regularly and older versions stop being supported. Cluster upgrades are ongoing operational work, not a one-off.

A longer debugging path. "The site is slow" now has more layers between the request and the code — ingress, service, pod scheduling, resource limits, node pressure. Each is another place to look.

None of this is an argument against it. It is an argument for being honest about the bill.

The honest test#

Kubernetes earns its complexity when you have several of these, not one:

• More services than people can track by hand — typically a dozen or more
• Genuinely variable load that benefits from automatic scaling
• Multiple teams needing isolated, self-service deployment
• Strict availability requirements where automatic recovery is worth real money
• Portability across environments or providers as an actual requirement, not a slide

You probably do not need it if:

• You run a handful of services with steady traffic
• One team deploys everything
• Your platform's simpler offering — a managed container service, or plain virtual machines with a process manager — already meets your availability target
• Nobody on the team wants to own cluster operations

There is a real middle ground that gets overlooked: managed container services run containers, restart them, and scale them, without you operating a cluster. For a large share of workloads that is the correct answer, and it is not a compromise.

A useful sanity check: if your entire estate fits comfortably on two decent servers and you deploy once a week, Kubernetes is likely to add more operational surface than it removes.

Getting it right if you do adopt it#

Set resource requests and limits on everything. Without them, one misbehaving container starves its neighbours and the whole node degrades. This is the single most common production problem.

Write real health checks. A liveness probe that only confirms the process is running will keep a wedged application in service. Check that the thing actually works — can it reach its database?

Do not put state in the cluster casually. Managed databases exist for a reason. Running your own stateful services on Kubernetes is a specialist activity; treat it as one.

Keep your manifests in version control and apply them from there. Cluster state that only exists because someone typed a command is state you cannot reproduce after an incident.

Decide the boring things once — logging, metrics, secrets, certificates, ingress — and apply them uniformly. Most cluster pain is per-service snowflakes.

Cap what pods can do. Run as non-root, drop capabilities, restrict network traffic between namespaces. The default posture is permissive.

A realistic path#

If you decide it is right, start small and boring: a managed cluster from your cloud provider, one namespace per environment, a handful of services, manifests in git.

Resist service mesh, custom operators and multi-cluster federation until something specific hurts. Each is a reasonable answer to a real problem, and each is a large amount of complexity to carry if you do not have that problem yet.

Measure the thing that matters: how long from a developer merging code to it serving traffic, and how often that goes wrong. If those numbers are not better than what you had before, the platform is not earning its cost.

FAQ#

Is Kubernetes the same as Docker?#

No. Docker packages an application into a container image. Kubernetes decides where containers run, keeps them running, and connects them. They solve different problems — you use container images with Kubernetes, and you can use containers perfectly well without it.

Do we need Kubernetes to use containers?#

No, and this is the most common misconception. Containers run fine on a single server with a process manager, or on a managed container service. Kubernetes is for orchestrating many containers across many machines.

Is it cheaper than virtual machines?#

Usually not at small scale, once you count the control plane, idle headroom and the engineer time to operate it. It becomes cost-effective at scale, where bin-packing many workloads onto shared nodes genuinely improves utilisation.

Should we self-host or use a managed cluster?#

Managed, unless you have a specific reason not to. The control plane is the part most likely to ruin a weekend, and letting the provider run it removes the majority of the operational burden for a modest fee.

How long does a team take to become competent?#

Running a simple workload: days. Being able to debug a production incident confidently — resource pressure, networking, scheduling, storage — is more like six to twelve months of real exposure. Budget for that, or buy the expertise.

What breaks most often in production?#

Missing resource limits, health checks that do not check health, and configuration drift between what is in git and what is in the cluster. All three are preventable and all three are common.

Can we move to Kubernetes later?#

Yes, and often that is the right sequencing. Containerise first — that is where most of the benefit is, and it is portable. Adopt orchestration when the number of services or the availability requirement makes manual management genuinely painful.

What else is coming for Kubernetes