Full lesson
Explore the full explanation, examples, and visuals at your own pace.
Same replica count, different identity guarantees
What changes when a database Pod dies? With a Deployment, its replacement gets a different generated name. A StatefulSet brings back the same ordinal, like db-1, so replica identity remains predictable.
A database replica may need
Replacing a database Pod can mean preserving its data, keeping its role identifiable, and coordinating with the other replicas—requirements a stateless API Pod usually avoids.
- Data that survives Pod replacement
- A stable identity for its role
- Coordination with other replicas
Deployment: three interchangeable Pods
The Deployment keeps three Pods behind the Service, which can route traffic to any of them. In this setup, they’re interchangeable: they don’t have stable individual identities or persistent volumes. If one is replaced, Kubernetes can create a new Pod, but its previous local data isn’t preserved.
StatefulSet: each Pod has its own claim
A StatefulSet gives each replica an ordinal identity: db-0, db-1, and db-2. Each mounts its own persistent volume claim, while the headless Service provides DNS names for discovery. If a Pod is replaced, Kubernetes can reconnect that identity to its associated claim, preserving its storage.
If db-1 is replaced in this StatefulSet, which storage should the new db-1 use?
Let's think this through. If db-1 is replaced in this StatefulSet, which storage should the new db-1 use? A: The existing claim for db-1. B: The claim belonging to db-0. C: A fresh claim with no previous data. Choose an answer, or just think it through. I'll explain in a moment.
- The existing claim for db-1
- The claim belonging to db-0
- A fresh claim with no previous data
If db-1 is replaced in this StatefulSet, which storage should the new db-1 use?
The answer is A: The existing claim for db-1. The claim is associated with the stable ordinal identity db-1, so its replacement uses that existing claim. Recreating a Pod does not normally mean assigning it another replica's claim or starting with an empty one.
- The existing claim for db-1
- The claim belonging to db-0
- A fresh claim with no previous data
StatefulSet spec excerpt
This excerpt configures three Pods. serviceName refers to a separately configured headless Service, which supports stable Pod DNS names. volumeClaimTemplates provides one claim per Pod, giving each ordinal its own storage. The Pod template itself isn’t shown.
replicas: 3
serviceName: db
volumeClaimTemplates:
- metadata:
name: data
spec:
accessModes: [ReadWriteOnce]
resources:
requests:
storage: 1GiReplace db-1, reconnect its claim
When db-1 disappears, the controller notices and recreates db-1 with the same ordinal identity. The replacement mounts the existing PVC 1, making its associated storage available again. That preserves the claim-to-replica relationship; it doesn’t prove the database process recovered cleanly or that its data is consistent.
What StatefulSets do not solve
A Deployment can mount persistent volumes too. StatefulSets pair replicas with stable identities and claims; they don't provide database replication, backups, data correctness, or guaranteed recovery from storage or scheduling failures.
- Database replication or failover
- Backups or data correctness
- Every storage and scheduling failure
Identity and storage stay paired
Identity and storage stay paired. Each Pod reconnects to its own claim, so a replacement can return with the same identity and storage.