How does Kubernetes reconcile a Deployment after a Pod is deleted?

A Kubernetes controller keeps comparing what you asked for with what actually exists. Here, desired is three Pods, but it observes only two. That gap of one is the trigger, so the controller creates exactly one new Pod.

Three fields in this manifest drive everything. Replicas three is the desired state, stored through the API server. The selector, app web, decides which Pods count toward that three. The template is the recipe used whenever a new Pod is needed.

The Deployment doesn't manage Pods directly. It creates a ReplicaSet, and the ReplicaSet owns the three Pods. Its controller counts the Pods matching app web and keeps that number at exactly three. That counting job is the one we'll watch in action.

We delete web-5d9c-a1, then list Pods again. The old one is gone, and a new Pod, d4, is already in ContainerCreating. Names and output here are illustrative. Nobody asked for d4, so how did Kubernetes notice that fast?

kubectl only talks to the API Server. The server removes the Pod in etcd, gets the stored confirmation, then pushes a watch event, Pod deleted, to the ReplicaSet controller. The controller never polls. It holds a watch, and periodic resyncs act as a backup.

The event only wakes the controller up. It doesn't say what to do. The controller recounts actual Pods, finds two against three desired, creates one, then checks again. Controllers loop forever: observe, diff, act, closing whatever gap they find.

With replicas set to three, you delete two Pods at once. What does the ReplicaSet controller do on its next reconcile?

Creates two new Pods. The controller does not replay individual delete commands. It recounts matching Pods, sees one against a desired three, and creates two to close the whole gap. Reapplying the Deployment is unnecessary because the desired state never changed.

The RS Controller only creates a Pod object, web-5d9c-d4, through the API Server. It never starts anything itself. The Scheduler sees an unscheduled Pod and binds it to a node. The Kubelet sees the assignment, starts it, and reports Running. Next loop counts three and does nothing.

Controllers react to state, not commands. They compare spec with what's observed and take the smallest action that closes the gap. So change the Deployment's spec, not individual Pods, because the loop will undo manual drift.