An automated manager for large numbers of containers: it starts them, stops them, spreads them across machines, and heals them.
Why it exists
Running many containers across many machines by hand, restarting the crashed ones and scaling the busy ones, is more than people can manage. Kubernetes exists to orchestrate containers automatically, deciding where they run, healing failures, and scaling them with load.
How it actually works
When you're running hundreds of containers across many machines, doing it by hand is impossible. Kubernetes automates it: it places containers on machines, restarts ones that crash, adds more when traffic rises, and removes them when it falls, keeping the system in the state you asked for.
It's powerful and complex, the kind of tool a platform team runs. Most PMs only need to know it's the thing keeping a fleet of containers healthy and scaled.
A senior PM walks you through it
A junior PM, stuck
After the Friday lunch spike the platform engineer dropped "k8s handled it, pods went 3 to 8" in the channel and moved on. My lead will ask me in the launch review whether anything actually went down during peak, and "the engineer said it was fine" is not an answer I can defend. He also sent me fourteen kubectl event lines from that window that I cannot read.
"K8s handled it" is a checkable claim, and these fourteen lines are how you check it instead of taking his word. This is Kubernetes narrating its own decisions during lunch: each line has a time, a type that is either Normal or Warning, the thing it acted on, and what it did. The trick is to hunt the Warning lines first, then see whether a Normal recovery line follows each one. Do not worry about the pod names, they are just labels. Here are the lines. Read the type column down the left, then take the steps with me.
2026-03-06T12:46:04Z Normal Pod/orders-7f9-c Restarting container orders
2026-03-06T12:46:19Z Normal Pod/orders-7f9-c Started container orders
2026-03-06T13:02:50Z Normal HorizontalPodAutoscaler/orders metric cpu 71% below target 80%
2026-03-06T13:12:50Z Normal HorizontalPodAutoscaler/orders scaled down replicas 8 to 3
2026-03-06T13:12:52Z Normal Pod/orders-7f9-b Killing container, draining
2026-03-06T13:12:55Z Normal Pod/orders-7f9-b Terminated
2026-03-06T13:15:00Z Normal HorizontalPodAutoscaler/orders replicas steady at 3
Click a step to see the lines it points at.
Mistakes I've seen
Taking "k8s handled it" on faith because you cannot read the log. The claim is verifiable in these lines, and a launch review answer should rest on the OOMKilled-then-recovered evidence, not on trust.
Seeing OOMKilled and declaring an outage. A killed pod that restarts in sixteen seconds while seven others serve traffic is self-healing working, not customers seeing errors.
Ignoring the memory limit that caused the OOMKill. The pod died because it exceeded its limit at peak, which is a real follow-up ticket, raise the limit or find the leak, even though nothing went down this time.
Assuming autoscaling is instant when planning a flash sale. New pods took about thirty seconds to start here, so a sudden vertical spike can still hurt for that window, and pre-scaling before a known event is the safer plan.
Reporting "pods went 3 to 8" as a flat fact. It was two steps over six minutes, then back to 3, and that shape tells the reviewer how long peak lasted and that cost returned to baseline afterward.
Tell your lead: "I read the k8s events. Autoscaling took the orders pods 3 to 5 to 8 as CPU crossed 80% during lunch, then back to 3 afterward. One pod was OOMKilled at 12:46 but restarted within sixteen seconds while the others served traffic, so nothing went down for customers. The open item is that pod's memory limit, which we should raise before the next peak." You verified a claim from the log instead of relaying it.
Where a PM meets this
It's why large systems self-heal and autoscale; the practical upshot is resilience you can rely on when planning launches.
Its complexity is a real cost; "do we even need Kubernetes" is a genuine debate for smaller teams.
Hear it in a meeting
"Kubernetes will scale the pods automatically when traffic climbs."