Exercise 3: The Reconciliation Loop, Explained and Applied to a New Example — Possible Solution
====================================================================

The reconciliation loop, in my own words:

A Kubernetes controller doesn't just set something up once and walk
away -- it runs a continuous cycle, forever: it looks at what's
ACTUALLY happening in the cluster right now, compares that against
what the stored configuration says SHOULD be happening, and if there's
any difference between the two, it takes action to correct that
difference. Then it repeats this exact process again, indefinitely.
This is what lets Kubernetes automatically keep the real state of the
cluster matching the intended state, without a human needing to
notice a problem and manually fix it every single time something
drifts.

A new example not explicitly covered in the chapter:

Imagine a Kubernetes cluster is configured (via a Deployment, briefly
mentioned as upcoming in Chapter 5) to always have exactly 3 copies of
a web server running. Suppose the node one of those 3 copies is
running on suddenly loses network connectivity and becomes unreachable
by the control plane.

- OBSERVE: the relevant controller notices, through its continuous
  watching, that only 2 of the 3 required copies are currently
  reporting as healthy and running (the third is unreachable and
  presumed failed).

- COMPARE: the desired state, stored in etcd, still says "3 copies
  should be running." The observed actual state is now "2 copies
  running." There's a difference.

- ACT: the controller automatically creates a new, replacement copy
  of the web server and has it scheduled onto a different, healthy
  node -- without anyone needing to notice the node failure or
  manually intervene to request a replacement.

- REPEAT: the loop continues watching indefinitely; once the
  replacement pod is running, actual state (3 copies running again)
  matches desired state (3 copies), and the loop simply keeps
  confirming this remains true going forward.

This is a genuine example of the SAME loop mechanism the chapter
describes, applied to a scenario (node failure triggering automatic
pod replacement) the chapter itself flagged as one of the later
applications of this concept (Chapters 5 and 11's self-healing
material) without walking through the specific mechanics in Chapter 2
itself.

WHY THIS WORKS AS AN ANSWER
------------------------------
This restates the chapter's own observe-compare-act-repeat structure
in plain language, then applies it faithfully to a concrete, novel
scenario (a node failure triggering automatic pod replacement) that
uses the exact same mechanism the chapter describes but wasn't spelled
out in this specific chapter's own text -- demonstrating genuine
understanding of the pattern rather than just repeating the chapter's
own wording back.