Understanding Kubernetes requests and limits
Configuring compute boundaries correctly ensures workloads remain reliable while maximizing node efficiency. In Kubernetes, every container can specify requests and limits for CPU and memory.
Requests dictate scheduling. When a pod is submitted, the
kube-scheduler inspects node allocatable capacity to find nodes with enough
unreserved capacity. If requests exceed available space, the pod stays in Pending.
Because scheduling looks only at requests, idle pods with oversized requests lock up compute.
Limits enforce runtime caps via Linux cgroups. Exceeding memory limits triggers the kernel OOM killer, terminating the container. Exceeding CPU limits causes CFS throttling rather than eviction, slowing processing.
Quality of Service classes
Kubernetes assigns one of three Quality of Service (QoS) classes based on resource declarations:
- Guaranteed: Every container specifies identical requests and limits for CPU and memory. These pods have highest scheduling priority and lowest eviction risk.
- Burstable: Requests are lower than limits, or only requests are configured. Workloads can burst into idle node headroom but face eviction before Guaranteed pods.
- BestEffort: No requests or limits are set. These pods are evicted first under memory pressure.
Worked examples
-
Web API: Request of
cpu: 250m, limit of1000m, with request and limit matched atmemory: 256Mito avoid OOM kills during bursts. -
Java service: Setting
cpu: 2000mandmemory: 4Gion both requests and limits for Guaranteed QoS and stable heap operation. -
Worker pod: Request of
cpu: 100mwith unbounded limit, allowing batch jobs to consume spare node CPU.
Common mistakes
-
Case-insensitive memory units: Kubernetes expects binary
MiorGi. Writing512mior512mbfails validation. - Unmatched memory limits: Allowing memory to burst risks sudden OOM terminations when nodes experience pressure.
- Tight CPU limits: Overly restrictive CPU limits cause CFS quota throttling and latency spikes on multithreaded runtimes.
For detailed advice, see our guide on Kubernetes Requests vs Limits.
Frequently asked questions
What is the difference between CPU and memory limits?
CPU is compressible: reaching a CPU limit throttles execution cycles without killing the process. Memory is incompressible: exceeding a memory limit triggers the Linux kernel OOM killer, terminating the container immediately with exit code 137.
How do I achieve the Guaranteed QoS class?
A pod receives Guaranteed QoS when every container sets both CPU and memory, and each request equals its limit. Guaranteed pods have the lowest eviction risk during node memory pressure.
Why does CPU throttling happen with low host CPU?
Kubernetes enforces CPU limits using CFS quotas over 100ms periods. Multithreaded apps can exhaust their quota within milliseconds, freezing execution until the next period despite idle host cores.
How does the scheduler use resource requests?
The kube-scheduler places pods by summing requests against node allocatable capacity. Real-time consumption is ignored; only declared requests determine scheduling.
Can I omit CPU limits safely?
Yes. Many teams omit CPU limits to prevent CFS throttling while using requests for scheduling and HPA for autoscaling. Memory limits should always remain configured.