Kubernetes Requests and Limits: A Practical Guide

Resource requests and limits are the two lines of YAML that decide whether your cluster is stable, efficient, or quietly expensive. They are also the settings teams most often copy-paste and forget.

What requests do

A request is what the scheduler reserves for a container. A pod is placed only on a node with enough unreserved CPU and memory to cover the sum of its requests.

• Requests affect scheduling, not runtime usage.
• Set them too high and nodes look full while sitting idle.
• Set them too low and nodes get overpacked, causing contention.

What limits do

A limit is the maximum a container may use at runtime.

• CPU limit: the container is throttled when it hits the limit. It keeps running, but slower.
• Memory limit: the container is killed (OOMKilled) when it exceeds the limit.

That asymmetry matters. CPU is compressible; memory is not.

Sensible defaults

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

Why this shape works for most web services:

1. Memory request equals memory limit. The scheduler reserves exactly what the container may use, so nodes are never overcommitted on memory.
2. No CPU limit. Throttling often hurts latency more than it protects neighbors. Requests already guarantee each pod its fair share under contention.
3. Start small, then measure. Use real usage data, not guesses.

Measure before tuning

Look at the 95th percentile of actual usage over at least a week:

kubectl top pods -n production --sort-by=memory

For sustained tuning, the Vertical Pod Autoscaler in recommendation mode suggests values without changing anything.

Common mistakes

• Copying the same values to every service. A queue worker and an API have very different profiles.
• Ignoring QoS classes. Pods without requests are evicted first under pressure.
• Setting limits far above requests. This hides overcommitment until a busy day triggers a cascade of OOM kills.

The takeaway

Treat resource settings as living configuration. Review them after major releases, alert on throttling and OOM kills, and let data, not defaults, drive the numbers.