Kubernetes.
An air-traffic controller for your containers: you say what you want running, it keeps it that way.
An air-traffic controller does not fly the planes. It is handed a goal — these flights, landed safely — and it works out which runway each one uses, reroutes around a closed strip, and calls in more capacity when the skies get busy.
Kubernetes is that controller for your containers. You declare the state you want — “run three copies of this app” — and it figures out where to place them, restarts anything that dies, and keeps reality matching your declaration without you micromanaging each machine.
- Three, please.1
You declare what you want: “keep three copies of this app running.”
- 2
The controller schedules those copies (pods) onto whichever machines have room.
- 3
It constantly compares what you asked for against what’s actually running.
- One down — replacing.4
A pod crashes? It notices the gap and starts a replacement automatically.
- 5
Need more? Change the number to ten and it fills in the rest.
- 6
Deploying a new version? It swaps pods gradually, so there’s no downtime.
Declarative, not step-by-step
The shift Kubernetes makes is from telling a server how to do something to telling the cluster what you want to be true. You hand it a desired state; a control loop endlessly nudges the actual state toward it. That is why it self-heals: a crashed pod simply makes actual diverge from desired, and the loop corrects it without anyone intervening.
What it buys, and what it costs
Run across many machines, this gives you automatic restarts, rolling updates, scaling, and rescheduling around dead hardware. The cost is real complexity: Kubernetes is a large system with a steep learning curve, and for a single small service it is often more machinery than the job needs. It pays off when you are running many services at scale.