A Pod stays Pending with no node assigned — what do you check, in order?
A Pod has been Pending for minutes with no node assigned. Explain what Pending means, then use the describe Events to find why the scheduler will not place it — and name the other causes the same message distinguishes.
$ kubectl get pod report-1
NAME READY STATUS RESTARTS AGE
report-1 0/1 Pending 0 3m
$ kubectl describe pod report-1
Events:
Warning FailedScheduling scheduler 0/3 nodes are available:
3 Insufficient memory.Diagnose and fix.
Pending means the scheduler placed the Pod on no node. The FailedScheduling Events line names why — here Insufficient memory: no node fits the memory requests. Other causes it names: a taint, no matching nodeSelector/affinity, or an unbound PVC.
- ✗Confusing
Pending(unscheduled) with a not-yet-Ready running container - ✗Ignoring the
FailedSchedulingmessage that names the exact reason - ✗Assuming only capacity, missing taints, affinity, and PVC binding
- →How would the
FailedSchedulingmessage differ for an untolerated taint? - →Why can lowering a Pod's memory
requestlet it schedule but risk an OOM later?
Solution
1. What Pending means
Pending = the Pod is accepted by the API server, but the scheduler has not yet chosen a node (or cannot). The node column in kubectl get pod -o wide is empty.
2. Read the scheduler's reason
$ kubectl describe pod report-1 | sed -n '/Events/,$p'
Warning FailedScheduling 0/3 nodes are available: 3 Insufficient memory.The message says it outright: none of the 3 nodes can fit the Pod's requests.memory.
3. Causes and fixes (read from the message)
- Insufficient cpu/memory → lower
requestsor add/free nodes; - node(s) had untolerated taint → add a toleration or remove the taint;
- didn't match nodeSelector/affinity → fix node labels or the selector;
- unbound PersistentVolumeClaim → no provisioner/StorageClass — fix the PVC.
When lowering a request, remember: too low risks an OOM under load.
