Kubernetes Pod Stuck in Pending: The 4 Bottlenecks and How to Clear Each

Published October 2, 2026

⏱️ 3 min read

A pod that sits in Pending forever is not broken — it is unscheduled. The scheduler cannot place it somewhere, and your job is to find out why. The single command that answers this is:

kubectl describe pod <pod-name>

Scroll to the Events section at the bottom. One of four messages will appear, and each one points to a different bottleneck.

1. Insufficient CPU or memory

Insufficient cpu / Insufficient memory means no node has the spare capacity your requests demand. This is the most common case. Check what you are actually requesting:

kubectl get pod <pod-name> -o jsonpath='{.spec.containers[*].resources}'

If requests are inflated (a habit from teams afraid of limits), right-size them. If the requests are honest, your cluster is genuinely full — scale a node group, or add a node. Also check for node taints: a message like had untolerated taint means the scheduler is skipping nodes on purpose, usually your control-plane nodes.

2. Pending PersistentVolumeClaim

pod has unbound Immediate PersistentVolumeClaims means the storage claim never got fulfilled, and the pod is waiting on it. Diagnose the PVC itself:

kubectl describe pvc <claim-name>

Typical causes: no StorageClass matches the claim's access mode, the volume size is unavailable in the zone, or your cluster has no default StorageClass at all. Fix the PVC and the pod schedules within seconds.

3. NodeSelector or affinity that cannot be satisfied

node(s) didn't match Pod's node affinity/selector means you asked for a node that does not exist. A very common typo: selectors for kubernetes.io/os=linux on a cluster, or an instance-type label nobody set. List what labels nodes actually have:

kubectl get nodes --show-labels

Compare against the selector in your pod spec. Either fix the selector or add the label to the node.

4. Resource quota or LimitRange ceilings

exceeded quota means the namespace itself is capped. This one surprises people because the cluster has capacity — the namespace does not. Check with:

kubectl describe quota -n <namespace>

Ask the namespace owner to raise the quota, or move the workload to a namespace whose quota fits.

The fast path

In practice: describe the pod, read the last event, and act on the four categories above. Pending pods almost never need a restart — they need capacity, storage, labels, or quota. Fix the named blocker and the scheduler does the rest.

Running your cluster on a provider where you can add a node in under a minute makes capacity issues far less painful — our cloud pick for small teams (partner link) is a good fit if you scale node groups often.