What's the difference between requests and limits, and how do they define a pod's QoS class?
Quick Answer
Requests are the resources guaranteed and used for scheduling; limits are the hard cap enforced at runtime. The relationship between them sets the pod's QoS class — Guaranteed, Burstable, or BestEffort — which decides eviction order under pressure.
Detailed Answer
A request is what the scheduler reserves on a node and what the pod is guaranteed; a limit is the ceiling the kernel enforces (CPU is throttled above its limit, memory over its limit gets the container OOMKilled). Their relationship defines QoS: Guaranteed (every container sets requests == limits for both CPU and memory) — last to be evicted; Burstable (requests set but less than limits, or only some resources set) — evicted after BestEffort; BestEffort (no requests or limits at all) — first to be evicted under node pressure. This matters because under memory pressure the kubelet evicts BestEffort then Burstable-over-request pods first. Practical guidance: always set memory requests==limits for critical workloads to get Guaranteed QoS and predictable behavior; set CPU requests for scheduling but be cautious with hard CPU limits (throttling can hurt latency).
Code Example
resources:
requests: { cpu: "500m", memory: "512Mi" }
limits: { cpu: "500m", memory: "512Mi" } # requests==limits => Guaranteed QoS
kubectl get pod web -o jsonpath='{.status.qosClass}'Interview Tip
Connect QoS to eviction order (BestEffort → Burstable → Guaranteed). And note the CPU-limit nuance: hard CPU limits cause throttling, so many teams set CPU requests but not CPU limits for latency-sensitive services.