Chapter 2 · Practice 1 of 5

Set CPU and memory requests on every container

From Resource requests, limits and scaling

Why it matters

The scheduler places a Pod only on a node whose unreserved capacity covers the sum of its containers' requests. Limits play no part in placement. Without requests, the scheduler treats the Pod as needing almost nothing, packs too many Pods on one node, and the first busy hour turns into evictions and slow responses.

Requests are also what the kubelet reserves for the container, so they decide who gets squeezed when a node runs short.

How to pick numbers:

Start from what the app uses under normal load: kubectl top pod or your metrics system.
Set the request near the steady-state usage, not the peak.
Revisit after real traffic, and after any big change to the code.

Units: CPU in cores or millicores (250m is a quarter of a core), memory in bytes with binary suffixes such as 256Mi and 1Gi.

To check, run kubectl describe node <node> and read "Allocated resources". Requests far above real usage waste money; requests far below it cause contention.

Example

YAML

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