1. The scheduler receives an unscheduled Pod
When a Deployment creates a Pod, the Pod initially has no assigned node. The Kubernetes scheduler watches for Pods whose spec.nodeName is empty and starts the scheduling process.
2. Filtering: which nodes are eligible?
The scheduler first removes nodes that cannot run the Pod. Common reasons include insufficient requested CPU or memory, taints without matching tolerations, node selectors, affinity rules, volume constraints and other scheduling policies.
resources:
requests:
cpu: "500m"
memory: "512Mi"
Requests are especially important: scheduling is based on requested resources, not simply the current percentage shown by a monitoring dashboard.
3. Scoring: which eligible node is preferred?
After filtering, the scheduler scores the remaining nodes using scheduling plugins and configured policies. The highest-scoring suitable node is selected.
4. Binding and startup
The scheduler records the decision by binding the Pod to the selected node. The kubelet on that node then pulls the image, creates the containers and reports their status back to the API server.
When a Pod stays Pending
- Check
kubectl describe pod <pod>and read the Events section. - Check node capacity and Pod resource requests.
- Review taints/tolerations and node selectors.
- Check affinity/anti-affinity rules.
- Check storage and topology constraints when volumes are involved.