Kubernetes Resource Requests and Limits
The declared minimum a container is guaranteed and the maximum it may consume, which drive scheduling, eviction and throttling in ways that are easy to get wrong.
Requests are what the scheduler uses to place pods and what the pod is guaranteed. Limits are the ceiling. The gap between them determines behaviour under contention, and the two resources behave very differently.
Exceeding a memory limit terminates the container immediately — memory is incompressible, so there is no throttling, only an out-of-memory kill. Exceeding a CPU limit throttles it, and this is the setting that causes the most confusion in practice: a container is throttled at its limit even when the node has idle CPU, so a low CPU limit produces latency spikes that look like a mysterious application problem and are entirely self-imposed.
The failure modes at the extremes. Requests set too high waste capacity, since the scheduler reserves it whether or not it is used, and cluster utilisation collapses. Requests set too low cause overcommitment, so pods are scheduled onto nodes that cannot actually serve them and eviction follows under load.
The guidance that has settled from operating this at scale: set memory request and limit equal, so the pod is guaranteed what it needs and is killed predictably rather than being evicted at an arbitrary moment. Set a CPU request based on measured usage and consider omitting the CPU limit for latency-sensitive services, letting them burst into idle capacity — a position that is counter to intuition and well supported by production experience.