Run Stateful Workloads with StatefulSets

Why this matters

A database that loses its disk or its name on reschedule is a data-loss incident wearing a scheduling costume. StatefulSets bind identity (web-0, web-1) to storage (one PVC per pod from the template) so rescheduling reattaches rather than reinvents. The ordering guarantees slow things down deliberately: data safety first, speed second.

Concepts

Each replica gets a stable hostname plus a stable claim: volumeClaimTemplates provisions one PVC per pod (data-web-0, data-web-1) from the named StorageClass, and re-created pods reclaim their own claim. Scaling is ordered (0 up, N down), updates are ordered with optional partitioning (updateStrategy.rollingUpdate.partition) so canary-style caution applies to state too. Headless Service membership gives stable DNS names for peer discovery.

Growth means expanding each claim (the expansion drill from the last lesson, per pod) and letting the filesystem follow. Protection means backups outside the cluster plus reclaim Retain on anything precious: deleting a StatefulSet never deletes its PVCs by design, and that asymmetry has saved more data than any runbook.

Worked example

Three replicas, one gigabyte each to start, ordered and stable:

apiVersion: apps/v1
kind: StatefulSet
metadata: { name: data, namespace: demo }
spec:
  serviceName: data-peers
  replicas: 3
  selector: { matchLabels: { app: data } }
  template:
    metadata: { labels: { app: data } }
    spec:
      containers:
      - name: store
        image: store:1.0
        volumeMounts: [{ name: data, mountPath: /var/lib/store }]
  volumeClaimTemplates:
  - metadata: { name: data }
    spec:
      accessModes: [ReadWriteOnce]
      resources: { requests: { storage: 1Gi } }

kubectl get pvc shows data-data-0 through data-data-2. Delete pod data-1 and watch it return with the same claim and the same data: identity plus storage surviving reschedule is the entire proof.

Exam notes

The headless Service must exist before the pods or DNS names lag behind: create it first, always. Scaling to zero keeps every PVC: data waits, costs accrue, nothing is lost. And partitioned updates (partition: 2) hold the tail back while the head proves the new version: stateful canary without extra tooling.