Kubernetes Deployment versus Pod
Kubernetes controllers and self-healing.
a Pod is the smallest disposable unit, a Deployment maintains a desired replica count, self-heals, and rolls out updates.
bare Pods expected to be recreated after a crash.
What's really being asked
This checks foundational Kubernetes knowledge: the difference between a raw workload object and a controller that manages it declaratively, plus the self-healing model.
The full answer
A Pod is the smallest deployable unit in Kubernetes, wrapping one or more tightly coupled containers that share network and storage. A Pod is ephemeral and mortal: if its node fails or the Pod crashes, nothing brings it back, and it has no built-in scaling or update story. A Deployment is a higher-level controller that manages Pods for you through a ReplicaSet. You declare desired state, for example three replicas of this Pod template, and the Deployment controller continuously reconciles reality toward that state. If a Pod dies or a node is lost, the controller creates a replacement to restore the count, giving you self-healing. It also handles scaling by changing the replica count and, crucially, rolling updates: when you change the image, it incrementally replaces old Pods with new ones with zero downtime, and it can roll back to a previous revision if the new version misbehaves.
The mistakes people make
Creating bare Pods and assuming Kubernetes will recreate them after a crash; it will not. Thinking a Deployment is just a Pod with extra fields rather than a controller. Believing you must manually delete and recreate Pods to deploy a new version, missing rolling updates and rollback.
What usually comes next
What is a ReplicaSet and how does it relate to a Deployment? How does a rolling update work, and what do maxSurge and maxUnavailable control? How do you roll back? When would you use a StatefulSet or DaemonSet instead?
A concrete example
You deploy an API with a Deployment of three replicas. A node crashes and one Pod is lost; the controller immediately schedules a replacement elsewhere, keeping three running with no human action. To ship v2 you update the image in the Deployment, and Kubernetes rolls Pods one batch at a time, watching readiness, so traffic is served throughout, and a bad release is reverted with a single rollback command.
Interview question
Why is a Deployment preferred over creating bare Pods for running an application?
- a.Deployments run faster because they skip the container scheduler
- b.Pods cannot be assigned to nodes unless wrapped in a Deployment
- c.Bare Pods cannot run containers, only Deployments can
- d.A Deployment self-heals by recreating failed Pods and performs rolling updates and rollbacksCorrect
Why? this is the answer
A Deployment is a controller that maintains the desired replica count, recreating dead Pods and doing rolling updates and rollbacks. Bare Pods run containers but are not recreated when they die.
Just read this? Test yourself on what you have been reading.
Read the original → kubernetes.io
- #kubernetes
- #deployment
- #pod
- #replicaset
- #self-healing
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