Exercise 2: What a Headless Service Is, and Why StatefulSets Need One — Possible Solution
====================================================================

What a headless Service is:

Per the chapter, it's a Service created with `clusterIP: None`. Rather
than being assigned its own single, stable cluster IP that traffic
gets load-balanced across (the normal Service behavior), a headless
Service instead causes Kubernetes to create a DNS record for EACH
INDIVIDUAL matching pod directly -- for example, `db-0.db-service.
namespace.svc.cluster.local` for one specific pod, a separate distinct
record for `db-1`, and so on.

Why a StatefulSet typically needs one:

Per `k8s1-6`, a NORMAL Service's entire purpose is to provide ONE
stable address that transparently LOAD-BALANCES traffic across
WHICHEVER matching pods happen to be currently healthy -- deliberately
hiding which SPECIFIC pod actually handled any given request, since
for a stateless application, any healthy pod is equally suitable to
handle any given request.

A StatefulSet's pods, per this chapter, are explicitly NOT
interchangeable in that way -- each one has a distinct identity and
potentially a distinct ROLE (a primary vs. a replica, for instance).
If a StatefulSet used a normal, load-balancing Service, a client
trying to specifically reach `db-0` (the primary, say, to send a
write) would have NO WAY to guarantee their request actually reached
`db-0` specifically -- the Service would transparently route it to
whichever pod happened to be selected by its load-balancing logic,
potentially a replica that shouldn't be receiving writes at all.

A headless Service solves this by giving each pod ITS OWN distinct DNS
name, letting other parts of the system explicitly address `db-0`
specifically (or `db-1`, or `db-2`) by name, bypassing any
load-balancing entirely -- exactly what's needed when it genuinely
matters WHICH specific replica a request goes to, not just "any
healthy one."

The contrast, stated directly: a normal Service answers "route me to
ANY healthy matching pod" -- a headless Service answers "let me reach
THIS SPECIFIC pod, by its own stable name."

WHY THIS WORKS AS AN ANSWER
------------------------------
This defines the headless Service mechanically (per-pod DNS records
instead of one load-balanced address) and then explains WHY that
specific behavior is required for StatefulSets by contrasting it
directly against the normal Service behavior from `k8s1-6`, using the
primary-vs-replica example the chapter itself sets up as the concrete
motivating scenario.