Kubernetes Workloads
StatefulSets — Running Stateful Applications
Handling stable network identifiers and dedicated disk persistent volumes.
Interview: StatefulSets are essential for database deployments. Focus on explaining how they differ from Deployments: stable ordinal network identities (pod-0, pod-1), stable storage bindings that persist even after a pod is deleted, headless services, and strict sequential scaling.
Why StatefulSets?
Deployments are designed for stateless applications where all Pods are identical and share the same storage. If a Pod is rescheduled, it doesn't matter which node it lands on, and it can attach to any shared directory.
For stateful applications like databases (Postgres, MySQL) or distributed coordination engines (ZooKeeper, Kafka, Elasticsearch), this model fails. Each instance requires a unique, stable identity and its own dedicated disk storage. **StatefulSets** provide these capabilities.
Core Characteristics of StatefulSets
StatefulSets differ from Deployments in three key areas:
- Stable Ordinal Indexes: Pods are created sequentially starting from 0 to N-1 (e.g.
db-0,db-1,db-2). Scaling up is done sequentially (e.g.,db-1only starts oncedb-0is healthy), and scaling down is done in reverse order (terminating the highest index first). - Headless Service & Stable DNS: Requires a Headless Service (a Service with
clusterIP: None) to publish individual DNS SRV records for each Pod (e.g.,db-0.db-service.default.svc.cluster.local). This allows client nodes or master/replica databases to communicate directly with specific pods. - Volume Claim Templates: Instead of mapping all Pods to the same PVC, a StatefulSet uses a
volumeClaimTemplatesblock to automatically provision a unique, dedicated Persistent Volume Claim (PVC) and physical disk for each replica. When a Pod is rescheduled or restarted, it automatically binds back to its exact same physical storage.