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]>
3.6 KiB
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.)