Kubernetes Requests vs Limits: What Actually Happens in Production

Kubernetes resource management is one of the most misunderstood causes of production outages. While CPU and memory requests and limits appear simple, their real-world behavior under load is governed by the Kubernetes scheduler and Linux cgroups.

This article explains, in production terms, how Kubernetes requests and limits work, why they cause real outages, and how experienced teams configure them safely at scale.

What Are Kubernetes Requests and Limits?

In Kubernetes, containers can specify CPU and memory requests and limits. Requests influence scheduling decisions, while limits define hard usage boundaries. However, CPU and memory behave very differently in production environments.

How CPU Requests and Limits Work in Production

CPU is a compressible resource. CPU requests are used only by the scheduler to place pods and determine relative CPU share during contention. Requests are not enforced at runtime.

CPU limits are enforced using Linux CFS quotas. When a container exceeds its CPU limit, it is throttled, causing increased latency and reduced throughput. Throttling may occur even when the node has idle CPU capacity.

Why CPU Limits Often Hurt Performance

In latency-sensitive workloads, CPU throttling introduces unpredictable response times. As a result, many production teams set CPU requests but avoid CPU limits entirely for application containers.

How Memory Requests and Limits Work in Production

Memory is a non-compressible resource. Memory requests are used only for scheduling. Memory limits are strictly enforced by Linux cgroups.

When a container exceeds its memory limit, it is immediately terminated with an OOMKill. The pod is restarted, often resulting in a CrashLoopBackOff.

Kubernetes QoS Classes and Pod Evictions

Kubernetes assigns pods to Quality of Service (QoS) classes based on resource configuration.

During node memory pressure, pods are evicted in the following order: BestEffort, Burstable, then Guaranteed.

Common Production Failures Caused by Misconfiguration

• CPU throttling due to unnecessary limits
• Frequent OOMKills from underestimated memory limits
• Poor autoscaling due to incorrect requests
• Node-level instability from missing memory limits

Production Best Practices for Requests and Limits

• Always set CPU and memory requests.
• Avoid CPU limits for latency-sensitive workloads.
• Always set memory limits with sufficient headroom.
• Use Guaranteed QoS for critical services.
• Monitor CPU throttling and OOMKill metrics continuously.

Conclusion

Kubernetes requests and limits directly shape system stability under load. CPU limits throttle. Memory limits kill. Requests influence fairness and scheduling.

In production, most Kubernetes outages are caused by incorrect resource configuration, not application bugs.