Free lesson · CKA Prep Program · Module 3: Workloads and scheduling
Set Requests and Limits with Intent
Requests reserve a seat, limits set the walls. Get them right and the scheduler packs honestly while the kernel protects neighbors; get them wrong and pods die mysteriously under load.
12 min reading
Objectives
- Explain how requests drive scheduling and limits drive throttling plus kills
- Size CPU and memory values from observed use instead of guessing
- Predict the QoS class of any pod from its containers
- Say who gets evicted first under node pressure and why
Why this matters
CPU is compressible: over the limit means throttled, slow but alive. Memory is not: over the limit means OOMKilled, dead instantly. The scheduler only sees requests when placing pods, so missing requests pack nodes on lies and missing limits let one container starve its neighbors. Every production incident involving slow-then-dead pods traces back here.
Concepts
Requests guarantee scheduling room: the scheduler sums container requests and refuses pods that do not fit the node's allocatable. Set requests to steady-state use so packing reflects reality. Limits cap burst: CPU throttles past the limit, memory kills past it. Set CPU limits generously (throttling is survivable) and memory limits from measured peaks plus headroom (kills are not).
QoS class falls out of the settings, and the kubelet evicts by class under pressure. Guaranteed means every container has equal request and limit for both CPU and memory: last evicted. Burstable means at least one request or limit set but unequal: evicted by need. BestEffort means nothing set: first to die. Check with kubectl get pod -o jsonpath on status.qosClass instead of guessing.
Worked example
An API container measured at 200m CPU steady with 400m peaks, 256Mi steady with 500Mi peaks:
resources:
requests: { cpu: "200m", memory: "256Mi" }
limits: { cpu: "600m", memory: "640Mi" }Requests mirror steady state so the scheduler packs truthfully. The CPU limit allows burst without complaint. The memory limit clears the measured peak with room, because the alternative to headroom is an OOMKill at the worst possible moment. Status shows Burstable (request differs from limit); making them equal would promote it to Guaranteed at the cost of reserved-but-idle room.
Exam notes
Memory without limits is the top killer: one leak takes the pod, then the neighbors. CPU without requests packs unfairly and throttles mysteriously. And LimitRange plus ResourceQuota can override or reject your values at admission: when a valid manifest is refused, read the namespace policy before rewriting numbers.
Quick check
A 4-question self-check. Your answers stay on your device, are never stored or sent. Only a passing score (for example 3 of 4) is saved, and only to unlock lesson progress: at least 3 correct is required before a lesson counts as complete. It never counts toward any certification assessment.
Lesson feedback
No published feedback yet.
Log in and complete the lesson to leave feedback.
Exercise
For a fictional worker container (150m steady, 500m spikes, 128Mi steady, 400Mi peaks) write requests plus limits with a one-line justification per value. Then state its QoS class and what happens to it when the node runs out of memory while a Guaranteed pod sits beside it.
Pass criteria
Values justified from measurements with CPU burst room and memory headroom; QoS class correct; eviction order names BestEffort/Burstable first with the Guaranteed neighbor surviving.