0 / 15 lessons — 0%
Lesson 01 / 15 ⚓
Why Kubernetes?
Say you've got Docker figured out and you're running 40 containers across 6 servers. Then, at 2am, server 3 dies. Which containers were on it? Who restarts them, and where? Traffic is spiking — do you have room to add more copies of the checkout service, and on which server?
Doing all that by hand is exactly the kind of tedious, error-prone work computers are supposed to save us from. Kubernetes is a system that takes a declaration — "I want 4 copies of this app running, each with this much memory" — and continuously works to make reality match it. Node dies? It reschedules the pods elsewhere, automatically. Traffic spikes? Scale the replica count and it spreads the new copies across available nodes.
The mental model that unlocks everything: you don't tell Kubernetes how to do things step by step. You describe the end state you want, and a set of background loops called controllers constantly nudge reality toward that description. This is "declarative" infrastructure, and once it clicks, most of Kubernetes' weirder behavior makes sense.
| Manual container ops | Kubernetes |
|---|---|
| You SSH in and restart a dead container | A controller notices and restarts it for you |
| You pick which server has room | The scheduler picks based on actual resource usage |
| Scaling means SSHing into more servers | Scaling means changing a number in a YAML file |
| A bad deploy means a manual rollback | One command rolls back to the last working version |
Before lesson 2Hold onto this one sentence: "Kubernetes doesn't run containers, it runs Pods, and it constantly reconciles reality against what you asked for." Everything else in this course is detail on top of that sentence.