Kubernetes Requests and Limits: How to Right-Size Pods Without Breaking Reliability
Blog post from Cast AI
Kubernetes resource requests determine pod scheduling and reserved CPU and memory, while runtime limits cap consumption, causing CPU throttling when exceeded or OOMKilled terminations for memory breaches; these settings also establish QoS eviction priority during node memory pressure. The guide argues that widespread overprovisioning—reportedly 69% unused requested CPU and 79% excess memory—raises costs and triggers unnecessary cluster scale-outs because schedulers and autoscalers act on requests rather than observed use. It recommends deriving CPU requests from two-week p95 usage data and memory limits from p99 working-set memory with headroom, monitoring throttling ratios and memory trends to distinguish insufficient limits from leaks, and explicitly sizing JVM heaps. CPU limits may be omitted or set generously for latency-sensitive services to avoid CFS-related tail-latency spikes, but remain useful for batch and multi-tenant workloads. It also advises avoiding simultaneous CPU-driven HPA and active VPA, using VPA recommendations cautiously, and enforcing organization-wide controls through LimitRange defaults and ResourceQuota caps, deployed in that order to prevent admission failures.
No tracked trend matches for this post yet.
Use this post, company, and trend context to find content marketing opportunities, perform competitive analysis, or address product feature gaps via the Plushcap MCP server or the Plushcap API.