FailedScheduling: The scheduler could not find a node that satisfies the pod's requirements

FailedScheduling is the event behind most pods stuck in Pending. Its message breaks down exactly how many nodes were rejected and for which reason, which is usually enough to identify the fix without further investigation.

Applies to: All Kubernetes versions

What it means

The scheduler evaluates every node against the pod's requirements and, when none pass, emits a FailedScheduling event summarising the rejections — for example 0/12 nodes are available: 8 Insufficient cpu, 3 node(s) had untolerated taint, 1 node(s) had volume node affinity conflict. Each clause is a distinct problem with a distinct fix, and the counts tell you which one matters most. This event is re-emitted as the scheduler retries, so a stale message can mislead; check the timestamp before acting on it.

Most common causes

• Insufficient CPU or memory across all nodes for the pod's requests.
• Untolerated taints, commonly on control-plane nodes or nodes marked unschedulable during maintenance.
• Node affinity or node selector rules matching no node, often because of a label typo.
• Pod anti-affinity spreading rules that cannot be satisfied at the current node count.
• Volume node affinity conflict — the persistent volume exists in one zone and the eligible nodes are in another.
• Insufficient extended resources such as GPUs.

How to diagnose it

1. Read the full message: kubectl describe pod POD. Do not stop at the first clause — the counts across clauses tell you whether this is a capacity problem or a placement-rule problem.
2. For insufficient resources, check what is actually free: kubectl describe node and compare allocated against allocatable.
3. For affinity mismatches, list the labels the rule expects and check they exist: kubectl get nodes --show-labels.
4. For taints, list them: kubectl describe node NODE and look at the Taints line.

How to fix it

1. Reduce resource requests, or add nodes with enough capacity.
2. Add the matching toleration to the pod, or remove the taint if it is no longer wanted.
3. Correct the node label or the selector so they match — a typo in either produces the same message.
4. Relax anti-affinity from requiredDuringScheduling to preferredDuringScheduling if strict spreading is not essential.
5. For zone conflicts, use a topology-aware storage class so volumes are provisioned where the pod can be scheduled.

Notes

The message counts nodes, not reasons — a single node can be rejected for several reasons but is counted once per clause it fails. The clause totals will often exceed the node count, which is expected.

Related

• Pending — Pod accepted but not yet running

Sources

• Kubernetes documentation — Kubernetes Scheduler
• Kubernetes documentation — Assigning Pods to Nodes
• Kubernetes documentation — Taints and Tolerations