A cluster administrator manually deletes a Pod that was created by a Deployment. Within seconds a replacement Pod appears, although no one issued a create command. Which principle of the Kubernetes model best explains this behaviour?
- AThe Pod's restartPolicy was set to Always, which caused the deleted Pod to restart itself in place after removal.
- BThe kubectl client cached the original request and automatically resubmitted it to the API server after the deletion.
- CA controller continuously reconciles the actual state toward the desired state declared in the Deployment, recreating the missing Pod. Correct
- DThe kubelet on the node recreated the Pod object because it detected that the Pod's container had exited unexpectedly.
Why A is wrong: restartPolicy is a real field, so it tempts, but it governs restarting containers inside a still-existing Pod on its node and cannot bring back a Pod object that has been deleted from the API.
Why B is wrong: This sounds plausible if you imagine the client retrying, but kubectl is stateless between commands and does not resubmit past requests, so the recreation is not driven from the client side.
Why C is correct: The Deployment's controller compares the desired replica count in the spec against the Pods it observes, and when a Pod disappears the observed count falls below desired, so the controller creates a replacement to close the gap.
Why D is wrong: The kubelet does manage containers for Pods assigned to its node, which makes this tempting, but it does not create new Pod objects in the API server; that ownership belongs to the controller acting on the Deployment's desired state.