LimitRange Calculator
Determine default and boundary values for a Kubernetes LimitRange policy.
About LimitRange Calculator
A LimitRange object sets default CPU/memory requests and limits that the API server injects into any pod in the namespace that omits its own — this ensures ResourceQuota can be enforced (quota requires every pod to have a request) even for teams that don't explicitly set resources. This calculator projects how much aggregate capacity those namespace-wide defaults consume once applied across every unspecified pod.
Formula
totalDefaultedCPU = defaultRequestCPU × podsWithoutSpec
- D_c
- LimitRange default CPU request in millicores
- P
- Number of pods inheriting the default
- T
- Total defaulted CPU request in millicores
Worked example
With the default values below, LimitRange Calculator returns Total Defaulted CPU Request of 2,500. Change any input above and every figure here is recalculated in your browser.
Inputs used
- LimitRange Default CPU Requestaccepts 0–64,000 millicores
- 100 millicores
- LimitRange Default CPU Limitaccepts 0–64,000 millicores
- 500 millicores
- LimitRange Default Memory Requestaccepts 0–1,000,000 MiB
- 128 MiB
- LimitRange Default Memory Limitaccepts 0–1,000,000 MiB
- 512 MiB
- Pods Without Explicit Resourcesaccepts 0–1,000,000 pods
- 25 pods
Results
- Total Defaulted CPU Request
- 2,500 millicores
- Total Defaulted Memory Request
- 3,200 MiB
- Implied CPU Burst Ratio
- 5.00 ×
- Implied Memory Burst Ratio
- 4.00 ×
Step by step
- 1Total defaulted CPU request= 2500m
- 2Total defaulted memory request= 3200MiB
Assumptions and limits
- The result is derived only from the 5 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
Why do pods need resources set if ResourceQuota is enabled?
If a namespace has a ResourceQuota on compute resources, the API server rejects any pod without an explicit request/limit — unless a LimitRange is also configured to inject sane defaults automatically, which is exactly what LimitRange is for.
Can LimitRange also enforce min/max bounds instead of just defaults?
Yes — beyond default request/limit values, LimitRange can set min and max bounds per container, rejecting any pod that requests below the min or above the max, which is useful for preventing egregiously oversized or undersized requests.
What happens if defaults are set too low across many pods?
Pods silently inherit an under-sized request, which can cause CPU throttling or OOMKills in production without an obvious signal at deploy time — audit LimitRange defaults against your typical workload profile, not just a generic placeholder value.
