# Containers → Kubernetes

## What you've actually built, across this entire course

You can now package an application (Dockerfile), run it in isolation (containers), connect
multiple containers together (networking, Compose), and persist their data reliably (volumes).
That's a complete, real skill set for running an application on ONE machine. Kubernetes exists
to answer the question this course deliberately never had to ask: **what happens when "one
machine" isn't enough?**

## What Docker already solves

- **Application packaging** — a Dockerfile makes an environment reproducible anywhere.
- **Process isolation** — a container is isolated from other processes on the same machine.
- **Basic networking** — containers can reach each other and be reached from outside, on one
  host.
- **Basic multi-container orchestration** — Compose runs a small set of related containers
  together, on one host.

## What Kubernetes adds on top

- **Scheduling** — deciding WHICH machine, out of potentially hundreds, a container should run
  on — a question that doesn't exist when you only have one machine.
- **Desired state and reconciliation** — you declare what SHOULD be running; Kubernetes
  continuously works to make reality match that declaration, even after a machine fails.
- **Controllers** — automated processes that watch and correct drift from desired state (the
  generalized version of "restart it if it crashes," running constantly, across the whole
  cluster).
- **Service discovery at scale** — reaching "the right instance of a service" when there might
  be dozens of them, spread across many machines, changing constantly.
- **Health management** — automatically detecting an unhealthy container and replacing it,
  without a human first noticing something's wrong.
- **Scaling** — running more or fewer copies of something based on real demand, automatically.
- **Rollout strategies** — deploying a new version across many running instances safely, with a
  defined strategy for how to do it without an outage.
- **Distributed orchestration** — coordinating ALL of the above across a fleet of machines as if
  it were one system.

## The honest bridge

None of this makes Docker/containers obsolete — Kubernetes runs containers, using the exact
container runtime concepts this course just taught. Kubernetes is the layer ABOVE containers
that exists specifically because real production systems eventually need more than one machine,
more reliability than manual restarts, and more automation than a human watching dashboards. You
are not about to learn a replacement for what you just built — you're about to learn what
happens when you need to run it at a scale one machine can't handle.

## Instructor Notes

**Lesson goal:** Deliver the explicit "why Kubernetes" answer this entire foundational half of
ROOT_ has been building toward — students should be able to state, in their own words, what
specifically Kubernetes adds that Docker alone doesn't.

**Approximate timing:** 15 minutes read; 10 minutes live.

**Common misconception to watch for:** treating Kubernetes as "a replacement for Docker" rather
than "an orchestration layer that runs containers across many machines" — the container
concepts from this entire course remain fully applicable inside Kubernetes.

**Discussion question:** "Name one thing from this list (scheduling, desired state, controllers,
service discovery, health management, scaling, rollout, distributed orchestration) that would be
genuinely hard to do by hand with just `docker run` commands across many machines." (Almost any
honest answer works — the point is feeling the real gap Kubernetes fills, not memorizing the
list.)