What happens after kubectl apply

WHAT THIS TESTS This checks whether you understand Kubernetes as a declarative, watch-based system and can trace responsibility across components.

A GOOD ANSWER COVERS First, kubectl apply sends the manifest to the kube-apiserver. The apiserver authenticates and authorizes the request, runs admission controllers, validates the spec, and persists the Pod object into etcd; the desired state now exists but the Pod has no Node yet. The scheduler, watching the apiserver for unscheduled Pods, runs its filtering and scoring to pick a Node and writes a binding back through the apiserver. The chosen Node's kubelet, also watching the apiserver, notices a Pod assigned to it, calls the container runtime through the CRI to pull the image and start the containers, and sets up networking via the CNI. The kubelet then reports the Pod's status, like Running, back to the apiserver, which stores it in etcd so kubectl get pod reflects reality. Everything flows through the apiserver; components communicate by watching it, not each other.

COMMON WRONG ANSWERS Saying kubectl talks directly to the Node or the kubelet. Skipping the scheduler so the Pod magically lands. Forgetting etcd persistence. Thinking components call each other directly rather than via the apiserver.

LIKELY FOLLOW-UPS What does admission control do? How does the scheduler choose a Node? What is the CRI? How does status get reported back?

ONE CONCRETE EXAMPLE You run kubectl apply -f pod.yaml. The apiserver validates and stores the Pod in etcd with no nodeName. The scheduler picks node-2 and binds it. The kubelet on node-2 pulls the image, the runtime starts the container, CNI wires up the Pod IP, and the kubelet reports Running. Seconds later kubectl get pod shows the Pod Running on node-2.