Requests, limits & QoS
How requests drive placement and eviction order.
In plain terms
Requests are the seat you reserve; limits are how loud you’re allowed to get before you’re asked to leave. Reserve nothing and you’re the very first to be bumped when the place fills up.
Every container should declare what it needs (requests) and its ceiling (limits). Requests are what the scheduler reserves and places on; limits are what the kubelet enforces at runtime. Getting these right is the difference between a stable cluster and a game of eviction roulette.
resources.yaml
resources:requests: { cpu: 100m, memory: 128Mi } # scheduler reserves thislimits: { cpu: 500m, memory: 256Mi } # kubelet caps at this
The scheduler places on requests, never on live usage — a node “full” by requests takes no more pods even if it sits idle. At runtime, exceeding the memory limit gets the container OOM-killed; exceeding CPU only throttles it. The combination of requests and limits also sets the pod’s Quality-of-Service class.
under node memory pressure, evicted in this order
BestEffort
no requests/limits — first out
Burstable
requests < limits
Guaranteed
requests == limits — last out
Setting no requests is not “free” — it makes the pod BestEffort, the first thing the kubelet kills when a node runs low on memory.