Kubernetes Resource Requests Are Not Capacity Planning
Kubernetes resource requests are often treated as application estimates and then aggregated into a capacity forecast. That produces precise-looking numbers, but it does not create a reliable planning model.
Requests are scheduling contracts. Capacity planning must also account for observed demand, failure domains, rollout behavior, system overhead, and the spare capacity required for recovery.
What matters
- Explicit service profiles: Standardize resource classes for common workload types instead of accepting arbitrary requests without context.
- Measured demand: Compare requests with sustained and peak usage. Neither historical consumption nor declarations are sufficient alone.
- Failure-domain reserves: Keep enough allocatable capacity to absorb node or zone loss without depending on emergency provisioning.
- Deployment behavior: Include surge pods, batch concurrency, autoscaler limits, and disruption policies in capacity calculations.
- Clear ownership: Application teams own workload behavior. Platform teams own cluster headroom, forecasting inputs, and escalation thresholds.
Recommendation
Use requests to express the resources a workload needs for predictable scheduling. Use a separate capacity model to translate workload demand and failure assumptions into infrastructure requirements.
The objective is not maximum utilization. It is controlled headroom with transparent trade-offs. A platform that schedules normally but cannot tolerate maintenance, rollout surges, or infrastructure failure is already operating beyond safe capacity.