Kubernetes Resource Requests and Limits Explained

Resource requests and limits are how Kubernetes manages CPU and memory allocation for pods. Properly configured requests and limits ensure fair resource sharing, prevent resource starvation, and enable efficient cluster utilization.

Requests vs Limits

A request is the minimum amount of a resource guaranteed to a container. The scheduler uses requests to decide which node to place a pod on. A node will not accept a pod if it cannot satisfy the pod's resource requests.

A limit is the maximum amount of a resource a container can use. For CPU, exceeding the limit causes throttling. For memory, exceeding the limit causes the container to be killed (OOMKilled).

CPU Resources

CPU is specified in millicores (m). 1000m equals 1 CPU core.

• Request 100m: the container is guaranteed 0.1 CPU cores
• Limit 500m: the container cannot use more than 0.5 CPU cores

CPU is a compressible resource. When a container exceeds its CPU limit, it is throttled (slowed down) rather than killed. This means CPU limits affect performance but do not cause container failures.

Memory Resources

Memory is specified in bytes (Mi for mebibytes, Gi for gibibytes).

• Request 256Mi: the container is guaranteed 256 MB of memory
• Limit 512Mi: the container cannot use more than 512 MB

Memory is an incompressible resource. When a container exceeds its memory limit, the kernel OOM killer terminates it. There is no graceful slowdown; the container is killed immediately.

Quality of Service (QoS) Classes

Kubernetes assigns each pod a QoS class based on its resource configuration:

Guaranteed: every container has both requests and limits set, and they are equal. These pods get the highest priority and are least likely to be evicted.

Burstable: containers have requests and limits set, but they are not equal. These pods can burst above their request when resources are available.

BestEffort: no requests or limits set. These pods get the lowest priority and are first to be evicted when the node runs out of resources.

Setting Requests and Limits

Analyze your application's actual resource usage before setting values: 1. Deploy with generous limits and no requests initially 2. Monitor actual CPU and memory usage over several days 3. Set requests to the typical observed usage 4. Set limits to accommodate peak usage with some headroom 5. Continuously monitor and adjust

Tools like the Vertical Pod Autoscaler (VPA) can recommend request and limit values based on observed usage.

Common Mistakes

• Setting limits too low: causes OOMKills (memory) or excessive throttling (CPU)
• Setting requests too high: wastes cluster capacity since reserved resources cannot be shared
• Not setting limits: a misbehaving container can consume all node resources
• Not setting requests: the scheduler cannot make informed placement decisions

Best Practices

• Always set requests for production workloads
• Set memory limits to prevent runaway containers from affecting other workloads
• Use CPU limits cautiously (throttling can cause unexpected latency)
• Monitor resource usage and adjust settings over time
• Use LimitRanges to set default requests and limits per namespace
• Use ResourceQuotas to limit total resource consumption per namespace

Proper resource configuration is one of the most impactful optimizations for Kubernetes cluster efficiency.

Key Takeaways

• Requests guarantee minimum resources and drive scheduling decisions; limits cap maximum usage and trigger throttling (CPU) or OOMKill (memory)
• Setting memory limits is essential to prevent a single misbehaving container from consuming all node resources and affecting other workloads
• CPU limits cause throttling rather than container termination — use them cautiously, as they can introduce unexpected application latency
• QoS classes (Guaranteed, Burstable, BestEffort) determine eviction priority under resource pressure; Guaranteed pods are safest for critical workloads
• Monitor actual resource usage over time and use tools like VPA to set data-driven requests and limits rather than relying on estimates