Requests, limits and QoS classes

Requests and limits are the most important numbers in a Pod spec, and they mean different things.

• Requests are what the scheduler reserves. A Pod is only placed on a node with enough unreserved capacity to cover its requests.
• Limits are what the container may use at most. Exceeding a memory limit gets the container killed (OOMKilled). Exceeding a CPU limit gets it throttled, slowed down rather than killed.

resources:
  requests:
    cpu: 250m
    memory: 300Mi
  limits:
    memory: 300Mi

QoS classes

From requests and limits, Kubernetes assigns each Pod a Quality of Service class:

• Guaranteed: every container has requests equal to limits for both CPU and memory.
• Burstable: at least one request or limit is set, but not Guaranteed.
• BestEffort: no requests or limits at all.

When a node runs short of memory, the kubelet evicts Pods to protect itself, and it considers BestEffort Pods and those using the most memory above their requests first. A BestEffort Pod on a busy node is the first to go.

Practical guidance

• Always set memory requests, and set the memory limit equal to the request for most services. Memory is not compressible, and a predictable limit prevents one Pod from starving its neighbours.
• Always set CPU requests from measured usage, so scheduling is realistic.
• Be careful with CPU limits. They can cause throttling and latency spikes even when the node has idle CPU. Many teams omit CPU limits for latency sensitive services and rely on requests for fair sharing. Others keep them for strict multi tenant isolation. Decide deliberately.

Measuring instead of guessing

kubectl top pods

Short snapshots mislead. Use Prometheus to look at usage over a week, for example the 95th percentile of working set memory and CPU usage, and set requests a little above typical usage. The Vertical Pod Autoscaler in recommendation mode can suggest values without changing anything.

Seeing the consequences

kubectl describe pod api-7d9f... | grep -A3 "Last State"

Reason: OOMKilled with exit code 137 means the memory limit was hit. Throttling does not appear in describe; you see it in the container_cpu_cfs_throttled_periods_total metric.

In the lab, run the memory leak scenario and watch the restarts and evictions happen in the order these rules predict.