Kubernetes Resource Request Limit Rightsizer
Optimize Kubernetes CPU and memory requests/limits based on actual usage for cost savings. Enter values for instant results with step-by-step formulas.
Formula
Recommended Request = Average Usage × Buffer Multiplier; Recommended Limit = Peak Usage × 1.2
Requests should accommodate typical usage plus headroom for variance (1.2-2x depending on workload type). Limits should exceed peak observed usage to prevent throttling (CPU) or OOMKill (memory). The buffer multiplier varies by workload: web services (1.3x), batch jobs (1.5x), ML workloads (2.0x), databases (1.4x). This formula balances efficiency with reliability.
Worked Examples
Example 1: Web Application - Over-Provisioned
Problem:3-replica web app. Current: 1000m CPU request, 2Gi memory request. Actual usage: 200m avg / 600m peak CPU, 400Mi avg / 800Mi peak memory.
Solution:Analysis: - CPU utilization: 200m / 1000m = 20% (wasteful) - Memory utilization: 400Mi / 2048Mi = 20% (wasteful) Recommended (1.3x buffer for web): - CPU request: 200 × 1.3 = 260m - CPU limit: 600 × 1.2 = 720m - Memory request: 400 × 1.3 = 520Mi - Memory limit: 800 × 1.2 = 960Mi Resource reduction: - CPU: 1000m → 260m (74% reduction) - Memory: 2Gi → 520Mi (75% reduction) Cost impact (assuming $30/core/mo, $5/GB/mo): - Current: 3 × ($30 + $10) = $120/mo - Optimized: 3 × ($7.80 + $2.54) = $31/mo - Savings: $89/mo ($1,068/year)
Result:CPU: 260m/720m | Memory: 520Mi/960Mi | Savings: $89/month
Example 2: ML Inference - Bursty Workload
Problem:ML model serving with high variance. 2 replicas. Current: 2000m CPU, 4Gi memory. Usage: 500m avg / 1800m peak CPU, 2Gi avg / 3.5Gi peak memory.
Solution:Analysis (2.0x buffer for ML): - CPU is bursty: 500m base, 1800m peak (3.6x variance) - Memory spikes during batch inference Recommended: - CPU request: 500 × 2.0 = 1000m (handle variance) - CPU limit: 1800 × 1.2 = 2160m (allow bursts) - Memory request: 2048 × 1.3 = 2662Mi - Memory limit: 3584 × 1.2 = 4301Mi For ML workloads, slightly over-provision to avoid latency spikes. Cost comparison: - Current: 2 × ($60 + $20) = $160/mo - Optimized: 2 × ($30 + $13) = $86/mo - Savings: $74/mo while maintaining performance headroom
Result:CPU: 1000m/2160m | Memory: 2662Mi/4301Mi | Savings: $74/month
Example 3: Database - Memory-Critical
Problem:PostgreSQL pod. 1 replica. Current: 500m CPU, 8Gi memory. Usage: 100m avg / 300m peak CPU, 6Gi avg / 7.2Gi peak memory.
Solution:Analysis (1.4x buffer for database): - CPU is over-provisioned (100m vs 500m) - Memory is appropriately sized (high utilization is expected) Recommended: - CPU request: 100 × 1.4 = 140m - CPU limit: 300 × 1.2 = 360m - Memory request: 6144 × 1.1 = 6758Mi (databases benefit from stable memory) - Memory limit: 7372 × 1.2 = 8847Mi CAUTION: For databases, memory OOM is catastrophic. Keep memory limit generous. Memory savings are less important than stability. Cost: - Current: $15 + $40 = $55/mo - Optimized: $4.20 + $33 = $37.20/mo - Savings: $17.80/mo (primarily from CPU)
Result:CPU: 140m/360m | Memory: 6758Mi/8847Mi | Savings: $17.80/month (conservative)
Frequently Asked Questions
What's the difference between requests and limits in Kubernetes?
Requests are guaranteed resources the container needs to run—used by the scheduler to place pods on nodes. Limits are maximum resources a container can use—exceeding CPU causes throttling; exceeding memory causes OOMKill. Set requests based on typical usage; set limits based on peak usage plus buffer.
How do I determine the right CPU request?
Analyze actual CPU usage over 1-2 weeks using metrics (Prometheus, Datadog). Set request to: (average usage × 1.2-1.5 buffer). The buffer accounts for variance and prevents throttling during normal operation. For bursty workloads, use higher buffers (1.5-2x).
How do I determine the right memory request and limit?
Memory is less elastic than CPU—exceeding limit causes OOMKill. Set request to (average usage × 1.3-1.5). Set limit to (peak usage × 1.2) minimum. For memory, it's better to over-provision slightly than risk OOMKill. Monitor OOMKilled events in your cluster.
What happens if requests are set too high?
Over-provisioned requests waste cluster resources. The scheduler reserves requested resources even if unused. You'll need more nodes than necessary, increasing costs. Other pods may be unable to schedule due to 'insufficient resources' even when actual utilization is low.
Should limits equal requests?
For memory: limits should be ≥ requests, often 1.5-2x requests to handle spikes without OOMKill. For CPU: limits can be higher than requests (burstable) or equal (guaranteed QoS). Equal requests/limits provide predictable performance but reduce flexibility.
How do I right-size for variable workloads?
For variable workloads: (1) Use VPA (Vertical Pod Autoscaler) for automatic recommendations, (2) Set requests to handle baseline load, (3) Set limits to handle peak, (4) Combine with HPA for horizontal scaling during sustained high load. Analyze weekly patterns, not just daily.
What is QoS class and how does it affect right-sizing?
Kubernetes assigns QoS classes: Guaranteed (requests=limits), Burstable (requests<limits), BestEffort (no requests/limits). Guaranteed pods are last to be evicted under pressure. For critical workloads, use Guaranteed QoS. For batch jobs, BestEffort may be acceptable.
How do cloud costs relate to Kubernetes resource settings?
Cloud providers charge for provisioned node capacity, not pod requests. However, requests determine how many pods fit per node. Over-provisioned requests mean fewer pods per node, requiring more nodes. Right-sizing requests directly reduces node count and costs.