What are Kubernetes Resource Requests and Limits?
Learn how Kubernetes resource requests drive scheduling and limits enforce runtime ceilings, plus how they determine Pod QoS class.
Expected Interview Answer
A resource request is the guaranteed amount of CPU and memory the scheduler reserves for a container on a node, while a limit is the hard ceiling the container is not allowed to exceed at runtime, enforced by the kernel cgroup for CPU throttling and by an OOM kill for memory.
Requests drive scheduling: the kube-scheduler only places a Pod on a node that has enough unreserved capacity to satisfy the sum of all its containers’ requests, so requests are really a capacity-planning promise rather than a runtime cap. Limits are enforced by the container runtime via Linux cgroups — CPU usage above the limit is throttled (the process keeps running but gets less CPU time per period), while memory usage above the limit triggers the kernel OOM killer to terminate the container, which then restarts per its restart policy. The relationship between requests and limits determines a Pod’s QoS class: Guaranteed when requests equal limits for every container, Burstable when requests are set but lower than limits, and BestEffort when neither is set, and this class is exactly what the kubelet uses to decide eviction order under node memory pressure. Getting requests too low causes overcommitted, thrashing nodes, while limits set too low cause needless CPU throttling or OOM kills even though the workload is healthy.
- Lets the scheduler pack nodes efficiently without overcommitting
- Protects the node from a single runaway container starving others
- Drives the Pod QoS class used for eviction ordering
- Makes capacity planning and autoscaling decisions predictable
AI Mentor Explanation
A resource request is like a team booking a guaranteed net-practice slot at the academy — the ground keeper reserves that block of time and space no matter what else is happening. A limit is like the strict curfew rule that no session may run past a fixed hour even if the coach wants more time; go over and the ground staff cut the lights immediately. If a team never books a slot at all, they only get leftover time whenever the ground happens to be free, and get bumped first if a booked team needs the space. This is exactly why requests reserve capacity while limits cap it and unrequested sessions get evicted first.
Step-by-Step Explanation
Step 1
Set requests
Declare requests.cpu and requests.memory per container — this is what the scheduler uses to place the Pod.
Step 2
Set limits
Declare limits.cpu and limits.memory — the cgroup ceiling the runtime enforces at execution time.
Step 3
Kubernetes assigns QoS
Requests == limits on every container gives Guaranteed; requests < limits gives Burstable; neither set gives BestEffort.
Step 4
Runtime enforcement kicks in
CPU over the limit is throttled via CFS quotas; memory over the limit triggers an OOM kill and container restart.
What Interviewer Expects
- Clear distinction that requests drive scheduling while limits drive runtime enforcement
- Knowledge that CPU limits throttle but memory limits OOM-kill
- Understanding of how requests/limits determine the Pod QoS class
- Awareness that unset requests lead to unpredictable node overcommitment
Common Mistakes
- Saying requests and limits are the same thing
- Believing a CPU limit breach kills the container like a memory limit breach does
- Forgetting to set requests, leading to poor scheduling decisions
- Not connecting requests/limits to the Pod QoS and eviction order
Best Answer (HR Friendly)
“Requests tell Kubernetes the minimum CPU and memory a container needs so the scheduler can place it on a node with enough room, while limits set the maximum it is ever allowed to use so one container cannot starve its neighbors. Getting both right keeps nodes efficiently packed and prevents a single misbehaving service from taking down everything else on the same machine.”
Code Example
apiVersion: v1
kind: Pod
metadata:
name: api-server
spec:
containers:
- name: api
image: myapp/api:2.3
resources:
requests:
cpu: "250m"
memory: "256Mi"
limits:
cpu: "500m"
memory: "512Mi"Follow-up Questions
- What is the difference between the three Kubernetes QoS classes?
- What happens when a container exceeds its memory limit versus its CPU limit?
- How does a LimitRange or ResourceQuota interact with per-container requests and limits?
- Why might a Pod get evicted even though its own limits were not exceeded?
MCQ Practice
1. What does the Kubernetes scheduler use to decide which node to place a Pod on?
The scheduler sums each container's requests and only places the Pod on a node with enough unreserved capacity to satisfy that sum.
2. What happens when a container exceeds its memory limit?
Memory limits are hard; exceeding them triggers the kernel OOM killer to terminate the container, unlike CPU limits which throttle.
3. Which QoS class is assigned when requests equal limits for every container in a Pod?
A Pod gets Guaranteed QoS only when every container has requests set equal to its limits for both CPU and memory.
Flash Cards
What drives scheduling in Kubernetes? — Resource requests — the scheduler places Pods based on requested, not limit, capacity.
CPU limit breach vs memory limit breach? — CPU is throttled via cgroups; memory triggers an OOM kill and restart.
What is Guaranteed QoS? — When every container's requests equal its limits for CPU and memory.
What happens to a Pod with no requests set? — It gets BestEffort QoS and is evicted first under node resource pressure.