When do you need a StatefulSet?

A StatefulSet creates pods named app-0, app-1 and so on, with a stable network identity through a headless Service. Each pod can claim its own PersistentVolume through volumeClaimTemplates, so storage follows the pod identity rather than the node.

• Creation and deletion are ordered by default; PodManagementPolicy can relax this
• Scaling down removes the highest ordinal first and keeps its PVC unless configured otherwise
• A headless Service provides per-pod DNS such as db-0.db.namespace.svc
• Rolling updates move from highest ordinal to lowest by default
• StatefulSets do not make an application highly available; quorum and replication are still your job

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: db
spec:
  serviceName: db-headless
  replicas: 3
  selector:
    matchLabels:
      app: db
  template:
    metadata:
      labels:
        app: db
    spec:
      containers:
        - name: db
          image: registry.example.com/db:16.2
          volumeMounts:
            - name: data
              mountPath: /var/lib/db
  volumeClaimTemplates:
    - metadata:
        name: data
      spec:
        accessModes: ["ReadWriteOnce"]
        resources:
          requests:
            storage: 50Gi

Stateful workloads require more operational care: backups, restore drills, failover testing and PVC lifecycle. Running a database on Kubernetes can be reasonable, but only if you own those practices rather than assuming the StatefulSet provides them.