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.
Maintained by CloudCostKit Editorial Team. Last updated: 2026-02-23. Editorial policy and methodology.
Best next steps
Use this calculator for the first estimate, then validate the answer with the closest guide or companion tool.
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.
Requests decide scheduling, limits decide risk
This page is fundamentally about scheduler truth. Requests decide where workloads can be placed. Limits define burst boundaries and failure behavior. If those two ideas are blurred together, the cluster can look efficient on paper and still be unstable or over-provisioned in production.
- Requests: the scheduler's reservation signal and the main sizing input.
- Limits: the ceiling that shapes burst behavior, throttling, and OOM risk.
- Other constraint: pod caps can beat CPU and memory as the real scaling boundary.
Where requests and limits models usually fail
- A calm average request is used without a separate burst or deployment scenario.
- Limits are set so high that they stop being useful operational guidance.
- CPU and memory are not tested independently, so the wrong bottleneck gets blamed.
- Pod-cap and allocatable constraints are ignored because the resource math looked fine.
What to validate before handing sizing to a cost page
- Use representative workload history, not a single quiet week or a single incident peak.
- Review CPU and memory as separate scheduling boundaries and keep the higher resulting node pressure visible.
- Leave headroom for rollouts, burst traffic, and noisy-neighbor protection instead of sizing to the edge.
- Only after requests and limits are believable should you move on to node or cluster pricing.
Baseline vs burst-sensitive scheduling scenarios
| Scenario | Pods | Requests | Pod cap |
|---|---|---|---|
| Baseline | Expected | Typical | 110 |
| Peak | High | Same | 110 |
How to review requests and limits in production
- Check whether CPU, memory, or pod count is the actual reason the cluster needed more nodes under load.
- If production scheduling differs from plan, identify whether the miss came from requests, limits, or hidden pod-cap constraints.
Next steps
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.
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. Reviewed against CloudCostKit methodology and current provider documentation. See the Editorial Policy .