Pending: The pod has been accepted but is not running yet, usually because it cannot be scheduled

A pod stuck in Pending has been accepted by the API server but has not started. Most often no node can satisfy its requirements, and the scheduler explains why in the pod's events.

Applies to: All Kubernetes versions

What it means

Pending is the phase between a pod being created and its containers starting. Briefly passing through it is normal. Staying there means one of two things: the scheduler cannot place the pod on any node, or it has been placed but the node cannot start it yet — usually because a volume will not attach or an image is still downloading. The distinction is visible in the pod's events, where a scheduling failure appears as FailedScheduling with a per-node breakdown of why each node was rejected. That breakdown is the most useful diagnostic Kubernetes produces for this state and is worth reading in full rather than skimming.

Most common causes

• No node has enough allocatable CPU or memory to satisfy the pod's requests.
• Node taints that the pod does not tolerate, including the control-plane taint and the not-ready taints applied automatically to unhealthy nodes.
• Node affinity, node selectors, or pod anti-affinity rules that no node satisfies.
• A PersistentVolumeClaim that is unbound, or a volume in a zone none of the candidate nodes are in.
• The cluster is genuinely full and the autoscaler is still provisioning, or cannot provision because of a quota or instance limit.
• A resource quota or limit range in the namespace rejecting the pod's requests.

How to diagnose it

1. Read the scheduling failure directly: kubectl describe pod POD and look for a FailedScheduling event. It names how many nodes were rejected and for what — insufficient cpu, insufficient memory, untolerated taint, node affinity mismatch, volume node affinity conflict.
2. Compare requested resources against what nodes have free: kubectl describe node NODE shows allocated resources versus allocatable.
3. If a volume is involved, check the claim is bound: kubectl get pvc -n NAMESPACE. A claim in Pending will hold the pod in Pending.
4. Check namespace quotas: kubectl describe quota -n NAMESPACE.
5. If the events say the pod was scheduled but it is still Pending, the problem has moved to the node — check for volume attachment errors or a slow image pull.

How to fix it

1. Lower the pod's resource requests if they were set higher than the workload needs, or add capacity to the cluster.
2. Add the necessary toleration, or correct the node selector or affinity rule that no node matches.
3. Fix the storage problem — create the missing StorageClass, or ensure the volume and the candidate nodes are in the same zone.
4. Raise or correct the namespace resource quota.
5. If the cluster autoscaler is not adding nodes, check its logs — instance quota limits and unschedulable-but-unscalable pods are the usual reasons.

Notes

A pod requesting more resources than any single node has will stay Pending forever without ever producing an obvious error. Comparing the request against the largest node's allocatable capacity catches this immediately.

Related

• FailedScheduling — The scheduler could not find a suitable node

Sources

• Kubernetes documentation — Pod Lifecycle: pod phase
• Kubernetes documentation — Kubernetes Scheduler
• Kubernetes documentation — Taints and Tolerations