Exercise 2: The Full kubectl apply Architecture Walkthrough — Possible Solution
====================================================================

This directly reproduces and explains the chapter's own six-step flow:

1. `kubectl apply` sends the pod's desired configuration (typically a
   YAML manifest) as a request to the API SERVER -- the single entry
   point for all cluster communication, per the chapter.

2. The API server VALIDATES the request (checking it's well-formed and
   permitted) and, once accepted, WRITES the desired state to ETCD --
   the cluster's single source of truth. At this point, the new pod
   exists as a recorded intention, but nothing is actually running
   yet.

3. The SCHEDULER continuously watches for pods that exist in etcd but
   have no node assigned yet. It notices this new, unscheduled pod,
   evaluates which available node best fits its resource requirements
   and constraints, and assigns it to that node -- writing this
   scheduling decision back to etcd via the API server.

4. The KUBELET running on that specific assigned node is itself
   continuously watching the API server for pods assigned to ITS
   node. It notices the newly assigned pod.

5. The kubelet instructs the CONTAINER RUNTIME (containerd) on that
   node to actually pull the required container image (if not already
   cached locally) and start the container(s) described in the pod
   spec.

6. The kubelet continuously monitors the actual running state of the
   pod on its node, and reports that status back through the API
   server -- updating etcd's record of the pod's ACTUAL state, closing
   the loop between "what was requested" and "what's actually
   happening."

At the end of this sequence, the pod that started as a single YAML
manifest submitted via `kubectl apply` is now an actual running
container on a specific node, with the cluster's own state (in etcd)
accurately reflecting that reality.

WHY THIS WORKS AS AN ANSWER
------------------------------
This walks through the chapter's own six-step diagram in full,
explicitly naming which architecture component (API server, etcd,
scheduler, kubelet, container runtime) is responsible for each step --
demonstrating that every component introduced earlier in the chapter
has a specific, traceable role in this one concrete, end-to-end
example.