How to Debug Kubernetes Pods Stuck in Pending
Determine why Kubernetes cannot schedule or start a Pending pod by checking scheduler events, resources, constraints, volumes, and quotas.
A pod remains Pending before its containers are running. It may be unscheduled because no node satisfies its requirements, or scheduled but waiting for volumes, image sandbox setup, or another node-level dependency.
Read scheduler events first
kubectl describe pod POD -n NAMESPACE
kubectl get events -n NAMESPACE --sort-by=.lastTimestamp
FailedScheduling messages usually state how many nodes were rejected and why: insufficient resources, taints, affinity rules, topology constraints, or unbound volumes.
Compare requests with available capacity
kubectl get pod POD -n NAMESPACE -o jsonpath='{.spec.containers[*].resources}'
kubectl describe nodes
kubectl top nodes
Scheduling uses resource requests and allocatable capacity, not only current utilization shown by top.
Check scheduling constraints
Inspect:
nodeSelectorand node affinity- pod anti-affinity
- topology spread constraints
- node taints and pod tolerations
- required host ports
- RuntimeClass requirements
kubectl get pod POD -n NAMESPACE -o yaml
kubectl get nodes --show-labels
Do not remove a taint or weaken affinity globally before understanding why the constraint exists.
Check volumes and quotas
kubectl get pvc -n NAMESPACE
kubectl describe pvc CLAIM -n NAMESPACE
kubectl get resourcequota,limitrange -n NAMESPACE
An unbound claim, unavailable storage class, or namespace quota can prevent progress.
Diagnose it with Rumus
Rumus is an AI-native terminal that can use your current Kubernetes context to correlate pods, events, logs, controllers, resources, and nodes. It keeps the investigation read-only until you approve a proposed change.
What Rumus can inspect
- Pods, events, previous logs, and owning controllers
- Resources, probes, scheduling rules, and node state
- Secret-aware output and approval before cluster changes
Diagnose why this pod is Pending. Inspect scheduler events, resource requests and
allocatable capacity, taints and tolerations, affinity, topology constraints,
host ports, PVCs, quotas, and node conditions. Rank the causes using observed
evidence and do not modify cluster constraints without approval.
Confirm the fix
After correcting the owning workload or cluster capacity:
kubectl get pod POD -n NAMESPACE -w
kubectl describe pod POD -n NAMESPACE
Confirm that the pod receives a node assignment and progresses beyond Pending without new warning events.
Open the server in Rumus and let the AI agent inspect context, propose a plan, and ask before it runs changes.