Exercise 3: Manually Deleting a Deployment-Managed Pod — What Happens Next — Possible Solution
====================================================================

What happens: a NEW, replacement pod is automatically created within
moments, restoring the count back to 3 -- the deleted pod is NOT
"undeleted," but the total number of running pods matching the
Deployment's template returns to the desired count.

Why, step by step, per this chapter's own self-healing material:

1. The Deployment (via the ReplicaSet it manages) has declared that
   3 pods matching its label selector should exist at all times --
   this desired state is recorded and continuously monitored, per
   Chapter 2's reconciliation loop.

2. The user's `kubectl delete pod` command removes one specific pod
   directly. This is a real, immediate action -- that specific pod IS
   deleted.

3. The ReplicaSet's own reconciliation loop, which continuously
   observes the actual number of matching pods against the desired
   count of 3, notices that only 2 pods now exist where 3 should.

4. Per the chapter, "if a pod managed by a ReplicaSet dies or is
   deleted, the ReplicaSet's own reconciliation loop notices the
   actual count has dropped below the desired count, and creates a
   replacement automatically." The ReplicaSet creates a brand NEW pod
   (with a new name, matching Chapter 3's "pods are disposable, not
   repaired" material) to bring the count back up to 3.

5. This all happens automatically, without the user (or anyone else)
   needing to notice the deletion and manually recreate anything --
   simply because the Deployment/ReplicaSet had already declared "3
   should exist" as an ongoing, continuously-enforced desired state,
   not a one-time setup action.

The key insight: manually deleting a Deployment-managed pod doesn't
actually reduce the Deployment's effective capacity for more than a
brief moment -- it just triggers the same self-healing mechanism that
would also kick in for a genuine failure (a crash, a node going down),
because from the ReplicaSet's perspective, a manually-deleted pod and
a pod that failed on its own look identical: both are simply "a pod
that used to exist and no longer matches the desired count."

WHY THIS WORKS AS AN ANSWER
------------------------------
This traces the exact reconciliation-loop mechanism the chapter
describes for self-healing, applied specifically to a MANUAL deletion
rather than a genuine failure -- making the point explicit that the
ReplicaSet doesn't distinguish between the two causes; it only cares
about the gap between actual and desired count, which is exactly why
manual deletion triggers the identical automatic-replacement behavior
a real failure would.