Pending Pod
This status occurs when a Pod cannot be scheduled onto a node due to resource constraints, taints, or missing volumes.
Usually happens because:
- ☑ Requested CPU or Memory limits exceed available allocations on all nodes
- ☑ Missing tolerations matching node NoSchedule taints parameters
- ☑ Pod relies on PersistentVolumeClaims (PVC) currently unbound
🔍 Quick Checklist:
What is Pending Pod?
A Pod in 'Pending' status indicates that the Kubernetes scheduler (kube-scheduler) cannot assign it to a node. Unlike running pods, a pending pod resides in the scheduler queue. In Kubernetes v1.36 scheduling frameworks, scheduling failures are logged as Events. Common scheduling blockers include CPU/Memory resource exhaustion, Node Taints that the Pod does not tolerate, or PersistentVolumeClaims (PVCs) failing to bind or locate matching storage classes.
Common Causes
- Insufficient node resources: The requested CPU or Memory limits inside the container spec exceed the available allocatable capacity on all nodes.
- Node Taints and Tolerations mismatch: Nodes are tainted (e.g. 'node-role.kubernetes.io/control-plane:NoSchedule') and the Pod does not have matching tolerations.
- Unbound Persistent Volume Claims (PVC): The Pod requests storage volumes that cannot bind due to incorrect size requests or missing StorageClasses.
| Cause | Frequency |
|---|---|
| Insufficient Node resources (CPU/Memory limits overflow) | ⭐⭐⭐⭐⭐ |
| Node Taints blocking scheduling (missing tolerations) | ⭐⭐⭐⭐ |
| PersistentVolumeClaims (PVC) stuck in Pending state | ⭐⭐⭐ |
Common Mistakes
- Setting container `resources.requests` equal to or higher than the total capacity of individual worker nodes (scheduling will fail even if the cluster has many nodes, because a single Pod cannot be split across nodes).
- Forgetting to check the status of PV Provisioners when utilizing dynamic volumes mappings.
How to Fix
Kubernetes Operations & Verification
Configure Pod tolerations to allow scheduling on tainted nodes (such as master or control-plane nodes).
apiVersion: v1
kind: Pod
metadata:
name: control-plane-utility
spec:
containers:
- name: sys-monitor
image: monitor:v1.2.0
# Match the taint key, value, and effect
tolerations:
- key: "node-role.kubernetes.io/control-plane"
operator: "Exists"
effect: "NoSchedule"Platform Specific Fixes
Query node capacity limits using kubectl commands directly from terminal controllers.
# 1. Describe node resources limits allocations
kubectl describe nodes | grep -A 10 "Allocated resources"
# 2. View details on the pending pod
kubectl describe pod app-workerBest Practices
- Adopt cluster autoscalers (like Karpenter or Kubernetes Cluster Autoscaler) to automatically provision nodes when resource exhaustion is detected.
- Define sensible resource requests and limits defaults using LimitRange files inside namespaces.
Frequently Asked Questions (FAQ)
Q: Why is my Pod stuck in Pending status?
This means the Kubernetes scheduler cannot find any worker node that meets the Pod's requirements. Run 'kubectl describe pod <pod-name>' and look at the 'Events' section at the bottom for the exact reason (e.g. '0/3 nodes are available: 3 Insufficient cpu').
Q: How do I fix 'Insufficient memory' scheduling failures?
Your containers have requested more CPU or Memory than what is available on the nodes. You can either lower the 'resources.requests' inside your deployment YAML or add more/larger nodes to your cluster.
Q: How Node Taints cause a Pod to stay Pending?
Taints allow a node to repel a set of pods. For example, control-plane nodes have a 'NoSchedule' taint. If your Pod does not have a matching 'tolerations' section in its spec, it won't be scheduled on those nodes.
Q: Why is my volume request keeping my Pod Pending?
If your Pod uses a PersistentVolumeClaim (PVC) that is not bound yet, the scheduler cannot schedule the Pod because it doesn't know which node can access the volume. Check your PVC status using 'kubectl get pvc'.