Exercise 1: Deployment, ReplicaSet, and Pod — Who Manages Whom — Possible Solution
====================================================================

The management relationship, per the chapter:

A DEPLOYMENT manages one or more REPLICASETS. A REPLICASET manages a
set of PODS. This is a layered chain: Deployment -> ReplicaSet -> Pod,
each layer managing the one directly beneath it.

Specifically: the ReplicaSet's job is to ensure a specified NUMBER of
pods matching its template exist at all times, using label selectors
to identify which pods belong to it. The Deployment's job is one level
up -- it manages the ReplicaSet(s) underneath it, specifically handling
the TRANSITION between different versions of a ReplicaSet (rolling
updates) and keeping a history for rollback, rather than directly
tracking individual pods itself.

Why create a Deployment rather than a ReplicaSet or a bare Pod
directly:

A BARE POD has no protection at all -- per Chapter 3's own material,
if it fails or its node dies, nothing automatically replaces it. You'd
have to notice and recreate it manually.

A REPLICASET on its own DOES provide self-healing (maintaining N
copies) -- but per the chapter, it has no built-in mechanism for
managing a controlled TRANSITION between an old version and a new one.
Updating a ReplicaSet's template directly doesn't trigger the kind of
gradual, rolling, zero-downtime transition described in this chapter
-- that capability specifically belongs to the Deployment layer above
it, along with the revision history that makes `kubectl rollout undo`
possible.

A DEPLOYMENT gives you BOTH the self-healing property (inherited from
the ReplicaSet it manages) AND safe, controlled version transitions
with rollback -- which is why, per the chapter, "you rarely create a
ReplicaSet directly" and almost always work through a Deployment
instead, even though ReplicaSets are the layer actually doing the
pod-count enforcement underneath.

WHY THIS WORKS AS AN ANSWER
------------------------------
This states the exact management chain (Deployment -> ReplicaSet ->
Pod) the chapter describes, and then justifies the practical
recommendation to use Deployments by contrasting what EACH layer does
and doesn't provide on its own -- bare pods lack self-healing entirely,
ReplicaSets provide self-healing but not version-transition
management, and only Deployments provide both.