When You Outgrow a Single Host → Kubernetes

This is the boundary the whole book has held to, now crossed and named. Docker builds and runs containers on one host; Kubernetes orchestrates them across many. Everything in this course — the image, the layers, the network, the volumes, the hardening — was the work of making one container right on one machine.

When you need that container running reliably across a fleet, the job changes shape, and Kubernetes is where this course hands off to its sibling. This topic draws the line precisely and points across it. It does not teach Kubernetes — that is the Kubernetes Deep Dive course, which assumes exactly the good image this book taught you to build.

The Contract Sentence

Docker is build-and-run on a single host; Kubernetes is orchestration across many. The dividing line is not "small versus large" — it is "one machine's daemon versus a scheduler placing work over a cluster." Recognizing which problem you actually have is the first decision, and it is more often answered wrong by adopting too much than too little. If one host holds your workload, you do not have an orchestration problem yet.

What One Host Can't Give You

A single Docker host can restart a crashed container, but four things sit beyond its reach. It cannot reschedule work when the whole node dies — a restart policy is useless if the machine running it is gone. It cannot schedule across many machines by capacity. It cannot roll out a new version across a fleet without downtime. And it cannot hold a declared desired state that the cluster continuously reconciles toward. Those are orchestration problems, and they begin precisely where one host ends.

Kubernetes Runs the Same Images You Built

Kubernetes does not ask you to rebuild anything. It pulls the exact OCI driftwood/web image you built, scanned, signed, and pushed, and runs it via containerd — the runtime from topic 73. The build work in this book is the input to the orchestration work in the next, unchanged. If you find yourself rebuilding an image to "make it Kubernetes-ready," you have misread the boundary: a good OCI image already is ready.

Compose and Swarm as the Stepping Stones

The path through this book has been a gradient. Compose declared multi-container intent on one host; Swarm stretched that same declarative idea across a few nodes; Kubernetes generalizes it to a fleet with self-healing, autoscaling, and a full ecosystem. The mental model — declare the desired state, let the system reconcile toward it — is identical at each step. Only the scope grows, from one machine to several to many.

The Hand-Off

When self-healing across nodes, multi-node scheduling, fleet-scale rolling deploys, or declarative desired-state become requirements rather than nice-to-haves, the right next move is the Kubernetes Deep Dive course. It starts exactly where this boundary ends, and it assumes the hardened, slim, signed image this book taught you to build. The build-and-run job is finished here; the orchestrate-across-many job begins there.

Stay on a single host until a concrete need forces the move, and carry the exact image forward when it does. The discipline this course drilled — multi-stage builds, non-root users, scanning, signing, digest pinning — is not wasted at the boundary; Kubernetes magnifies a good image and magnifies a bad one equally. The next topic walks that whole single-host pipeline end to end before the hand-off.