What is the difference between a StatefulSet and a Deployment?
Understand the difference between a StatefulSet and a Deployment in Kubernetes: stable identity, ordered rollout, and per-pod storage vs stateless replicas.
Expected Interview Answer
A Deployment manages stateless, interchangeable pod replicas that can be created, replaced, or scaled in any order, while a StatefulSet manages stateful pods that need stable, unique network identities, ordered rollout, and their own persistent storage. Use a Deployment for web servers and APIs; use a StatefulSet for databases, message brokers, and other clustered stateful systems.
StatefulSet pods get a stable ordinal identity (web-0, web-1, ...) and a stable hostname via a headless Service, and each pod keeps its own PersistentVolumeClaim across rescheduling through volumeClaimTemplates. Pods are created, scaled, and updated in a defined order, and a replacement pod reattaches to the same volume and name. Deployment pods, by contrast, get random hashed names, are fungible, roll out with no ordering guarantees, and typically share or lack persistent per-pod storage.
- StatefulSet gives each pod a stable, predictable name and hostname
- StatefulSet provides per-pod persistent storage that survives rescheduling
- Ordered, graceful deployment, scaling, and deletion for clustered apps
- Deployment offers fast, unordered scaling for stateless workloads
- Deployment supports simple rolling updates and easy rollback
AI Mentor Explanation
A Deployment is a pool of substitute fielders — any one can cover any gap and swapping them changes nothing. A StatefulSet is the numbered batting order: each batter has a fixed slot and identity, comes in a set sequence, and carries their own kit that follows them. You cannot send number four in as number one and expect the same innings.
Step-by-Step Explanation
Step 1
Decide stateful or stateless
If pods are interchangeable and hold no per-pod state, choose a Deployment; if they need stable identity or storage, choose a StatefulSet.
Step 2
Set up identity
For a StatefulSet, create a headless Service (clusterIP: None) so each pod gets a stable DNS hostname like web-0.svc.
Step 3
Define per-pod storage
Use volumeClaimTemplates in the StatefulSet so each pod gets its own PersistentVolumeClaim that follows it across rescheduling.
Step 4
Control rollout order
StatefulSets create and update pods in ordinal order; Deployments roll out with no ordering guarantees.
Step 5
Scale appropriately
Scale Deployments freely; scale StatefulSets knowing pods are added and removed one at a time in order.
What Interviewer Expects
- Stateless versus stateful distinction
- Stable network identity and headless Service for StatefulSets
- Per-pod persistent storage via volumeClaimTemplates
- Ordered versus unordered rollout and scaling
- Correct example workloads for each (API vs database)
Common Mistakes
- Using a StatefulSet for a plain stateless web app
- Thinking a Deployment gives each pod stable storage
- Forgetting the required headless Service for a StatefulSet
- Assuming StatefulSet pods scale in parallel like a Deployment
- Believing pod names are random in a StatefulSet
Best Answer (HR Friendly)
“A Deployment runs identical, replaceable copies of an app, which is perfect for websites and APIs. A StatefulSet is for apps like databases where each copy needs its own permanent name and storage, so replacements come back as the same instance with the same data.”
Code Example
apiVersion: v1
kind: Service
metadata:
name: db
spec:
clusterIP: None
selector:
app: db
ports:
- port: 5432
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: db
spec:
serviceName: db
replicas: 3
selector:
matchLabels:
app: db
template:
metadata:
labels:
app: db
spec:
containers:
- name: postgres
image: postgres:16
ports:
- containerPort: 5432
volumeMounts:
- name: data
mountPath: /var/lib/postgresql/data
volumeClaimTemplates:
- metadata:
name: data
spec:
accessModes: ["ReadWriteOnce"]
resources:
requests:
storage: 10GiapiVersion: apps/v1
kind: Deployment
metadata:
name: api
spec:
replicas: 3
selector:
matchLabels:
app: api
template:
metadata:
labels:
app: api
spec:
containers:
- name: api
image: myorg/api:1.4
ports:
- containerPort: 8080Follow-up Questions
- Why does a StatefulSet require a headless Service?
- What happens to a StatefulSet pod's PVC when the pod is deleted?
- How does ordered rollout help a database cluster?
- Can you convert a Deployment into a StatefulSet safely?
- How do update strategies differ between the two?
MCQ Practice
1. Which workload gives each pod a stable, ordinal name like app-0, app-1?
StatefulSets assign stable ordinal identities; Deployment and ReplicaSet pods get random hashed names.
2. What provides per-pod persistent storage in a StatefulSet?
volumeClaimTemplates create a dedicated PVC per pod that follows it across rescheduling.
3. Which is the best fit for a stateless REST API?
Stateless, interchangeable replicas are exactly what a Deployment manages.
Flash Cards
Deployment in one line — Manages stateless, interchangeable pod replicas with unordered rollout.
StatefulSet in one line — Manages stateful pods with stable identity, ordered rollout, and per-pod storage.
How does a StatefulSet get stable DNS names? — Through a required headless Service (clusterIP: None).
Per-pod storage mechanism — volumeClaimTemplates, which create one PVC per pod that persists across rescheduling.
Pick one: database vs web API — Database uses a StatefulSet; web API uses a Deployment.