Determine default and boundary values for a Kubernetes LimitRange policy.
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.
totalDefaultedCPU = defaultRequestCPU × podsWithoutSpec
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.
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.
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.