Kubernetes Resource Requests and Limits Explained

Requests and limits tell Kubernetes how much CPU and memory a container needs and may use. They affect scheduling, performance and stability, and getting them wrong is a top cause of mysterious slowdowns and crashes.

resources:
  requests:
    cpu: 250m        # 0.25 of a CPU core
    memory: 256Mi
  limits:
    memory: 512Mi

Requests: what the scheduler reserves

A Pod is only placed on a node with enough unrequested capacity. Requests are a guarantee: under contention, CPU is shared in proportion to requests.

Limits: the ceiling

• Memory limit exceeded - the container is killed (OOMKilled, exit code 137) and restarted.
• CPU limit exceeded - the container is throttled, not killed. Requests get slow, and latency spikes even when the node has idle CPU.

A sensible default

• Always set CPU and memory requests.
• Set a memory limit, often equal to or a bit above the request.
• Many teams leave out CPU limits for latency-sensitive services to avoid throttling, relying on requests for fair sharing. Others set them for strict multi-tenant isolation. Decide deliberately.

QoS classes

• Guaranteed - requests equal limits for CPU and memory in every container. Evicted last.
• Burstable - requests set, limits higher or missing.
• BestEffort - nothing set. First to be evicted under pressure.

Sizing from real data

kubectl top pods -n shop                  # current usage (needs metrics-server)

Look at usage over days in your monitoring (Prometheus, cloud dashboards). Set requests near typical usage (for example the 90th percentile) and memory limits with headroom above the peak. The Vertical Pod Autoscaler can recommend values automatically.

Runtime awareness

Make sure your runtime respects container limits: set Node.js --max-old-space-size below the memory limit, and note that recent Go versions set GOMAXPROCS from the container's CPU limit automatically.