StatefulSets

Stable Identity for Stateful Workloads

Databases and brokers care about who they are: peers must locate each other, and each member owns its own data. Deployments give interchangeable pods with random suffixes; StatefulSets give ordinal identity.

Pods are named <set>-<ordinal> — mysql-0, mysql-1, mysql-2 — and a governing headless Service (clusterIP: None) publishes DNS records such as mysql-0.mysql.ns.svc.cluster.local. Under the default OrderedReady policy, scaling down removes the highest ordinal first, and scaling up creates each pod only after the previous one is Running and Ready.

Each ordinal mounts its own PVC from volumeClaimTemplates, so data follows identity instead of following the node.

Spec Shape

apiVersion: apps/v1
kind: StatefulSet
metadata: { name: mysql }
spec:
  serviceName: mysql
  replicas: 3
  podManagementPolicy: OrderedReady
  updateStrategy: { type: RollingUpdate }
  selector: { matchLabels: { app: mysql } }
  template:
    metadata: { labels: { app: mysql } }
    spec:
      containers:
      - name: mysql
        image: mysql:8.4
        ports: [{ containerPort: 3306 }]
        volumeMounts: [{ name: data, mountPath: /var/lib/mysql }]
  volumeClaimTemplates:
  - metadata: { name: data }
    spec:
      accessModes: [ReadWriteOnce]
      resources: { requests: { storage: 10Gi } }

serviceName must reference a headless Service; per-pod DNS entries appear only once pods run.

Pitfalls and Interview Angles

Pitfall 1 — PVC lifecycle surprises. Deleting the StatefulSet leaves its PVCs behind by default (deliberate: data survives), but recreating the set with the same name rebinds those volumes — including stale schema or single-writer data from a previous incarnation.

Pitfall 2 — careless rolling upgrades. Restarting clustered stores pod-by-pod can still break quorum when combined with parallel pod management or aggressive readiness. For systems like etcd or Kafka, consider OnDelete and roll manually after checking cluster health.

Interview-ready: state the guarantees — stable network identity, stable storage, ordered deployment and termination — explain the headless Service's role, and pair upgrades with PodDisruptionBudgets so drains never empty a quorum.