Kubernetes Deployment versus Pod

WHAT THIS TESTS This checks foundational Kubernetes knowledge: the difference between a raw workload object and a controller that manages it declaratively, plus the self-healing model.

A GOOD ANSWER COVERS 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.

COMMON WRONG ANSWERS 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.

LIKELY FOLLOW-UPS 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?

ONE 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.