How do resource requests and limits affect pod scheduling and eviction?
How Kubernetes requests and limits drive pod scheduling, QoS classes, throttling, OOM-kills and eviction order — with YAML examples and interview answers.
Expected Interview Answer
Requests are the guaranteed minimum CPU and memory a container needs, and the scheduler uses them to place a pod only on a node with enough allocatable capacity; limits are the hard ceiling a container may consume. Together they determine both where a pod is scheduled and how likely it is to be throttled or evicted under pressure.
The scheduler sums each node's requests and only admits a pod if its requests fit the remaining allocatable resources — limits are ignored at scheduling time. At runtime, exceeding the CPU limit causes throttling, while exceeding the memory limit causes the container to be OOM-killed. Under node memory pressure the kubelet evicts pods based on their Quality of Service class, which is derived from requests and limits: BestEffort pods are evicted first, then Burstable pods exceeding their requests, and Guaranteed pods last.
- Predictable, capacity-aware scheduling
- Protects nodes from resource exhaustion
- Defines QoS classes (Guaranteed, Burstable, BestEffort)
- Enables fair sharing and prioritised eviction
- Improves cluster density and cost efficiency
AI Mentor Explanation
Requests are the minimum overs a bowler is guaranteed in a match — the captain only picks a lineup if every bowler's promised overs fit the innings. Limits are the maximum overs any single bowler may bowl. If the game is disrupted and overs must be cut, the bowlers with no guaranteed spell are dropped first, then those bowling beyond their promised quota, while guaranteed frontline bowlers keep theirs.
Step-by-Step Explanation
Step 1
Set requests
Declare the guaranteed CPU/memory each container needs so the scheduler can place it on a fitting node.
Step 2
Set limits
Declare ceilings so a container cannot starve neighbours; CPU over-limit throttles, memory over-limit is OOM-killed.
Step 3
Scheduler filters nodes
It admits the pod only where the sum of existing requests plus the new pod's requests fits allocatable capacity.
Step 4
QoS class assigned
Requests==limits on all resources gives Guaranteed; some set gives Burstable; none set gives BestEffort.
Step 5
Eviction under pressure
The kubelet evicts BestEffort first, then Burstable over requests, then Guaranteed last.
What Interviewer Expects
- Requests drive scheduling, limits do not
- CPU is throttled, memory triggers OOM-kill
- Correct QoS class derivation
- Eviction ordering by QoS and usage above requests
- Awareness of node allocatable vs capacity
Common Mistakes
- Claiming limits are used for scheduling
- Thinking exceeding a CPU limit kills the pod
- Confusing Guaranteed and Burstable QoS rules
- Ignoring that no requests means BestEffort and first to evict
Best Answer (HR Friendly)
“Requests tell Kubernetes the minimum resources an app needs, so it only places the app on a machine that has room. Limits are the maximum it may use. When a node runs low on memory, apps that asked for the least protection are stopped first, and apps with an exact guaranteed reservation are stopped last.”
Code Example
apiVersion: v1
kind: Pod
metadata:
name: web
spec:
containers:
- name: web
image: nginx:1.27
resources:
requests:
cpu: "500m"
memory: "256Mi"
limits:
cpu: "500m"
memory: "256Mi"kubectl describe node <node> | grep -A5 "Allocated resources"
kubectl get pod web -o jsonpath='{.status.qosClass}{"\n"}'Follow-up Questions
- How are the three QoS classes determined?
- What happens when a container exceeds its memory limit versus its CPU limit?
- How does the scheduler use requests versus limits?
- What is the difference between node capacity and allocatable?
- How do LimitRange and ResourceQuota interact with requests and limits?
MCQ Practice
1. Which value does the Kubernetes scheduler use to place a pod?
The scheduler sums requests against a node's allocatable resources; limits are not considered at scheduling time.
2. What happens when a container exceeds its memory limit?
Memory is incompressible, so exceeding the memory limit causes the container to be OOM-killed.
3. Which pods are evicted first under node memory pressure?
BestEffort pods set no requests/limits and are the first to be evicted, followed by Burstable pods over their requests.
Flash Cards
Which value drives scheduling? — Requests — the scheduler fits them into a node's allocatable capacity.
CPU over limit vs memory over limit? — CPU is throttled; memory is OOM-killed.
How is Guaranteed QoS achieved? — Every container sets requests equal to limits for both CPU and memory.
Eviction order under memory pressure? — BestEffort first, then Burstable over requests, then Guaranteed.