LimitRange Calculator
Determine default and boundary values for a Kubernetes LimitRange policy.
Inputs
Pods in the namespace that omit resources and inherit the LimitRange defaults.
Total Defaulted CPU Request
2,500millicores
Total Defaulted Memory Request
3,200MiB
Implied CPU Burst Ratio
5.00×
Implied Memory Burst Ratio
4.00×
Step by step
Total defaulted CPU request
100m × 25
= 2500m
Total defaulted memory request
128MiB × 25
= 3200MiB
How it works
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
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.