Skip to content
beginner Phase 8 · Scaling & Autoscaling

Resource Requests & Limits

Configure resource requests and limits for QoS and resource management.

45m
0 problems
Topic Progress 0%

Requests Reserve, Limits Enforce

Requests Reserve, Limits Enforce

Requests are what the scheduler uses for placement and what the node reserves: sum of container requests must fit a node or the pod stays Pending. Limits are the runtime ceiling enforced through cgroups.

  • CPU limit → the cgroup throttles the container: it simply stops receiving CPU time for the rest of each period. Latency-sensitive services often feel this as tail latency.
  • Memory limit → the kernel OOM-kills the container when usage exceeds it. Memory does not "throttle"; it dies, typically visible as exit code 137.

Memory requests also set the QoS and eviction math the kubelet uses when the node runs out of memory.

Setting Them and the QoS Classes

Setting Them and the QoS Classes

resources:
  requests: { cpu: "250m", memory: "256Mi" }
  limits:   { cpu: "1",   memory: "512Mi" }

Kubernetes derives a QoS class per pod:

Class Condition
Guaranteed every container sets requests = limits for CPU and memory
Burstable at least one request/limit set, but not equal everywhere
BestEffort no requests or limits at all

Under node memory pressure the kubelet evicts BestEffort first, then Burstable pods using most above their request; Guaranteed pods are last. LimitRange can impose per-namespace defaults so nothing ships BestEffort.

Pitfalls and Interview Angles

Pitfalls and Interview Angles

No requests → BestEffort: scheduled by leftovers, first to be evicted, unusable by HPA utilization.

Limit too low → OOMKilled restarts. Check kubectl describe pod last state and kubectl get pod -o jsonpath='{.status.containerStatuses[*].lastState}'.

CPU limit too tight → throttling shows up as p99 spikes while CPU graphs look "fine". Teams either raise the limit or run Burstable with generous limits.

Distinguish eviction (kubelet frees node resources, pod rescheduled) from OOMKill (cgroup kills one container). Interview angle: walk the Guaranteed/Burstable/BestEffort ordering and cite the exact failure signal for each misconfiguration.

Quiz

1. What does the scheduler read when placing a pod?

Question 1 options

2. A container is repeatedly restarted with reason OOMKilled. What is wrong?

Question 2 options

3. Which pod is Guaranteed?

Question 3 options

Flashcards

Question

requests vs limits

Click to reveal answer

Answer

Requests drive scheduling and reservation; limits are the runtime cap (CPU throttled, memory OOM-killed).

Question

QoS classes

Click to reveal answer

Answer

Guaranteed (requests=limits everywhere), Burstable (some set), BestEffort (none) — eviction order under node pressure follows this.

Question

Exit code 137

Click to reveal answer

Answer

SIGKILL from the kernel OOM killer — the container exceeded its memory limit.

Question

CPU throttling

Click to reveal answer

Answer

Hitting the CPU limit means cgroup time slices stop; shows as tail latency, not crashes.

Revision Notes

Key Takeaways

  • 1. Requests are capacity reservations for scheduling; limits are cgroup-enforced runtime ceilings
  • 2. QoS class falls out of how you write requests/limits and controls eviction priority
  • 3. OOMKilled and throttling have distinct signals — read lastState and latency graphs, not wishful thinking

Interview Tips

  • • Tie each misconfiguration to its exact symptom: no requests → BestEffort eviction, low memory limit → 137, tight CPU limit → p99 spikes
  • • Explain why Guaranteed helps node pressure: the kubelet evicts it last

Cheat Sheet

requests = scheduler reservation; limits = cgroup ceiling (CPU throttles, memory OOM-kills/137). QoS: Guaranteed > Burstable > BestEffort in eviction. Defaults via LimitRange.

Continue Learning