Skip to main content
This lesson compares Kubernetes resource requests and limits, explains how they influence scheduling and runtime behavior, and shows a practical workflow to pick sensible values for containers. Correct right-sizing reduces outages and wasted capacity while improving scheduling accuracy.

​
What are Requests?

Requests are the minimum resources a Pod needs and are used by the Kubernetes scheduler to decide where to place Pods. When you set a container to request 100m CPU and 128Mi memory, the scheduler treats that capacity as reserved on the target node before admitting the Pod. Key points:
  • Drives placement decisions.
  • Guarantees that, under normal conditions, the Pod can use at least the requested amount.
  • The scheduler sums requests across all Pods when deciding if a node has enough allocatable resources.

​
What are Limits?

Limits define the maximum resources a container may consume at runtime. The kubelet on the node enforces limits. Behavior when limits are exceeded:
  • CPU: the container is throttled (slower CPU access but continues running).
  • Memory: the container is terminated (OOMKilled) if it exceeds the memory limit.
Requests affect scheduling; limits affect runtime enforcement. Understanding this split prevents both insufficient resource reservations and runaway resource consumption.
An infographic titled "Requests vs Limits" that compares Kubernetes resource Requests (guaranteed minimum used by the scheduler) with Limits (maximum enforced by the kubelet), and notes meanings and consequences if exceeded (e.g., CPU throttling, OOMKill).

​
Scheduling example

Imagine a node with 4 CPUs and three Pods arriving. Each Pod requests 1 CPU and sets a limit of 2 CPUs.
  • Scheduler considers only requests: 1 + 1 + 1 = 3 CPU requested, so all three Pods are scheduled because 3 ≤ 4.
  • Node remaining allocatable CPU is 1.
  • If a fourth Pod arrives requesting 2 CPUs, the scheduler will not place it because only 1 CPU remains allocatable.
The scheduler does not account for currently idle CPU cycles or potential bursts above requests—only the sum of requests matters for placement.

​
Runtime behavior

At runtime, each Pod is guaranteed its request (1 CPU) and may burst up to its limit (2 CPUs). If all Pods burst simultaneously, total demand could reach 6 CPUs on a 4-CPU node. The Linux Completely Fair Scheduler (CFS) will fairly distribute CPU cycles between containers, resulting in throttling as workloads contend for limited CPU. Practical implication: CPU bursting lets workloads be flexible, but simultaneous bursts cause performance degradation across contending Pods.
A diagram explaining Kubernetes CPU requests and limits, showing three pods (A, B, C) on a node with 4 CPUs where each pod requests 1 CPU and can burst to 2 CPUs. It shows 3 CPU requested (75% committed) and notes that CPU throttling occurs if all pods try to burst.

​
QoS classes

Kubernetes assigns a Quality of Service (QoS) class to each Pod based on how requests and limits are configured. You do not set the class directly—Kubernetes infers it. Eviction priority under memory pressure: BestEffort → Burstable → Guaranteed. Remember: CPU limit results in throttling (degraded latency/throughput), whereas memory limit can cause OOMKills (process termination). Treat memory limits conservatively.

​
Right-sizing workflow

A repeatable workflow helps you choose requests and limits with confidence:
  1. Profile actual usage
    • Run workloads under realistic, production-like load for a representative time window (hours to weeks).
    • Collect CPU/memory metrics using Prometheus, kubectl top, or your monitoring stack.
  2. Set requests to a conservative percentile
    • Use P95 (95th percentile) of observed usage for requests to cover normal operation and frequent spikes.
  3. Set limits to provide controlled headroom
    • A common starting point is 2×–3× the request value. This prevents short spikes from triggering OOMKills while avoiding unbounded resource use.
    • Some teams intentionally omit CPU limits for extremely latency-sensitive services, but still set memory limits.
  4. Monitor and iterate
    • Watch for CPU throttling metrics and OOMKills, then tune requests/limits.
    • Consider automated recommendations from tools like the Vertical Pod Autoscaler (VPA).
Example container spec (YAML) showing requests and limits:
Use monitoring and A/B testing to validate that these settings meet latency, throughput, and reliability targets.
An infographic titled "The Right-Sizing Workflow" showing four numbered steps: Profile Actual Usage, Set Requests at P95, Set Limits at 2–3x, and Monitor and Adjust, each with a brief explanatory note. It outlines a process for measuring resource usage and tuning CPU/memory requests and limits.
Callout summary
  • Requests determine scheduling placement; limits control runtime behavior—do not confuse them.
  • Use QoS classes intentionally: set requests == limits for critical workloads to achieve Guaranteed QoS.
  • CPU limits lead to throttling; memory limits can cause OOMKills—be conservative with memory.
  • Profile first (P95 for requests), give reasonable limit headroom (often 2–3× requests), and continuously monitor or use tools like VPA to refine settings.
Right-sizing is an iterative process: measure, set conservative defaults, observe, and adjust to balance cost, performance, and reliability.

Watch Video