TL;DR: Pending means the pod has been accepted but its containers are not yet fully set up. Check
PodScheduledandspec.nodeName: an unbound pod needs scheduling diagnosis; a bound pod may be pulling images, mounting volumes or running initialization. Events and container status identify the branch.
How to approach it
Say what Pending means before saying what you would run, because the meaning bounds the search. Then go to events first. Logs help only when a container has started, including an init container; an unscheduled pod has no container logs.
A strong answer
Read the full pod description, including its assigned node, conditions, init-container status and events. If spec.nodeName is empty and PodScheduled is false, focus on scheduling constraints. If a node is assigned, inspect image pulls, volume setup, the container runtime and init containers on that node. The phase remains Pending during these startup steps.
The events say why:
kubectl get pod api-7f9c -o wide
kubectl describe pod api-7f9c
# 0/6 nodes are available: 3 Insufficient cpu, 2 node(s) had untolerated taint,
# 1 node(s) had volume node affinity conflict.
That message is the answer, and it is worth reading carefully because it counts every node and gives a reason per group.
Insufficient CPU or memory means the incoming pod's requests, combined with already allocated requests, do not fit the node's allocatable resources. Requests, not limits, and not usage: a node at 10 percent actual CPU can be unschedulable because everything on it requested more than it uses. The fix is right-sizing requests or adding capacity, and it is usually the former.
An unsatisfiable selector or required affinity can involve missing node labels, conflicting pod placement rules or topology constraints. Check the pod's selector against kubectl get nodes --show-labels, and expect a typo or a node group that was scaled to zero.
An untolerated taint means the only nodes with room are reserved. Control plane nodes and GPU pools are the usual ones. Either tolerate it deliberately or schedule elsewhere.
A volume conflict means the PVC is bound to a PersistentVolume in one availability zone and the only free capacity is in another, or the PVC is not bound at all because no StorageClass matched. This is the one that looks most mysterious and it is common on StatefulSets.
Finally, if the cluster autoscaler is present, Pending is sometimes correct and temporary: it is the signal that triggers a scale-up, and the pod stays Pending for the provisioning time. Check whether a node is being added before treating it as a fault.
What interviewers probe next
"The node shows 40 percent CPU used but the pod will not schedule. Explain." Scheduling is on requests, monitoring shows usage. The gap between them is the whole answer, and it is the most common misunderstanding on this topic.
"How would you prevent this class of problem?" Sensible defaults through LimitRange, requests derived from observed usage rather than guessed, and alerting on pods Pending beyond a threshold so you find out before a user does.
"What if events are empty?" Events can expire or be unavailable. Check pod conditions, scheduling gates and any custom schedulerName, then inspect the responsible scheduler if the pod is unbound. For an assigned pod, inspect kubelet and container status instead.
Common mistakes
Treating every Pending pod as unscheduled, or asking for application logs before checking whether a container has started.
Confusing requests with limits, which turns the entire answer inside out.
Adding nodes as the reflex fix. Check requests and placement constraints before buying capacity that cannot resolve the actual restriction.