Scheduling, Requests, Limits and QoS
The scheduler places Pods using requests, taints, affinity and spread rules; the kubelet then enforces limits and evicts under pressure. Knowing which component uses which number explains most Pending, throttling and eviction incidents.
Key points
- 1
Scheduling compares the sum of requests with node allocatable (capacity minus kube-reserved, system-reserved and the hard eviction threshold). Actual usage and limits are ignored.
- 2
CPU limits throttle through a CFS quota per 100 ms period; memory limits OOM-kill. Only a limit with no request makes the request default to the limit.
- 3
QoS: Guaranteed = every container has CPU and memory requests equal to limits; BestEffort = nothing set anywhere; everything else is Burstable.
- 4
Node-pressure eviction ranks by usage over requests, then priority, then how far over requests; hard thresholds use a 0 s grace period and ignore PDBs.
- 5
Taints repel and tolerations permit; use node affinity or nodeSelector to attract. Required affinity rules are ignored after scheduling (IgnoredDuringExecution).
- 6
Topology spread with DoNotSchedule compares (count + 1) with the global minimum; minDomains treats the minimum as 0 when there are too few domains.
- 7
ResourceQuota on cpu/memory forces every new Pod to declare those resources; LimitRange supplies defaults only at admission.
Common traps
Assuming BestEffort Pods are always evicted first: a Burstable Pod far over its request can go before them.
Writing
memory: 400m(0.4 bytes) instead of400Mi.Expecting a toleration alone to pin Pods to dedicated nodes.
Read the source
Test yourself on Scheduling, Requests, Limits and QoS
Ten questions, with the answer and explanation after each one.