Full lesson
Explore the full explanation, examples, and visuals at your own pace.
Node A: 3.5 of 4 CPU reserved. Node B: 3.75 of 4.
Your new Pod, web-3, is stuck in Pending. Look at the cluster. Node A has 3.5 of its 4 CPU reserved, and Node B has 3.75 of 4. Both are nearly full, so the scheduler has nowhere to put web-3, and it just waits.
web-3 requests 1 CPU
Free room is allocatable minus requested. Node A has half a CPU left, Node B only a quarter. But web-3 asks for one full CPU, so neither node fits. The scheduler records that as an event: Insufficient cpu.
Chart values
| Label | CPU cores |
|---|---|
| Node A free | 0.5 |
| Node B free | 0.25 |
| web-3 needs | 1 |
How the scheduler decides
Every pending Pod goes through Filter Nodes first, which drops any node that can't fit it. If some survive, Score Nodes ranks them and Bind to Node picks the best one. For web-3, both nodes get filtered out, so nothing reaches scoring and it Stays Pending.
What the filter checks
The filter runs three checks: do the requests fit the free room, does the Pod tolerate the taints, and do its selectors and affinity match. Any single failure removes the node. For web-3, CPU fails first.
- CPU and memory requests vs free room
- Taints the Pod does not tolerate
- Node selectors and affinity rules
The scheduler counts reserved requests, not live usage.
A node can sit nearly idle and still be full on paper. Requests are reservations, and the scheduler only counts reservations.
A node has four CPU, Pods there request three and a half but use only one. Can a Pod requesting one CPU be scheduled there?
A node has four CPU, Pods there request three and a half but use only one. Can a Pod requesting one CPU be scheduled there?
- Yes, because actual usage is only one CPU
- No, only half a CPU is unreserved
- Yes, but only after scoring ranks it highest
A node has four CPU, Pods there request three and a half but use only one. Can a Pod requesting one CPU be scheduled there?
No, only half a CPU is unreserved. The scheduler compares the new Pod's request with allocatable capacity minus existing requests. Live usage does not matter, so the node looks full on paper with only half a CPU free.
- Yes, because actual usage is only one CPU
- No, only half a CPU is unreserved
- Yes, but only after scoring ranks it highest
Cluster autoscaler adds capacity
The scheduler flags web-3 as unschedulable, and the autoscaler notices. It first checks that a new node would actually fit web-3. If so, it asks the cloud API for one more node. The VM boots as Node C, joins, and turns Ready. Then the scheduler binds web-3 there.
web-3 runs on new Node C
Now web-3 is running on Node C, bound there by the Scheduler after the Autoscaler added the node. But this takes minutes, not seconds. It also fails if the node group is already at its maximum size, or if the Pod requests more than any node type can offer.
Part 10
A Pod stays Pending when no node has enough unreserved requests, and the autoscaler only helps if a new node would fit it. Next time, read the Pending Pod's events, and set realistic resource requests.
- Pending: no node has enough unreserved requests
- Scheduler filters by requests, taints, affinity
- Autoscaler adds a node only if Pod fits