How does a StatefulSet give stable identity and storage?

WHAT THIS TESTS Whether you understand the concrete mechanisms, headless Service plus volumeClaimTemplates, that produce StatefulSet guarantees, and why a clustered database needs them.

A GOOD ANSWER COVERS Stable network identity has two parts. First, the StatefulSet names Pods deterministically by ordinal, like mysql-0, mysql-1, and a Pod keeps its name through restarts and reschedules even though its IP changes. Second, you pair the StatefulSet with a headless Service, one with clusterIP None, which causes DNS to publish a per-Pod A record at a predictable hostname such as mysql-0.mysql.namespace.svc.cluster.local. Peers address each other by these stable names rather than ephemeral IPs. Stable storage comes from volumeClaimTemplates: the controller creates a separate PVC for each Pod ordinal, and that PVC, and thus its data, stays associated with the same ordinal. If mysql-1 is rescheduled to another node, it reattaches the same volume. For a clustered database this is essential because replicas must know each other's identities to form quorum and replicate, and each replica must retain its own on-disk dataset rather than start empty after a move.

COMMON WRONG ANSWERS Attributing stable hostnames to an ordinary ClusterIP Service. Thinking all Pods share one PVC. Believing identity is based on IP. Forgetting the headless Service is required.

LIKELY FOLLOW-UPS Why must the Service be headless? What DNS name format is produced? What happens to the PVC if you scale down then up? How does ordered startup help a database bootstrap?

ONE CONCRETE EXAMPLE A MongoDB replica set runs as a StatefulSet; each member configures peers using stable DNS names like mongo-0.mongo and mongo-1.mongo, and when mongo-1 reschedules it reattaches its own volume, so it rejoins with its existing data and oplog intact.