A StatefulSet is a Kubernetes resource for running pods whose individual identities and stored data matter. Like a Deployment, it uses a pod template, replica count, and label selector. Unlike a Deployment, it gives each replica an ordinal name and can create a separate PersistentVolumeClaim for it. A replacement pod keeps the replica’s name and claim rather than starting as an interchangeable copy. section 16.1.2 section 16.2.1
To give each pod a stable network name, associate the StatefulSet with a headless Service. The Service creates a DNS record for each pod; if a replacement receives a different IP address, its record points to the new address. In a Service manifest, `clusterIP: None` makes it headless. Set `publishNotReadyAddresses: true` when pods must find one another before they become ready. section 16.1.3 section 16.2.1
Listing 16.1 Headless Service for the quiz StatefulSet
apiVersion: v1
kind: Service
metadata:
name: quiz-pods #1
spec:
clusterIP: None #2
publishNotReadyAddresses: true #3
selector: #4
app: quiz #4
ports: #5
- name: mongodb #5
port: 27017 #5
The headless Service manifest shows the settings that expose individual quiz pods, including pods that are not yet ready. section 16.1.3
Run a three-replica quiz service
Create the headless Service first, then apply a StatefulSet with `serviceName: quiz-pods`, `replicas: 3`, and a PersistentVolumeClaim template. Inspect it with `kubectl get sts`, `kubectl get pods -l app=quiz`, and `kubectl get pvc -l app=quiz`: the pods are `quiz-0` through `quiz-2`, each with its own claim. Here, MongoDB replication must also be initiated before the application’s readiness checks pass. The manifest uses `podManagementPolicy: Parallel` so all three pods can be created without waiting for earlier pods to become ready. section 16.1.3 section 16.1.4
Identity affects everyday operations:
- Deleting a pod causes the controller to recreate that ordinal with the same claim. Check its hostname rather than relying on its old IP address. section 16.2.1
- A disconnected node needs care: the old pod may still be running. Force deletion does not confirm that its process stopped, and a replacement may be unable to attach the volume. section 16.2.2
- Pod creation normally follows ascending ordinals, while deletion follows the reverse order; the pod management policy can change whether these operations proceed sequentially or simultaneously. A claim-retention policy controls whether claims survive scale-down or StatefulSet deletion. section 16.5
Updating the pod template also follows a deliberate pattern. The default `RollingUpdate` replaces pods one at a time, from highest ordinal to lowest, waiting for each new pod to become ready. `OnDelete` instead waits for you to delete each pod. For a staged or canary update, set a RollingUpdate partition: pods below that ordinal stay on the old template. With three replicas, partition `2` updates only pod `2`; lowering it continues the rollout. section 16.3 section 16.3.2
