Pod Resource Calculator
Calculate optimal CPU and memory requests/limits for a Kubernetes pod.
About Pod Resource Calculator
Kubernetes schedules pods based on their resource requests, and enforces limits at runtime to prevent a single pod from starving its node. This calculator scales a single pod's CPU and memory request up to the full replica count to show total cluster capacity needed, and applies a limit-to-request ratio to compute the corresponding limits. A ratio of 1 means requests equal limits (Guaranteed QoS); higher ratios allow bursting but increase overcommit risk.
Formulas
Per-pod limit
limit = request × ratio
- R
- Per-pod resource request (CPU or memory)
- \rho
- Limit-to-request ratio
- L
- Per-pod resource limit
Total cluster request
totalRequest = request × replicas
- R
- Per-pod resource request
- N
- Number of replicas
- T
- Total cluster resource request
Worked example
With the default values below, Pod Resource Calculator returns Total Cluster CPU Request of 0.75. Change any input above and every figure here is recalculated in your browser.
Inputs used
- CPU Requestaccepts 1–64,000 millicores
- 250 millicores
- Memory Requestaccepts 1–1,000,000 MiB
- 256 MiB
- Replicasaccepts 1–10,000 pods
- 3 pods
- Limit-to-Request Ratioaccepts 1–10 ×
- 2 ×
Results
- Total Cluster CPU Request
- 0.75 cores
- Total Cluster Memory Request
- 0.75 GiB
- Per-Pod CPU Limit
- 500 millicores
- Per-Pod Memory Limit
- 512 MiB
- Total Cluster CPU Limit
- 1.50 cores
- Total Cluster Memory Limit
- 1.50 GiB
Step by step
- 1CPU limit: request × ratio= 500m
- 2Memory limit: request × ratio= 512MiB
- 3Total CPU request across replicas= 750m (0.75 cores)
- 4Total memory request across replicas= 768MiB (0.75 GiB)
Assumptions and limits
- The result is derived only from the 4 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 2 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
What's the difference between requests and limits?
Requests are what the scheduler reserves for a pod when placing it on a node. Limits are the hard ceiling the kernel enforces — CPU is throttled and memory beyond the limit triggers an OOMKill.
What ratio should I use between requests and limits?
A ratio of 1 (Guaranteed QoS) is safest for predictable latency-sensitive workloads. Ratios of 1.5–3 are common for bursty workloads where you want headroom without over-reserving cluster capacity.
How does replica count affect cluster capacity planning?
Total cluster resources needed scale linearly with replica count. This is what you should compare against your node pool's allocatable capacity when planning autoscaling.
Should I set memory limits equal to requests?
Often yes — unlike CPU, memory can't be reclaimed gracefully, so many teams set memory limits equal to requests to avoid unpredictable OOMKills while still allowing CPU to burst.