Pod CPU Request Calculator
Determine the right CPU request value for a pod based on average utilization.
About Pod CPU Request Calculator
The Kubernetes scheduler places pods based on their CPU request, not their limit or actual usage. Setting the request equal to raw average usage leaves no room for normal fluctuation and risks CPU throttling under the node's CFS quota. Multiplying the measured average by a safety factor of 1.2–1.5× gives the scheduler an honest reservation that reflects real-world variance without permanently over-provisioning the way a peak-based request would.
Formula
request = avgUsage × safetyFactor
- \bar{U}
- Measured average CPU usage in millicores
- S
- Safety factor multiplier (typically 1.2–1.5×)
- R
- Recommended CPU request in millicores
Worked example
With the default values below, Pod CPU Request Calculator returns Recommended CPU Request of 260. Change any input above and every figure here is recalculated in your browser.
Inputs used
- Measured Average CPU Usageaccepts 1–64,000 millicores
- 200 millicores
- Safety Factoraccepts 1–5 ×
- 1.3 ×
- Replicasaccepts 1–10,000 pods
- 3 pods
Results
- Recommended CPU Request
- 260 millicores
- Recommended CPU Request
- 0.260 cores
- Headroom Above Average
- 60 millicores
- Total Request Across Replicas
- 0.78 cores
Step by step
- 1CPU request = avg usage × safety factor= 260m
- 2Headroom above measured average= 60m
- 3Total request across replicas= 780m (0.78 cores)
Assumptions and limits
- The result is derived only from the 3 inputs listed above. Anything not among them is not part of the calculation.
- In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
- Figures are rounded for display to 3 decimal places, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.
How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.
Frequently Asked Questions
Why not just request the peak usage instead of the average?
Requests affect bin-packing and cost — every millicore requested is reserved on a node whether used or not. Peak-based requests waste capacity; average-based requests with a modest safety factor balance efficiency with resilience to normal variance.
What safety factor should I use?
1.2–1.5× is a reasonable default for steady workloads. Bursty or latency-sensitive services may warrant 1.5–2×, while highly predictable batch workloads can use closer to 1.1×.
How do I measure average CPU usage accurately?
Use a metrics window that spans multiple business cycles (at least 7 days including peak traffic days) from Prometheus/metrics-server, and average per-pod usage rather than node-level usage.