What is a Kubernetes StatefulSet?
Learn what a Kubernetes StatefulSet is, how stable identity and per-Pod storage work, and when to use it over a Deployment.
Expected Interview Answer
A StatefulSet manages Pods that need a stable, unique network identity and stable, persistent storage across restarts — each Pod gets a predictable name and its own PersistentVolumeClaim that survives rescheduling, unlike the interchangeable Pods a Deployment manages.
Pods created by a StatefulSet are named with an ordinal suffix, such as `mysql-0`, `mysql-1`, `mysql-2`, and are created, scaled, and terminated in strict, predictable order rather than in parallel. Each Pod gets its own PersistentVolumeClaim generated from a `volumeClaimTemplate`, so `mysql-1` always reattaches to the same volume it had before, even after being rescheduled to a different node. A headless Service (`clusterIP: None`) gives each Pod a stable DNS name like `mysql-1.mysql.default.svc.cluster.local`, which does not change across restarts. This combination — ordinal identity, stable storage, and stable DNS — is essential for clustered, stateful systems like databases (PostgreSQL, MySQL, Cassandra), message queues (Kafka), and any system where replicas must know and reliably reach each other by identity.
- Gives each Pod a stable, predictable name and network identity
- Attaches a dedicated PersistentVolumeClaim per Pod that survives rescheduling
- Creates, scales, and deletes Pods in strict ordinal order
- Enables clustered stateful systems like databases and message queues
AI Mentor Explanation
A StatefulSet is like a team assigning permanent, numbered lockers to each player — locker 1 always belongs to the same opening batter, locker 2 to the same wicketkeeper, no matter which changing room they use across different stadiums. If a player is injured and later returns, they get their exact same locker back with their exact same gear inside, not a random one. A regular squad rotation, by contrast, would just hand any free locker to whoever walks in. The numbering and ownership stay fixed and predictable across the whole season.
Step-by-Step Explanation
Step 1
Define the StatefulSet spec
Set serviceName, a Pod template, and a volumeClaimTemplate for per-Pod persistent storage.
Step 2
Create a headless Service
A Service with clusterIP: None gives each Pod a stable, predictable DNS name.
Step 3
Scale in ordinal order
Pods are created and terminated one at a time in order, e.g. mysql-0 before mysql-1.
Step 4
Rescheduling preserves identity
If a Pod is rescheduled, it keeps its ordinal name and reattaches to its same PersistentVolumeClaim.
What Interviewer Expects
- Understanding of stable network identity via ordinal Pod naming
- Knowledge of per-Pod PersistentVolumeClaims via volumeClaimTemplate
- Awareness that StatefulSet scaling/termination happens in strict order
- Ability to name real use cases: databases, Kafka, clustered stateful systems
Common Mistakes
- Using a StatefulSet when a stateless Deployment would suffice
- Forgetting a headless Service is required for stable DNS identity
- Assuming StatefulSet Pods scale up/down in parallel like a Deployment
- Not realizing PersistentVolumeClaims are not deleted automatically on scale-down
Best Answer (HR Friendly)
“A StatefulSet is what we use when Pods need a stable identity and their own dedicated storage, like a database cluster where each replica has to know exactly who it is even after a restart. Unlike a Deployment where any Pod is interchangeable, StatefulSet Pods get predictable names and reattach to the same storage every time.”
Code Example
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: mysql
spec:
serviceName: mysql
replicas: 3
selector:
matchLabels:
app: mysql
template:
metadata:
labels:
app: mysql
spec:
containers:
- name: mysql
image: mysql:8.0
volumeMounts:
- name: data
mountPath: /var/lib/mysql
volumeClaimTemplates:
- metadata:
name: data
spec:
accessModes: ["ReadWriteOnce"]
resources:
requests:
storage: 10GiFollow-up Questions
- Why does a StatefulSet require a headless Service?
- What happens to a PersistentVolumeClaim when a StatefulSet Pod is deleted?
- How does StatefulSet Pod ordering affect scale-down?
- When would you choose a StatefulSet over a Deployment with a shared volume?
MCQ Practice
1. What distinguishes a StatefulSet Pod from a Deployment Pod?
StatefulSet Pods have stable ordinal identities and dedicated PersistentVolumeClaims that persist across rescheduling.
2. What kind of Service does a StatefulSet require for stable DNS names?
A headless Service gives each StatefulSet Pod a stable, individually addressable DNS name.
3. In what order does a StatefulSet typically create its Pods?
StatefulSets create and terminate Pods one at a time in strict ordinal order, e.g. pod-0 before pod-1.
Flash Cards
What is a StatefulSet? — A controller for Pods needing stable identity and stable, per-Pod persistent storage.
Why a headless Service? — It provides each StatefulSet Pod a stable, predictable DNS name.
How are StatefulSet Pods named? — With an ordinal suffix, e.g. mysql-0, mysql-1, mysql-2.
Typical StatefulSet use case? — Clustered stateful systems like databases and Kafka.