Exercise 3: Three Instances of the Reconciliation Loop Across Course 1 — Possible Solution
====================================================================

The reconciliation loop, per Chapter 2: observe current state, compare
against desired state, act to reconcile any difference, repeat
forever. Three instances of this exact pattern, showing up in
genuinely different guises across the course:

1. REPLICASETS MAINTAINING POD COUNT (Chapter 5). The desired state is
   a specific NUMBER of pods matching a template. The controller
   continuously observes how many matching pods actually exist,
   compares that to the desired replica count, and creates or deletes
   pods to reconcile any difference -- this is the mechanism behind
   both self-healing (replacing a failed pod) and scaling (adjusting
   the count).

2. SERVICES MAINTAINING THEIR ENDPOINTS LIST (Chapter 6). The desired
   state is "route traffic to whichever pods currently match this
   label selector and are healthy." The Service continuously observes
   which pods currently match, and updates its Endpoints list to
   reconcile that observation against what it should be routing to --
   automatically adding newly-created matching pods and removing
   deleted or unhealthy ones, with no manual intervention.

3. LIVENESS PROBES DECIDING WHETHER TO RESTART A CONTAINER (Chapter
   11). The desired state is "this container is functioning
   correctly." The kubelet continuously observes the container's
   actual health (via the probe), compares it against the expectation
   that it should be passing, and takes action (restarting the
   container) to reconcile a failure -- the exact same observe-
   compare-act-repeat structure, just applied at the individual
   container-health level rather than the pod-count or Service-
   routing level.

(A fourth valid example: `kubectl apply`'s own idempotent behavior from
Chapter 4 -- comparing a manifest's desired state against what's
currently deployed and only acting on genuine differences, the same
loop applied to the act of applying configuration itself.)

What they have in common:

Despite operating on completely different kinds of resources (pod
COUNT, a Service's ENDPOINTS LIST, an individual CONTAINER's health),
all three are built from the exact same underlying structure: continuously
watch reality, compare it against a stated intention, and correct any
gap automatically, without a human needing to notice the gap and
intervene manually each time. This is precisely why Chapter 2 called
the reconciliation loop "Kubernetes' Core Mechanism" and predicted that
"nearly everything else in the course is a variation on it" -- these
examples confirm that prediction held true across pod management,
networking, and health checking alike.

WHY THIS WORKS AS AN ANSWER
------------------------------
Each example names a genuinely different Kubernetes resource/concept
(ReplicaSets, Services, liveness probes) rather than three variations
on the same one, and the closing "what they have in common" section
explicitly restates the observe-compare-act structure shared across
all three, directly confirming Chapter 2's own stated prediction that
this pattern would recur throughout the course.