Requests reserve capacity for the scheduler; limits cap use at runtime.

The two settings answer different questions, and together they decide a Pod's quality-of-service class and who is evicted first.

container resources

resources:
  requests: {cpu: 500m, memory: 512Mi}  # scheduler reserves this
  limits:   {cpu: "1",  memory: 1Gi}      # kernel enforces this

CPU over limit

Throttled: slowed down, never killed.

Memory over limit

OOMKilled: the kernel kills the process.

Why it matters

The scheduler places a Pod only where unreserved requests fit. Set requests too low and a node is oversold; too high and capacity sits idle and costs money.

Guaranteed

requests equal limits for every container. Evicted last. Use for payments, databases.

Burstable

requests set below limits (or limits missing). Middle priority. The common default.

BestEffort

no requests or limits at all. Evicted first under node memory pressure. Avoid in production.

Requests decide placement; limits decide enforcement

Resources are set per container. A request is what the scheduler reserves: it will place the Pod only on a node whose unreserved capacity covers the sum of requests. It is also the guaranteed minimum under contention. A limit is a ceiling enforced by the Linux kernel through cgroups. Mixing these up is one of the most common Kubernetes misunderstandings: requests drive scheduling, limits drive runtime enforcement.

The enforcement differs by resource. CPU is compressible: a container exceeding its CPU limit is throttled, so it runs slower but survives. Memory is not: a container exceeding its memory limit is killed by the kernel and shows as OOMKilled. This is why memory limits should be sized with headroom while CPU limits are sometimes omitted deliberately to avoid unnecessary throttling, a design choice some teams make.

From requests and limits Kubernetes derives a QoS class. Guaranteed (every container's requests equal its limits) is evicted last under node pressure; BestEffort (nothing set) is evicted first; Burstable sits between. Critical workloads such as payments should be Guaranteed. Reveal the three classes with the right arrow.

Production gotcha: setting no requests makes a Pod BestEffort and also leaves the scheduler blind, so nodes end up overcommitted and neighbours starve each other. Platform teams enforce defaults with a LimitRange, covered next, and size requests from real usage, which is the subject of the capacity planning chapter in Deck 6.