Running containers at scale means answering five questions, forever.

Shopwave runs 40 services across 12 servers. Without an orchestrator, a human (or a pile of scripts) owns every one of these decisions.

Placement

Which server should this container run on, given CPU, memory and zones?

Failure

A server dies at 3 a.m. What restarts its containers, and where?

Discovery

How does checkout find payments when IPs keep changing?

Rollout

How do you ship v2 with no downtime, and undo it in seconds?

Scale

Black Friday triples traffic. What adds capacity, and removes it after?

Kubernetes automates all five, continuously, from a desired state you declare.

You write "3 replicas of checkout:1.4 behind one stable name". The system decides placement, replaces failures, wires discovery, rolls out changes and scales on demand.

Five questions you would otherwise answer by hand

Start with the pain, not the product. Containers solved packaging: an image runs the same on a laptop and a server. They did not solve operations. Once you have dozens of services on a fleet of machines, five questions appear and never go away: where to run things, what to do when machines fail, how services find each other, how to change versions safely, and how to follow load up and down.

Before orchestrators these were answered by runbooks and bespoke scripts, and each answer was brittle: a script that assumes a server is healthy cannot cope with half-failure. Kubernetes' contribution is to make all five answers the output of one continuous process driven by declared intent.

Press the right arrow to reveal each question. The last card is the single-sentence answer worth memorising for interviews: Kubernetes continuously works to make the actual state match the desired state, placing containers, restarting them, routing traffic to them and scaling them without a human doing it manually.