Exercise 2: Why "Kubernetes Replaced Docker" Is Misleading — Possible Solution
====================================================================

Why it's misleading:

"Kubernetes replaced Docker" implies the two tools were direct
competitors doing the same job, and one simply won out over the
other. Per the chapter, this isn't accurate at all -- Kubernetes and
Docker operate at completely different layers and perform different
jobs: Kubernetes ORCHESTRATES containers (deciding what runs where,
handling failures, scaling, networking across a cluster), while a
container RUNTIME (which Docker itself is one example of, alongside
containerd) actually RUNS the containers on a given machine. One
doesn't substitute for the other -- Kubernetes still needs SOME
runtime underneath it to actually execute containers; it never did
away with the need for a runtime at all.

What actually changed, and what didn't:

Per the chapter's warn-box, what changed was narrower and more
technical than the headlines suggested: Kubernetes removed
"dockershim," an internal compatibility layer that let Kubernetes talk
specifically to the Docker daemon, in favor of using the Container
Runtime Interface (CRI) directly -- commonly running containerd
instead. This is a change to KUBERNETES' OWN internal plumbing for
talking to a runtime, not a statement that Docker itself stopped being
usable or relevant.

What did NOT change: Docker remains a widely used, fully supported
tool in its own right (for local development, building images, and
running containers outside a Kubernetes context). Container images
built with Docker remain completely compatible and usable inside a
Kubernetes cluster, because they follow the OCI (Open Container
Initiative) image standard -- a standard independent of which specific
runtime executes them.

The accurate relationship: Docker (or another OCI-compliant runtime)
runs individual containers; Kubernetes coordinates and manages many
containers, potentially using many different runtimes, across an
entire cluster of machines. They operate together at different layers
of the stack, not as competing alternatives to the same problem.

WHY THIS WORKS AS AN ANSWER
------------------------------
This distinguishes the chapter's own two separate claims -- Kubernetes
orchestrates vs. a runtime executes -- and applies the chapter's
specific dockershim-removal explanation to show that what actually
changed was a narrow, internal Kubernetes implementation detail, not
Docker's relevance or compatibility, directly countering the
misleading "replaced" framing.