Scheduling & requests/limits
Creating a Pod doesn't start it. A node has to be chosen first. What the scheduler looks at is not what is being used right now but the sum of the requests the Pods declared — the reserved share. Nodes that can't take the request are filtered out, and the remaining candidates are scored to pick one.
01Scheduling & requests/limits
Concept at a GlanceCreating a Pod doesn't start it. Until a node is chosen it waits as Pending.
What the scheduler reads is the sum of requests, not current usage. The filled bar is reserved share, not consumption.
The filter runs first. A node that would overflow once the request is added drops out — 0.5 left can't hold 1.
The remaining candidates are scored. By default the policy favours the node with more room, so load doesn't pile up in one place.
Once placed, that node's reservation goes up by the same amount. The next Pod is measured against this new figure.
Room isn't the only test. A tainted node only takes Pods that tolerate the mark, and a node whose labels don't match is out however much room it has.
Understate requests and more Pods fit. The cost arrives together: under load, Pods reaching past their reservation take resources from each other.
The punishment for going over differs by resource. CPU is throttled back to the limit, while memory kills the container on the spot.
A Pod that fits on no node stays Pending. Adding nodes at that point is the cluster autoscaler's job.
02 Understand It Simply
For EveryoneThe scheduler places pods by the sum of declared requests, not by actual usage. requests reserve the room and limits decide what happens when you exceed them — CPU is throttled, memory kills the container.
Scheduling is a filter step and a scoring step.
Nodes that would overflow once the request is added, or whose labels and taints don't match, drop out first; among the rest the default policy favours spreading load rather than piling it up.
requests reserve room while limits set the ceiling, and going over is punished differently: CPU is throttled back to the limit, while memory can't be reclaimed so the container is OOMKilled.
The relationship between the two values sets the QoS class, which is also what decides who gets evicted first when a node runs short.
A Pod that fits nowhere stays Pending, and adding nodes is the cluster autoscaler's job.
- –Setting requests and limits
- –diagnosing why a Pod is Pending
- –partitioning workloads with node labels and taints
- –and trading overcommit against OOMKills
03 Frequently Asked Questions
FAQWhat is Scheduling & requests/limits?+
Creating a Pod doesn't start it. A node has to be chosen first. What the scheduler looks at is not what is being used right now but the sum of the requests the Pods declared — the reserved share. Nodes that can't take the request are filtered out, and the remaining candidates are scored to pick one.
Where is Scheduling & requests/limits used?+
Setting requests and limits, diagnosing why a Pod is Pending, partitioning workloads with node labels and taints, and trading overcommit against OOMKills.
What's a simple analogy for Scheduling & requests/limits?+
The scheduler places pods by the sum of declared requests, not by actual usage. requests reserve the room and limits decide what happens when you exceed them — CPU is throttled, memory kills the container.