How a Deployment rolling update works

WHAT THIS TESTS This probes your grasp of the layered controller model: Deployment owns ReplicaSets, and each ReplicaSet owns identical Pods. Updates happen by swapping ReplicaSets, never by editing running Pods.

A GOOD ANSWER COVERS When you change the image tag and apply the manifest, the Deployment controller computes a new pod-template hash and creates a brand-new ReplicaSet for the new template. It then performs a coordinated scale: incrementing the new ReplicaSet's replica count while decrementing the old one's. The pace is governed by the RollingUpdate strategy's maxSurge (how many extra Pods above desired are allowed) and maxUnavailable (how many below desired). Once the new ReplicaSet reaches the full count and its Pods are Ready, the old ReplicaSet is scaled to zero but retained in history.

COMMON WRONG ANSWERS Saying the Deployment patches existing Pods, which never happens; Pods are immutable in their spec. Saying the old ReplicaSet is deleted right away, which would break rollback. Ignoring readiness gating in the surge logic.

LIKELY FOLLOW-UPS How many old ReplicaSets are kept? Controlled by revisionHistoryLimit. How do you roll back? kubectl rollout undo, which scales the old ReplicaSet back up. What if new Pods never become Ready? The rollout stalls and progressDeadlineSeconds eventually marks it failed.

ONE CONCRETE EXAMPLE A Deployment with three replicas, maxSurge 1 and maxUnavailable 0, gets a new image. The controller creates a new ReplicaSet, scales it to 1 (now four Pods total), waits for that Pod to be Ready, scales the old down to 2, and repeats until the new ReplicaSet has 3 and the old has 0.