Deployment, ReplicaSet, and Pod hierarchy

WHAT THIS TESTS This checks whether you understand the three-layer ownership chain and the operational features a Deployment adds.

A GOOD ANSWER COVERS The three objects form a hierarchy. A Pod runs one or more containers and is ephemeral. A ReplicaSet owns a set of identical Pods and continuously ensures the desired replica count, recreating Pods that die. A Deployment sits above and manages ReplicaSets, owning the update strategy. When you change a Deployment's Pod template, it creates a new ReplicaSet and gradually scales it up while scaling the old one down, giving a rolling update with no downtime; the old ReplicaSet is kept so you can roll back instantly. We manage Deployments rather than bare Pods because Pods alone do not self-heal or update, and managing ReplicaSets directly would force you to orchestrate rollouts and rollbacks by hand. The Deployment gives declarative versioned rollouts, automatic recovery, and simple scaling.

COMMON WRONG ANSWERS Managing individual Pods directly and expecting self-healing. Thinking the ReplicaSet handles rolling updates. Believing a Deployment runs containers itself. Conflating ReplicaSet with ReplicationController without noting the Deployment layer.

LIKELY FOLLOW-UPS What happens to the old ReplicaSet after an update? How does rollback work? What is the difference between a ReplicaSet and a Deployment? How does scaling propagate down the chain?

ONE CONCRETE EXAMPLE You run a Deployment with three replicas; it creates ReplicaSet v1 managing three Pods. You update the image, and the Deployment creates ReplicaSet v2, scaling it to three while scaling v1 to zero, one Pod at a time, so traffic never drops. v1 is retained at zero replicas, so kubectl rollout undo instantly scales it back up and v2 down if the new version misbehaves. You never touched a Pod directly.