Why Kubernetes exists (and when you actually need it)

Welcome to part 1 of Kubernetes from Zero. Before we run a single command, let's build the mental model — because Kubernetes makes no sense until you understand the problem it solves.

The problem: containers don't manage themselves

Docker made packaging apps easy. But the moment you run containers in production, questions pile up:

• What restarts a container when it crashes at 3am?
• How do you run 10 copies and spread traffic across them?
• How do you roll out v2 without downtime — and roll back when it breaks?
• What moves your containers when a server dies?

You can script all of this. Congratulations — you've built a worse Kubernetes.

What Kubernetes actually is

Kubernetes is a desired-state machine. You declare what you want ("3 replicas of this image, reachable on port 80"), and controllers work continuously to make reality match. That's the whole trick — everything else is detail.

# You declare this...
spec:
  replicas: 3

...and if a node dies taking a replica with it, Kubernetes notices the count is 2 and starts another. Nobody gets paged.

When you don't need it

Honesty time: a personal site, a small API, a startup MVP — these are often better served by a static site, a single VM, or a serverless platform. Kubernetes earns its complexity when you have many services, many teams, or real scaling needs.

Next up in part 2: we get our hands dirty with Pods — the atom of Kubernetes.