Kubernetes Requests & Limits Calculator
Requests drive scheduling. This tool converts per-pod requests into cluster totals and estimates how many nodes you need given allocatable overhead and max pods per node. Use baseline vs peak to stress-test the sizing.
Inputs
Pods
CPU request (mCPU / pod)
~0.25 cores per pod.
Memory request (MiB / pod)
~0.5 GiB per pod.
CPU limit (mCPU / pod)
Memory limit (MiB / pod)
Node CPU (cores)
Node memory (GiB)
Allocatable (%)
Reserve capacity for kubelet/daemonsets/overhead.
~7.2 cores, 28.8 GiB allocatable.
Max pods per node
Set to 0 to ignore pod limits.
Peak pods multiplier (%)
Model a peak month (traffic spikes, reprocessing, incidents).
Scenario presets
Results
Total CPU requests
15 cores
Total memory requests
30 GiB
Nodes needed (requests)
3
Bottleneck
CPU requests
Allocatable per node
7.2 cores / 28.8 GiB (90%)
Max pods per node
110
Baseline vs peak
| Scenario | Pods | Nodes | CPU req (cores) | Mem req (GiB) |
|---|---|---|---|---|
| Baseline | 60 | 3 | 15 | 30 |
| Peak | 75 | 3 | 18.75 | 37.5 |
| Delta | 15 | 0 | 3.75 | 7.5 |
Limits (burst risk)
| Metric | Total |
|---|---|
| CPU limits | 30 cores |
| Memory limits | 60 GiB |
Use the peak multiplier to model traffic spikes, and set max pods per node to capture CNI pod caps.
How to get your inputs
- Inputs: use billing exports, metrics, or logs to get real counts/GB where possible.
- Units: convert throughput (Mbps) or rates (RPS) into monthly units when needed.
- Scenarios: build a baseline and a high-usage scenario to avoid under-budgeting.
Result interpretation
- Requests drive scheduling; limits represent burst risk and OOM risk.
- Pod caps can exceed CPU/memory as the limiting factor.
Common mistakes
- Using a single average and ignoring peak/incident scenarios.
- Double-counting or missing adjacent line items (transfer, logs, retries).
Scenario planning
| Scenario | Pods | Requests | Pod cap |
|---|---|---|---|
| Baseline | Expected | Typical | 110 |
| Peak | High | Same | 110 |
Validate after changes
- Compare your estimate to the first real bill and adjust assumptions.
- Track the primary driver metric (requests/GB/count) over time.
Next steps
Advertisement
Example scenario
- 60 pods with 250m CPU and 512Mi requests -> estimate total requests and node count for an 8 vCPU / 32 GiB node.
- 120 pods with a 110 pods/node cap -> see how pod limits increase node count.
Included
- Totals for CPU/memory requests and limits from per-pod values and pod count.
- Node count estimate based on allocatable percentage and max pods per node.
- Baseline vs peak comparison and bottleneck label.
Not included
- Bin packing constraints (affinities, taints, topology spread) and daemonset overhead.
- Network, storage, and control plane costs.
How we calculate
- Total requests = pods x per-pod request (CPU and memory).
- Allocatable per node = node capacity x allocatable percentage.
- Node estimate uses the largest of CPU, memory, and pod-limit counts.
- Compare baseline vs peak to understand scaling risk.
FAQ
Why not size based on limits?
Scheduling uses requests, not limits. Limits matter for bursting risk and potential throttling/OOM behavior.
What should I use for allocatable %?
A common planning value is 85-95% depending on kubelet/system reservations, daemonsets, and headroom.
What is max pods per node?
Kubernetes enforces a pod cap per node (often 110). Even if CPU/memory fits, pod limits can require more nodes.
Does this include per-node overhead like daemonsets?
Not explicitly. Use a lower allocatable % or increase requests to account for overhead.
What about cluster autoscaler and bin packing?
This tool is a quick estimate. Real scheduling constraints (affinities, daemonsets, topology spread) can increase node count. Treat the result as a floor and validate with real packing.
How do I turn this into a cost estimate?
Use the resulting node count with the Kubernetes Node Cost Calculator, and add control plane, load balancers, storage, and observability costs separately.
Related tools
Related guides
Kubernetes requests & limits: practical sizing (and cost impact)
How to size clusters from requests, choose allocatable headroom, and use limits to reason about burst risk - with a calculator, a worked template, and common pitfalls.
Kubernetes requests vs limits: why requests drive node count (and cost)
A practical explanation of Kubernetes requests vs limits for capacity planning and cost estimation, with common mistakes, a worked sizing workflow, and links to calculators.
EKS node sizing: requests, overhead, and why packing is never perfect
A practical EKS node sizing guide: size from requests, reserve headroom, account for DaemonSets and max-pods limits, and understand why real scheduling often needs more nodes than the math minimum.
Google Kubernetes Engine (GKE) pricing: nodes, networking, storage, and observability
GKE cost is not just nodes: include node pools, autoscaling, requests/limits (bin packing), load balancing/egress, storage, and logs/metrics. Includes a worked estimate template, pitfalls, and validation steps to keep clusters right-sized.
CloudFront cache hit rate: how it changes origin egress cost
Cache hit rate strongly influences origin requests and origin egress (cache fill). Learn a simple model, what breaks hit rate, and the practical levers to improve it safely.
Estimate Secrets Manager API calls per month (GetSecretValue volume)
A practical workflow to estimate Secrets Manager API request volume (especially GetSecretValue): measure and scale when possible, model from runtime churn when not, and validate with CloudTrail so your budget survives peaks.
Advertisement
Disclaimer
Educational use only. Not legal, financial, or professional advice. Results are estimates based on the inputs and assumptions shown on this page. Verify pricing and limits with your providers and documentation.
Last updated: 2026-02-23