Day 55: Resource requests & limits
Requests and limits: back to Phase 0
A request is what a container is guaranteed to get, and what the scheduler uses to decide which node has room for it. A limit is the hard ceiling it's allowed to consume. Both are implemented via exactly the mechanisms from Phase 0 and Phase 6: cgroups enforce the limits, and CFS (Phase 0, Day 4) is the scheduler that actually allocates CPU time within them.
resources:
requests:
cpu: '250m' # 0.25 of a core, guaranteed
memory: '256Mi'
limits:
cpu: '500m' # hard ceiling — throttled beyond this
memory: '512Mi' # hard ceiling — OOMKilled beyond thisCPU throttling vs memory OOMKill — an important asymmetry
Exceed your CPU limit and CFS simply throttles you (you get slower, but keep running) — because CPU time can be rationed. Exceed your memory limit and the kernel's OOM killer terminates the container outright — because memory can't be 'throttled', only allocated or refused. This asymmetry is why memory limits deserve much more careful tuning than CPU limits.
A bursty container hitting its quota every ~100ms period, then flatlining (throttled) for the rest of it.
The scheduler only ever looks at requests to decide if a node has room — a node can be oversubscribed on limits (the sum of all containers' limits can exceed the node's actual capacity) as long as requests fit, betting that not everyone hits their limit simultaneously.
Key terms
- Request
- The guaranteed resource amount used for scheduling decisions.
- Limit
- The hard resource ceiling — throttled (CPU) or killed (memory) beyond it.
Why can a container exceed its CPU limit and just slow down, while exceeding its memory limit gets it killed?
