Do You Actually Need Kubernetes?

Updated 2026-09-24

Probably not. That’s the honest answer for most of the people asking, and it’s worth getting out of the way before a thousand words of nuance make it sound more complicated than it is.

Kubernetes solves a specific problem: keeping a lot of containers running across a lot of machines without a human watching. If you don’t have a lot of machines, you have bought the solution without the problem, and it charges rent. A cluster is a permanent operational commitment, not a deployment target you set up once.

What Docker alone actually gets you

More than people expect. A single server running Docker Compose will comfortably serve a web app, its database, a cache and a background worker. It survives reboots if you set a restart policy. It deploys with a git pull and a compose up. One person can hold the entire thing in their head, which matters more at 2am than any feature on a comparison chart.

The ceiling is real, though, and it’s worth naming honestly. One server means one failure domain: when that machine goes down, everything on it goes down, and nothing brings it back but you. Deploys have a brief gap where the old container has stopped and the new one hasn’t finished starting. You scale by buying a bigger machine, until you can’t.

For a great many services, that is an entirely acceptable set of tradeoffs, and pretending otherwise is how teams end up maintaining a cluster to run a blog.

Where the threshold actually is

The line isn’t traffic. It’s whether the work of running things by hand has started to exceed the work of running a cluster.

You’re past it when you have more than a couple of machines and you’re manually deciding what runs where. When “the server that hosts X” is a sentence anyone in the team says. When you need a deploy that doesn’t drop requests, and you’ve started writing scripts to drain connections. When something needs to restart itself at 4am and nobody wants to be the person who gets paged.

Those are orchestration problems. Kubernetes is a genuinely good answer to them, and if you have several at once you should stop resisting it.

You are not past the line because your architecture diagram has microservices on it, or because a job posting mentioned it, or because you expect to scale later. Scaling later is a thing you can do later. The migration from Compose to Kubernetes is real work but it isn’t a rewrite, and paying for it now to avoid it hypothetically is the most common version of this mistake.

If you do need it, use a managed one

Self-managing a control plane means owning etcd, certificate rotation, version upgrades and the class of failure where the thing that schedules your workloads is itself the thing that’s broken. The managed offerings from the major clouds charge a modest hourly fee for the control plane and absorb all of that.

Run your own control plane if you have a compliance requirement that forces it, or an on-premises environment with no alternative, or a team large enough that a platform group exists. “It’s cheaper” is usually wrong once you price the hours.

Docker or Podman

Different question, much lower stakes, and the honest answer is that either will do.

Both build and run images to the same standard, so this isn’t a lock-in decision. The difference worth caring about is architectural: Docker runs a background daemon as root by default, and Podman runs containers under your own user with no daemon at all.

That matters for one specific reason. If a container process escapes its isolation, what it lands in differs. Under a root daemon, it lands as root on the host. Under rootless Podman, it lands inside a user namespace, confined to one unprivileged user’s files. Docker can be run rootless too (that’s been available for years), but it’s opt-in, and most installations never turn it on. Podman’s advantage is largely that its safer configuration is the default one, which is a meaningful advantage in practice even though it sounds like a technicality.

Podman is the better default for Linux servers, especially anything multi-tenant. Docker remains the pragmatic choice on macOS and Windows, where the tooling is better maintained, and in CI systems that assume it exists. Neither choice is one you’ll struggle to reverse.

Worth knowing, because it causes recurring confusion: Kubernetes removing support for Docker as a runtime did not make Docker images stop working. Images are a standard format. Anything Docker builds, Kubernetes runs.

The mistakes that actually cost people

Adopting it for one service. A cluster running a single application has all of the operational cost and none of the benefit. If there’s one thing to run, run it on a server.

Skipping resource limits. A container with no memory limit will, given a leak, consume the node and take its neighbors with it. This is the single most common way a cluster goes from fine to on fire, and the fix is a few lines of configuration.

Treating health checks as optional. Without them, Kubernetes knows your process is running but not whether it works, so it will cheerfully route traffic to something that’s been broken for an hour.

Letting the YAML sprawl. Hand-maintained manifests multiply quietly and then one day nobody knows which file is authoritative. Pick a templating approach early, even a basic one.

The short version

Run one server with Docker Compose until something forces you off it. When several machines and a no-downtime requirement arrive together, move to managed Kubernetes and set resource limits on day one. Prefer Podman on Linux servers for the rootless default.

If you’re running this at home rather than in production, the calculus is different and mostly about learning. Our Kubernetes at home guide covers that case. When a container is already misbehaving, container troubleshooting is the faster place to start.