TL;DR: The API server authenticates, admits and persists the object to etcd, and that is the whole of the write path. Everything after it is controllers watching for a difference and acting: the deployment and replicaset controllers create the pod, the scheduler binds it to a node, the kubelet pulls and starts it, and the CNI and kube-proxy make it reachable.
How to approach it
Name the stages in order and keep each to a sentence. The value of the answer is that it gives you a fault tree: for every stage you name, you know what "stuck here" looks like. Finish by mapping each stalled transition to the component you would inspect.
A strong answer
The request hits the API server, which authenticates you, authorises the verb against RBAC, then runs admission. Mutating admission webhooks and defaulting run first, so this is where a sidecar gets injected or a default resource limit gets stamped on. Validating admission and policy engines such as Kyverno or a Pod Security admission run next and can reject outright. If it survives, the object is persisted to etcd and the API server returns success. Your kubectl apply is now done, and nothing is running.
Everything after this is a control loop. The deployment controller sees a Deployment with no matching ReplicaSet and creates one. The replicaset controller sees a ReplicaSet whose desired replica count exceeds observed and creates Pod objects, which land in etcd with nodeName empty.
The scheduler watches for unbound pods. It filters nodes that cannot run the pod at all (insufficient allocatable resources, unsatisfied node selector or affinity, an untolerated taint, an unbindable volume) and then scores the survivors and writes a binding. If nothing survives filtering, the pod sits in Pending and the events explain which predicate failed.
The kubelet on the bound node takes over. Through CRI it asks the container runtime to create the pod sandbox; the runtime normally creates the network namespace and invokes CNI to configure networking and allocate an IP. Storage controllers and the kubelet coordinate CSI attachment and mounting. The runtime pulls images and starts containers. Ordinary init containers complete in sequence; restartable native sidecars can continue running after their startup condition allows the next container. EndpointSlices can contain an unready pod already: readiness updates endpoint conditions, which service proxies normally use to select traffic destinations. Pod lifecycle, EndpointSlice conditions.
The debugging payoff is to find the transition that has not completed. Pending covers both unscheduled pods and scheduled pods whose containers are not yet set up. Inspect the PodScheduled condition and events before blaming the scheduler. ContainerCreating points toward setup such as networking, volumes or image retrieval. CrashLoopBackOff is a container restart backoff, so inspect the last terminated state and previous logs. A Running pod can still fail readiness or have a broken traffic path.
Use this illustrative case to turn the component list into a diagnosis. The Deployment is accepted, a new ReplicaSet exists, but its new pod is Pending. The pod's PodScheduled condition is false, and its event reports insufficient memory. The API write and controller work have happened; restarting the application cannot repair a scheduling constraint because the new container has not started. Compare its memory request with allocatable, already-requested capacity on eligible nodes. Aggregate free memory across the cluster does not prove that one eligible node can fit it.
| Evidence | Next check | Why |
|---|---|---|
| No new ReplicaSet | Deployment conditions and controller events | Reconciliation or admission may have failed |
| PodScheduled false | Pod events, requests and node constraints | The scheduler has not found a usable placement |
| Scheduled, container waiting | Waiting reason, image and volume events | Placement succeeded; setup has not |
| Container repeatedly terminates | Exit reason and previous container logs | Startup or runtime execution is failing |
| Running but no successful requests | Readiness, Service selector, endpoints and network path | Process state does not establish service reachability |
For the last row, check whether the Service selects this pod and whether the endpoint is ready before investigating routing or network policy. A service proxy may be kube-proxy or another implementation; naming kube-proxy should not imply that every cluster uses it. Explain what evidence moves you to the next boundary rather than reciting every component at once.
What interviewers probe next
"Where is the pod's IP assigned?" By the CNI plugin, on the node, into the pod's network namespace. Not by the API server, and not by the scheduler.
"What if the scheduler is down?" Existing pods keep running because the kubelet does not need it. New pods stay Pending indefinitely. This is a good illustration of why the control plane is not on the data path.
"Where would an injected sidecar come from?" A mutating admission webhook, which is why it appears in the object even though nobody wrote it in the manifest.
Common mistakes
Describing it as a linear pipeline where each component calls the next. Controllers coordinate asynchronously through API state, while kubelet, runtimes and plugins also make direct API calls. Controllers watch the API server and reconcile, which is why the failure modes are "stuck" rather than "errored".
Skipping admission. It is where a surprising share of real production behaviour is introduced, which is why a change review that skips it is reviewing the wrong artifact.
Saying the scheduler "starts the pod". The scheduler only writes a node name. The kubelet starts things.