Two Different Jobs
Requests and Limits look similar in a YAML file but serve entirely different purposes. Conflating them is one of the most common mistakes in Kubernetes configuration.
Requests — A Promise to the Scheduler
A Request is a guarantee: "I need at least this much to function." The Kubernetes Scheduler reads Requests when deciding which Node to place a Pod on. It sums up all existing Requests on a Node and compares that total against the Node's allocatable capacity. If there isn't enough headroom, the Pod is not scheduled there — even if the Node's actual CPU usage at that moment is near zero.
Think of a Request like a hotel reservation. The hotel holds a room for you regardless of whether you're physically in it. The room is "spoken for" in their system.
Limits — A Ceiling Enforced by the Kernel
A Limit is a hard cap: "Never let this container use more than this." The Scheduler completely ignores Limits — they play no role in placement decisions. Instead, the Linux kernel enforces Limits at runtime using control groups (cgroups). If a container tries to exceed its memory Limit, the kernel kills it. If it tries to exceed its CPU Limit, the kernel throttles it.
Think of a Limit like the physical size of a fuel tank. You can't pump in more than it holds, no matter how much you want to.
In a Pod spec, a container might request 256Mi of memory and 250 millicores of CPU (250m = 0.25 of one core), with limits of 512Mi and 500m. The Scheduler reserves 256Mi of memory and 0.25 CPU on the chosen Node. At runtime, the container can burst up to 512Mi and 0.5 CPU before the kernel intervenes.
CPU units: 1000m (millicores) = 1 full CPU core. 250m = one quarter of a core.
Memory units: Mi = mebibytes (1 Mi = 1,048,576 bytes). Gi = gibibytes. Use Mi/Gi rather than MB/GB to avoid ambiguity.
Interviewers frequently ask: "If a Node has 8GB of RAM and all Pods are using only 2GB, why won't Kubernetes schedule a new Pod requesting 4GB?" The answer is that the Scheduler looks at the sum of Requests, not actual usage. If existing Pods have requested 6GB total, only 2GB of allocatable capacity remains — regardless of real-time consumption. This distinction between "requested" and "used" is fundamental to Kubernetes scheduling.