ced4568andClaude Sonnet 5
682ef2de47
Adds all 8 ROOT 04 modules (why containers exist, images & containers, Docker CLI, container networking, container storage, Dockerfile & image build, Docker Compose, containers → Kubernetes) — 43 activities, using the nested Docker Engine Phase 6D built and tested. Modules 1, 2, and 8 are conceptual (no lab by design) — the honest bridge module (M8) explicitly names what Kubernetes adds beyond what this course already taught, without re-teaching Kubernetes itself. Adds 5 new hands-on Docker scenarios plus 2 MCQs, all against the real nested Docker Engine: docker-cli-basics (run/exec/inspect a real container), docker-container-networking (a genuine "works internally, unreachable from host" port-publishing failure, diagnosed and fixed by recreating the container with the correct `-p` flag), docker-container-storage (a real destroy/recreate cycle proving named-volume persistence, not just described), docker-build-image (a real Dockerfile, a real build, a real custom image run), and docker-compose-multiservice (a real two-service Compose application with a real published port). All tested end-to-end via the real scenario-validation API, including negative tests. Wires rootnode-containers-assessment (2 required + 4 random-draw scenarios) using the existing Phase 3B assessment engine. This completes the entire ROOT_ Foundations sequence (ROOT 01-04) — see docs/PHASE6E_ROOT_FOUNDATIONS_COMPLETION.md. Co-Authored-By: Claude Sonnet 5 <[email protected]>
65 lines
3.6 KiB
Markdown
65 lines
3.6 KiB
Markdown
# 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.)
|