Resource Requests and Limits
The declared minimum a container is guaranteed (request) and the maximum it may consume (limit) — the two numbers that determine scheduling, packing and throttling.
Requests are what the scheduler uses. A node must have the requested CPU and memory free for a pod to be placed there, and that reservation is held whether or not the container uses it. Requests therefore determine cluster utilisation and cost.
Limits are enforced at runtime, and the two resources behave completely differently:
CPU over the limit is throttled. The container keeps running, slowly. The symptom is latency with no error and no obvious cause — CPU throttling metrics are the diagnostic, and they are rarely on a default dashboard.
Memory over the limit is killed. The container is OOM-killed and restarted, which appears as an unexplained restart loop.
The recurring guidance, which is genuinely contested: always set memory requests and limits equal, because memory is incompressible and an over-committed node will kill something. For CPU, set requests accurately and consider omitting limits, since throttling a container that has spare CPU available on the node harms latency for no benefit. That advice is not universal — multi-tenant clusters usually need CPU limits for fairness — but the reasoning should be explicit either way.
Requests set far above actual usage are the single largest source of wasted cluster spend.