StatefulSets: Stable Identity and Ordered Startup

Workloads / Guide 28 of 103 / Intermediate

• Kubernetes1.36.4
• Cluster4 nodes
• Runtimecontainerd 2.2.6
• CNICalico v3.32.1
• TimeAbout 40 min

PV names, UIDs and addresses are generated per run. The StorageClass here is local-path; any dynamic provisioner behaves the same for this exercise.

• StorageClasslocal-path (default)

This guide includes

Use this when a workload's Pods are not interchangeable - a database, a queue, anything where one replica owns its data. This matters because identity needs a name that resolves, so a StatefulSet is always two objects rather than one.

• pairing a StatefulSet with a headless Service so its Pods get DNS names, and resolving a per-Pod name through it
• seeing ordinal names and staggered ages rather than random suffixes created all at once
• getting one PersistentVolumeClaim per Pod without writing a single one
• deleting a Pod and watching it come back as itself, with its own volume
• finding the PVCs still Bound after the StatefulSet is gone, and cleaning them up separately

Before you start

• A cluster with a default StorageClass. Check with kubectl get sc; without one, volumeClaimTemplates produce PVCs that stay Pending forever.
• The Deployments guide. The contrast with a Deployment is the point of this one.
• Enough room for three small volumes. This uses 64Mi each.

1. 1

   Two objects, because identity needs a name to resolve

2. 2

   Numbered names and staggered ages

3. 3

   One volume per Pod, provisioned automatically

4. 4

   Per-Pod DNS from the headless Service

5. 5

   Delete a Pod and watch it come back as itself

6. 6

   The PVCs outlive the StatefulSet

7. 7

   Clean up, storage included

Official sources

• StatefulSets
• Headless Services
• StatefulSet basics tutorial
• PersistentVolumeClaim retention