Misconfigurating resource requests and limits is one of the most common causes of instability in Kubernetes clusters. Learn the difference, how the scheduler uses them, and how to set them correctly.

# Kubernetes Resource Requests and Limits Explained Resource requests and limits are some of the most misunderstood fields in a Kubernetes pod spec. Getting them wrong leads to OOMKilled pods, noisy neighbors, and over-provisioned clusters. ## Requests vs Limits ```yaml resources: requests: memory: "256Mi" cpu: "250m" limits: memory: "512Mi" cpu: "500m" ``` - **Requests** are what the scheduler uses to find a node with enough capacity. The pod is *guaranteed* these resources. - **Limits** are the hard ceiling. Exceed the memory limit → OOMKilled. Exceed the CPU limit → throttled (not killed). ## Quality of Service Classes Kubernetes assigns a QoS class based on your configuration: | Class | Condition | Eviction priority | |---|---|---| | **Guaranteed** | Requests == Limits | Last to be evicted | | **Burstable** | Requests < Limits | Middle priority | | **BestEffort** | No requests/limits set | First to be evicted | ## Common Mistakes **1. Setting limits but not requests:** The scheduler can't make good decisions → pods land on full nodes. **2. Setting CPU limits too low:** CPU throttling is silent but devastating to latency-sensitive apps. Consider removing CPU limits and relying on requests alone. **3. No limits at all (BestEffort):** One runaway container can starve the entire node. ## Recommended Approach 1. Load test your application and observe actual usage with `kubectl top pods`. 2. Set requests to your **P50 usage** and limits to your **P99 usage**. 3. For CPU, set requests conservatively; consider dropping CPU limits. 4. Enable the **Vertical Pod Autoscaler (VPA)** in recommendation mode to get data-driven suggestions. Right-sizing resource configuration is an ongoing process, not a one-time setting.