Exercise 3: Pets vs. Cattle, and Why Hardcoded Pod IPs Break — Possible Solution
====================================================================

The "pets vs. cattle" mental model, in my own words:

In a "pets" mindset, you treat individual servers as unique, valued,
carefully-maintained things -- you give them names, patch them
individually, nurse them back to health when something goes wrong, and
would be genuinely upset if one had to be replaced, because it took
real ongoing effort to keep it running exactly as configured.

In a "cattle" mindset, individual instances are interchangeable and
disposable -- if one has a problem, you don't try to diagnose and
repair that SPECIFIC one; you simply remove it and replace it with a
fresh, identical one, with no particular attachment to which specific
instance is running at any given moment. What matters is that the
RIGHT NUMBER of healthy instances exist, not which specific ones they
are.

Per the chapter, Kubernetes pods are explicitly "cattle" -- when a pod
fails or its node dies, "Kubernetes generally doesn't try to repair
the existing pod -- it creates a brand new one to replace it,
typically with a new name and often a new IP address."

Why hardcoding a pod's IP address breaks in practice:

Because pods are treated as disposable cattle, NOTHING about a
specific pod's identity -- including its IP address -- is guaranteed to
stay the same over time. A pod can be replaced for many reasons
entirely outside an application's control: the node it was running on
fails, it's evicted for resource reasons, it crashes and gets
restarted, or it's simply replaced as part of a routine rolling update
(Chapter 5). Every one of these events can result in a pod with a
DIFFERENT IP address taking its place.

If an application hardcodes a specific pod's IP address to connect to
it, that hardcoded address is only valid until the NEXT time that pod
happens to be replaced -- which, per the chapter's own framing, could
happen at literally any time, unpredictably. Once replaced, the
hardcoded IP simply points at nothing (or worse, at whatever pod
happens to get assigned that IP later), and the connection breaks.
This is exactly the problem the chapter names Chapter 6's Services as
existing specifically to solve -- providing a stable way to reach a
group of pods regardless of which specific pods, or IP addresses,
currently make up that group.

WHY THIS WORKS AS AN ANSWER
------------------------------
This restates the pets-vs-cattle metaphor in concrete, relatable terms
(individual attention and repair vs. disposability and replacement),
then traces the specific causal chain from "pods get replaced
unpredictably" to "a hardcoded IP eventually points at nothing" --
directly matching the chapter's own warn-box reasoning and its
explicit forward pointer to why Services exist.