Topic 0.1
Why Kubernetes: The Orchestration Problem
In one line
Running one container is easy; running hundreds across many machines, healing them when they crash, and scaling them under load is a genuinely hard problem — Kubernetes is the tool built specifically to solve it.
Think of it like this
One restaurant kitchen (Docker Compose on one machine) versus running an entire restaurant CHAIN — hundreds of kitchens across many cities, each needing consistent staffing, automatic replacement when someone calls in sick, and the ability to open new locations instantly when demand spikes. Kubernetes is the chain's central operations system, not any single kitchen's recipe book.
Key ideas
- 01
Docker (and Compose) answer 'how do I package and run a container' — genuinely solved problems, covered fully in Docker's own course. Kubernetes answers a different question entirely: 'given hundreds of containers that need to run across many physical machines, how do I decide WHICH machine runs WHICH container, restart it automatically when it crashes, and route traffic to whichever healthy copies currently exist?'
- 02
This coordination problem is called ORCHESTRATION. Without it, running containers at real scale means manually deciding which server runs which container, manually restarting anything that crashes, manually updating a load balancer's configuration every time something moves — genuinely impractical past a handful of containers, and completely unworkable at hundreds or thousands.
- 03
Kubernetes' actual job, stated plainly: given a DESIRED STATE ('I want 5 copies of this container running, healthy, reachable at this address'), continuously work to make the ACTUAL state match it — starting containers where needed, restarting crashed ones, moving them off failed machines, and updating networking automatically as things change. This 'declare what you want, the system makes it true' model, called RECONCILIATION, is the single most important mental model in this entire course.
- 04
Kubernetes was originally developed by Google, based directly on their internal experience running enormous numbers of containers (their internal system was called Borg) — it was open-sourced in 2014 and has since become the de facto standard for container orchestration, with every major cloud provider offering a managed version (AWS's EKS, Google's GKE, Azure's AKS).
- 05
The one-sentence pitch you should be able to give in an interview: 'Kubernetes is a container orchestration platform — you declare the state you want, and it continuously reconciles the actual cluster to match it, handling scheduling, healing, scaling, and networking automatically across many machines.'
Code & diagrams
Without an orchestrator, every one of these is a manual, error-prone task at scale.
Explain it without notes
What specific problem does Kubernetes solve that Docker Compose genuinely cannot, once you're past a handful of containers on one machine?
What does 'declarative, reconciled state' actually mean, in your own words, and why is it more powerful than manually running commands to fix things as they break?
Practice
Think of a real application you've worked on (or a hypothetical one) that runs as multiple copies for reliability — write one sentence describing what SHOULD happen automatically if one copy crashes, without anyone manually intervening.
Look up which managed Kubernetes service (EKS, GKE, AKS) a cloud provider you're familiar with offers, and note one sentence on what 'managed' means in that context (hint: who runs the control plane, Phase 0.2).
Trade-offs
- ↔
Kubernetes' power comes with genuine complexity — for a single small application on one machine, Docker Compose remains simpler, faster to set up, and easier to reason about, with zero orchestration overhead to learn. Kubernetes earns its complexity specifically once you have enough scale, enough machines, or enough reliability requirements that manual container management becomes genuinely impractical — reaching for it before that point is adding real overhead for a problem you don't have yet.
Done when you can
I can explain the orchestration problem Kubernetes solves, beyond what Docker Compose already handles.
I understand the declarative, reconciled state model: describe what you want, the system continuously makes it true.
I know Kubernetes originated from Google's internal Borg system and is now offered as a managed service by every major cloud.