In this lesson, you will learn how to balance cluster efficiency and system stability by tuning your Pod resource configurations based on real-world telemetry.
Moving Beyond "Guestimates"
When deploying services, it is tempting to set arbitrary values for resources. However, in a production environment, imprecise requests and limits lead to either "bin-packing" inefficiency (underutilization) or frequent OOM (Out of Memory) kills and CPU throttling (performance degradation).
Before setting these values, you must have already established resource baselines (Concept 25). Once you have observed your application's 95th percentile (p95) usage patterns over a typical business cycle, you can define precise constraints.
Applying Requests vs. Limits
Think of these two settings as different mechanisms for traffic control:
- Requests: These are your "guaranteed" resources. Kubernetes uses these to schedule the Pod; if a node doesn't have enough available capacity to satisfy the
request, the scheduler will skip it. Setting these too high creates "wasted" space that no other Pod can use. - Limits: These are your "hard ceilings." If a process exceeds its CPU limit, it will be throttled; if it exceeds its memory limit, the kernel will kill the process.
For example, if your baseline monitoring shows that your microservice usually consumes 128Mi of memory but occasionally spikes to 256Mi during startup, your manifest might look like this:
resources:
requests:
memory: "150Mi" # Slightly above the average to ensure stability
cpu: "250m"
limits:
memory: "300Mi" # A buffer to handle spikes without triggering OOM
cpu: "500m"
Preventing Starvation
By aligning your requests closely with your actual observed p95 usage, you allow the Kubernetes scheduler to pack nodes densely without risking "node pressure" events. When every service in a namespace has accurately defined requests, you minimize the risk of a single "noisy neighbor" causing node starvation. Always review these values during your post-incident reviews (Concept 6); if a service crashed under load, your limits were likely too tight, or your requests were too low to guarantee the baseline performance required for your service to recover.
Key Takeaway: Precise requests and limits are not guesses—they are mathematical reflections of your observed telemetry that guarantee cluster density and prevent resource starvation.