A pod declares a CPU request of 200m with a limit of 1 CPU, and a memory request and limit both of 512Mi. Which statement is correct?
Show the full answer Hide the answer
What is being tested
The difference between a scheduling promise and a runtime ceiling, and the fact that CPU and memory behave differently because one is compressible and the other is not. Almost every mis-sized Kubernetes workload comes from conflating these.
The mechanism
- Request is used by the scheduler to decide whether a pod fits on a node, and it is subtracted from the node's allocatable capacity whether or not the pod uses it. It also sets the cgroup's CPU shares, which determine the proportion of CPU the container wins when there is contention.
- Limit is enforced by the kernel. For CPU it becomes a CFS quota per 100 ms period, so the container is frozen when it exhausts its slice. For memory there is no equivalent to freezing: a process that wants a page it cannot have cannot be slowed down, so the container is killed with an out-of-memory error and restarted.
That asymmetry drives the usual advice: set memory request equal to memory limit - you want to be scheduled for exactly what you will be killed for - and be careful with CPU limits on latency-sensitive services, because the quota produces tail latency at low average utilisation.
Quality of service, which follows from these two numbers
| Class | Condition | What it means at eviction time |
|---|---|---|
| Guaranteed | requests equal limits for every resource in every container | evicted last |
| Burstable | requests set and lower than limits | evicted by how far usage exceeds the request |
| BestEffort | nothing set | evicted first |
So the pod in the question is Burstable, and under node memory pressure it is a candidate for eviction before a Guaranteed pod - a consequence of the CPU numbers differing, which is not obvious from either number on its own.
Why the other options fail
- "Both are enforced at runtime." Then a request would be a cap, and a node with idle CPU could not be used by a pod that needs it. Requests exist for the scheduler, not for the kernel's bandwidth controller.
- "Memory limits throttle." They cannot. A page either exists or does not; the kernel's only option is to refuse the allocation, and the usual outcome is the process being killed. Teams that expect throttling are surprised by restart loops under memory pressure.
- "Equal memory values are documentation." They change the QoS class, and with it the eviction order - which is precisely what decides whether your pod survives a node under pressure.
When this is the wrong model to apply
On a single-tenant node pool running one workload, these numbers matter much less: there is no neighbour to protect and the node's capacity is the real limit. The cost of getting them wrong scales with how much the node is shared, which is the argument for separating latency-sensitive services onto their own pools rather than tuning limits ever more finely.