kubelet

Follow a Deployment change through the API server, controllers, scheduler and kubelet. Each handoff gives you a different place to investigate when a pod never starts.

The single most common Kubernetes interview question, and the one where a vague answer is most obvious. Every stage you name is a place the interviewer can ask you to debug.

Three propagation mechanisms live inside this one question and only one of them is automatic. Instant reload is the common assumption and the kubelet has never offered it.

The kubelet is a local reconcile loop with its own event stream, probe workers and eviction brain. The detail worth holding onto is that Ready status can reflect either a reported health failure or missing heartbeats, and those have different causes and different fixes.

Every control plane component depends on the API server, so who starts the API server? The bootstrap paradox sits at the heart of every cluster, and the kubelet plus a directory of files is the accepted way out.

Two cleanup mechanisms hide behind one taint: image garbage collection removes unreferenced images by LRU at threshold crossings, while eviction kills pods. Candidates who conflate them fail this question quietly.