Exercise 2: How Rolling Updates Avoid Downtime — Possible Solution
====================================================================

The core mechanism, per the chapter:

When a Deployment's pod template changes, Kubernetes does NOT simply
delete all the old pods and then create all the new ones -- that would
cause a visible gap with no healthy pods serving traffic at all.
Instead, it creates a NEW ReplicaSet with the updated template, and
gradually scales that NEW ReplicaSet up while scaling the OLD
ReplicaSet down, a few pods at a time, rather than all at once.

The role of maxSurge and maxUnavailable:

MAXSURGE controls how many EXTRA pods, beyond the originally desired
count, are allowed to exist temporarily during the rollout -- this
lets Kubernetes start bringing up new-version pods BEFORE it removes
old-version ones, rather than having to tear down capacity first and
rebuild it after.

MAXUNAVAILABLE controls how many pods are allowed to be UNAVAILABLE
at any single moment during the rollout -- capping how much capacity
can be removed at once, ensuring a meaningful number of pods (whether
old-version or new-version) remain up and serving traffic throughout
the entire transition.

Together, these two settings ensure that at every point during the
rollout, there is always SOME combination of old-version and
new-version pods actively running and available -- the rollout simply
shifts the BALANCE between old and new gradually, rather than ever
dropping to zero available pods at any point.

Why this avoids downtime:

Because a load balancer or Service (Chapter 6) routes traffic to
WHICHEVER pods are currently healthy and available -- regardless of
whether they happen to be running the old or new version at that exact
moment -- users continue being served throughout the entire rollout.
There is never a window where the total available pod count drops to
zero, which is precisely what would cause a visible outage. The
rollout completes once the new ReplicaSet reaches the full desired
replica count and the old ReplicaSet has been fully scaled down to
zero.

WHY THIS WORKS AS AN ANSWER
------------------------------
This explains the mechanism (gradual, simultaneous old-scale-down/
new-scale-up rather than delete-then-recreate) and then specifically
explains what maxSurge and maxUnavailable each individually control,
tying both back to the chapter's own core claim that "healthy pods are
always serving traffic throughout the transition" -- the reason
downtime doesn't occur.