What happens, step by step, when you run kubectl apply for a Deployment?

Summary

kubectl sends the manifest to the API server, which authenticates and authorises the request, runs admission controllers (mutating, then validating), validates the object and stores it in etcd. The Deployment controller creates a ReplicaSet, the ReplicaSet controller creates Pods, the scheduler assigns each Pod to a node, and that node's kubelet pulls images and starts the containers through the runtime, then reports status back.

Longer Answer

Then: the kubelet runs probes; when readiness passes, the EndpointSlice controller adds the pod's IP to the Service's endpoints, and kube-proxy (or the CNI's eBPF data path) routes Service traffic to it. During an update, the Deployment controller scales a new ReplicaSet up and the old one down within maxSurge and maxUnavailable.

Knowing this chain tells you where to look when something is stuck: admission rejection (API error), Pending (scheduling), ContainerCreating or ImagePullBackOff (kubelet/runtime), not ready (probes).

Key Points

• API server: authn, authz, admission, etcd.
• Deployment then ReplicaSet then Pods.
• Scheduler binds; kubelet starts containers.
• Readiness adds the pod to Service endpoints.

What interviewers look for

A full, correct chain, and using it to reason about where a deployment can get stuck.