Kubernetes Requests and Limits: Your Pod's Resource Contract

WHY IT EXISTS In a shared cluster, multiple applications run on the same physical nodes. Without rules, one misbehaving or high-traffic application could consume all the CPU or memory, causing other critical applications on that node to slow down or crash. Resource requests and limits were created to solve this "noisy neighbor" problem by providing a mechanism for fair and predictable resource allocation.

THE MENTAL MODEL Think of it like booking an airline ticket. The request is your confirmed seat; the airline (Kubernetes scheduler) guarantees you that space and won't put you on a plane that's already full. The limit is the airline's baggage policy; you can't bring an unlimited amount of luggage, because that would impact other passengers. If you try, they'll either charge you extra (CPU throttling) or refuse to let you board (memory OOMKill).

HOW IT WORKS When you define a Pod, you can specify resource requests and limits for each container. The Kubernetes scheduler uses the request value to decide which node to place the Pod on; it will only pick a node that has enough available capacity to satisfy the request. Once the Pod is running, the Kubelet on that node enforces the limit. If a container exceeds its CPU limit, it gets throttled (its CPU time is restricted). If it exceeds its memory limit, it is terminated with an Out-Of-Memory (OOM) error. This behavior defines a Pod's Quality of Service (QoS) class: Guaranteed (requests equal limits), Burstable (requests are less than limits), or BestEffort (neither are set).

WHEN TO USE IT Always use requests and limits for production workloads. They are essential for building stable, resilient, and multi-tenant systems. Setting them allows Kubernetes to make intelligent scheduling decisions and protects workloads from resource starvation. Even for development, setting them is a good practice to understand your application's resource footprint.

WHEN NOT TO USE IT The only time to omit requests and limits is for throwaway, low-priority tasks where you do not care if they are evicted. This puts them in the "BestEffort" QoS class, making them the first pods to be killed when a node is under resource pressure. For any workload you care about, you should define at least a request.

ONE CANONICAL EXAMPLE A typical web application container might have a memory request of 256Mi and a limit of 512Mi, and a CPU request of "250m" (a quarter of a core) and a limit of "1" (one full core). This configuration tells Kubernetes that the application needs a guaranteed 256Mi of memory and 0.25 CPU to run, but can burst up to 512Mi of memory and 1 full CPU during traffic spikes if those resources are available on the node.