What actually happens, step by step, when you run `kubectl apply -f deployment.yaml`?
Quick Answer
kubectl sends the manifest to the API server, which authenticates, admits, and persists it in etcd. The Deployment controller creates a ReplicaSet, the ReplicaSet creates Pods, the scheduler binds each Pod to a node, and that node's kubelet starts the containers — all via watch-and-reconcile loops.
Detailed Answer
1) kubectl POSTs/PATCHes the object to the kube-apiserver. 2) The apiserver runs authentication, authorization (RBAC), and admission control (validating/mutating webhooks, defaulting), then writes the desired state to etcd — the apiserver is the only component that touches etcd. 3) The Deployment controller (in kube-controller-manager) watches for the new/changed Deployment and creates or updates a ReplicaSet to match the template. 4) The ReplicaSet controller sees it needs N pods and creates Pod objects (still unscheduled). 5) The kube-scheduler watches for pods with no node, filters nodes that fit (resources, taints, affinity) and scores the rest, then binds each pod to the best node. 6) The kubelet on that node sees a pod assigned to it, pulls images via the CRI runtime, mounts volumes, starts containers, and runs probes, reporting status back to the apiserver. Every step is a controller reconciling actual state toward declared state — that loop is the essence of Kubernetes.
Code Example
kubectl apply -f deployment.yaml kubectl get events --sort-by=.lastTimestamp # watch the loop: scheduled, pulling, started # Deployment -> ReplicaSet -> Pods -> (scheduler binds) -> kubelet runs
Interview Tip
This is a top senior question. Hit the chain apiserver(+admission)→etcd→Deployment ctrl→ReplicaSet→scheduler→kubelet, and stress that each hop is a watch-and-reconcile loop. That narrative signals real architectural understanding.