Kubernetes StatefulSets: Stable Identity, Persistent Storage, and When to Use Them

What makes pods "stateful"

A Deployment's pods are interchangeable — any pod can handle any request, and Kubernetes can kill and replace them in any order. When a pod is replaced, it starts fresh with no memory of the previous pod.

A StatefulSet's pods are not interchangeable:

• Each has a stable name: redis-0, redis-1, redis-2 (not random hashes).
• Each has a stable DNS record: redis-0.redis-svc.namespace.svc.cluster.local.
• Each has its own PersistentVolume that is bound to that pod's identity — if redis-0 is rescheduled to a different node, Kubernetes mounts the same PVC to the new pod.

This matters for clustered databases. A Redis Cluster node or a Kafka broker needs a stable address because other nodes store its address in their configuration. If the pod's address changes on reschedule, the cluster breaks.

A StatefulSet for Redis Sentinel

apiVersion: v1
kind: Service
metadata:
  name: redis-svc
spec:
  clusterIP: None  # headless — returns pod IPs directly, no load balancing
  selector:
    app: redis
  ports:
  - port: 6379
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: redis
spec:
  serviceName: redis-svc  # must reference the headless service
  replicas: 3
  selector:
    matchLabels:
      app: redis
  template:
    metadata:
      labels:
        app: redis
    spec:
      containers:
      - name: redis
        image: redis:7.0
        volumeMounts:
        - name: data
          mountPath: /data
  volumeClaimTemplates:  # creates a PVC per pod
  - metadata:
      name: data
    spec:
      accessModes: ["ReadWriteOnce"]
      storageClassName: gp3
      resources:
        requests:
          storage: 10Gi

This creates:

• redis-0 with PVC data-redis-0
• redis-1 with PVC data-redis-1
• redis-2 with PVC data-redis-2

DNS records: redis-0.redis-svc.default.svc.cluster.local, etc.

If redis-1 is evicted and rescheduled on another node, it remounts data-redis-1 and resumes from where it left off.

Ordered startup and why it matters

StatefulSets start pods sequentially: redis-0 must be Running and Ready before redis-1 starts. This is critical for clustered applications that require a specific initialization sequence.

For a database cluster (PostgreSQL with Patroni, MySQL with InnoDB Cluster), the first pod initializes as the primary. Subsequent pods join as replicas. If they all start simultaneously before the primary is ready, each tries to initialize as primary and the cluster is corrupted.

# Watch ordered startup
kubectl get pods -w
NAME      READY   STATUS    RESTARTS
redis-0   0/1     Pending   0          ← starts first
redis-0   1/1     Running   0
redis-1   0/1     Pending   0          ← starts after redis-0 is Ready
redis-1   1/1     Running   0
redis-2   0/1     Pending   0
redis-2   1/1     Running   0

For workloads that do not need ordered startup (multiple independent Cassandra nodes), set podManagementPolicy: Parallel to start all pods simultaneously.

# After scaling down StatefulSet to 2:
kubectl get pvc
NAME           STATUS   VOLUME    CAPACITY   ...
data-redis-0   Bound    pv-abc    10Gi       ← still in use
data-redis-1   Bound    pv-def    10Gi       ← still in use
data-redis-2   Bound    pv-ghi    10Gi       ← orphaned, costs money

kubectl delete pvc data-redis-2  # manual cleanup required