Comparisons
Pairs that get conflated in real conversations, and a few that get treated as synonyms when one is a prerequisite for the other. Neither column wins — what decides is the change in front of you. Each record leads with the confusion, because the confusion is why the record exists.
Requests vs Limits
Two mirror-image errors. Setting them equal "to be safe" wastes the elasticity that makes bin packing work, and setting no request at all makes the scheduler place the pod blind — it will happily pack a node that then cannot serve. The deeper confusion is that the two resources behave completely differently at the limit: exceeding a CPU limit throttles the process, which shows up as latency with unremarkable average CPU; exceeding a memory limit kills it. So the same "we hit the limit" sentence describes a performance problem in one case and a crash in the other.
Set requests to what the workload actually needs to run normally — this is what the scheduler reserves and what capacity planning is based on.
Set limits as the ceiling the kernel enforces — the protection for the node and its neighbours, not a target.
| Dimension | Requests | Limits |
|---|---|---|
| Enforced by | The scheduler, at placement time | The kernel, continuously |
| Effect on placement | Reserves capacity on a node | None |
| Too low | Node oversubscribed; contention under load | CPU throttling or OOM kills in normal operation |
| Too high | Wasted capacity, poor bin packing, higher cost | A misbehaving pod can starve its neighbours |
| CPU at the limit | n/a | Throttled — latency rises, average utilisation looks fine |
| Memory at the limit | n/a | OOM-killed — exit 137, restart, no graceful shutdown |