Deployment versus StatefulSet
choosing the right workload controller.
Deployments suit interchangeable stateless replicas, StatefulSets give stable identities, ordered rollout, and per-Pod persistent storage for stateful systems.
What's really being asked
This checks whether you understand identity and storage semantics well enough to pick the correct controller.
The full answer
A Deployment manages stateless, interchangeable Pods. They get random hash-suffixed names, can be created, replaced, or scaled in any order, and share no per-Pod identity or storage. This suits stateless web servers and APIs where any replica handles any request. A StatefulSet is for workloads that need stable identity. Each Pod gets a stable ordinal name like db-0, db-1, a stable DNS hostname via a headless Service, ordered startup and shutdown, and its own PersistentVolumeClaim that follows the Pod across rescheduling. This matters for databases and clustered systems where a primary and replicas must be distinguishable, where storage must persist per instance, and where scaling order matters. Choosing wrong causes data corruption or broken clustering, for example if a database loses its volume or two Pods share one.
The mistakes people make
Running a clustered or replicated database on a Deployment. Using a StatefulSet for a plain stateless API. Thinking Deployments preserve Pod identity. Ignoring the per-Pod volume difference.
What usually comes next
What is a headless Service and why does a StatefulSet need it? How does PVC behavior differ? What is the scaling order for a StatefulSet? Can you run a database on a Deployment with a shared volume?
A concrete example
A stateless image-resize API runs as a Deployment with five identical replicas behind a Service; any Pod handles any request and scaling up or down is trivial. A three-node Cassandra cluster runs as a StatefulSet: each Pod is cassandra-0, cassandra-1, cassandra-2, each keeps its own PersistentVolume across restarts, and they start in order so the cluster forms correctly, which a Deployment could not guarantee.
Interview question
Why is a StatefulSet, not a Deployment, the right choice for a clustered database?
- a.StatefulSets use less memory per Pod
- b.Deployments cannot mount any volumes
- c.Each Pod needs a stable identity and its own persistent volume that survives reschedulingCorrect
- d.StatefulSets always run faster than Deployments
Why? this is the answer
A StatefulSet gives stable ordinal names, stable DNS, and per-Pod persistent storage that databases require. Deployments treat Pods as interchangeable and can mount volumes (B) but not per-Pod stable ones.
Just read this? Test yourself on what you have been reading.
Read the original → kubernetes.io
- #kubernetes
- #deployment
- #statefulset
- #stateful
- #workloads
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on kubernetes — each one lists the topics its interview covers.
See open roles