ResourceQuota vs LimitRange

Both bound resources. Different scopes.

ResourceQuota

ResourceQuota is the namespace-level cap. It aggregates CPU, memory, pod count, and PVC count across every pod in the namespace, and refuses admission when the sum would exceed the cap. Its job is to protect cluster capacity from any single namespace running away.

• Total namespace cap. Aggregate limits on CPU, memory, pod count, PVC count, and other resources. Sum is enforced across every pod in the namespace.
• Hard admission boundary. A pod that would push the namespace over its quota fails to admit; this drives multi-tenant fairness.
• Use cases. Per-tenant capacity allocation in multi-tenant clusters; per-environment caps for dev, staging, and prod fairness.
• Named owner per quota. Document which team owns the cap and the change process; "everyone and no one" decisions are how clusters fill up.

LimitRange

LimitRange is the per-pod constraint. It sets defaults and maximum bounds for individual pods or containers, and acts as a safety net when pod specs forget to declare requests and limits. Its job is per-pod sanity, not aggregate capacity.

• Per-pod or per-container bounds. Default and maximum values for CPU, memory, and ephemeral storage applied at admission.
• Default values when spec is incomplete. Pods that omit requests or limits get the namespace's defaults rather than running unconstrained.
• Use cases. The no-oversized-pod rule; reasonable-default enforcement for teams that have not learned to declare resources.
• Documented bounds per namespace. Make the LimitRange config part of the IaC review so the rules are visible alongside the deployments.

Layer them

The two together provide layered protection: LimitRange enforces per-pod sanity, ResourceQuota enforces namespace-level fairness. Either one alone leaves an exploitable gap.

• LimitRange first. Per-pod defaults and maxima keep individual pods from being absurd.
• ResourceQuota second. Aggregate cap keeps the namespace as a whole within its allocation.
• Together as layered protection. Pods stay reasonable, the namespace stays bounded; either layer alone is bypassable.
• Documented combination per namespace. Operators need both rules visible to debug quota errors and admission failures.

Operating discipline

Both objects need to live in IaC and get reviewed quarterly. Setting them at namespace creation is cheap; retrofitting them after a runaway workload is expensive.

• ResourceQuota at namespace creation. IaC-managed quota set on day one; never bolted on after the first incident.
• Standard LimitRange template. One template applied to every namespace; per-team variants only with documented rationale.
• Quarterly review. Audit quotas versus actual usage; right-size, remove unused, expand for growing teams. Drift is gradual.
• At-cap alarm per namespace. Alert when usage approaches the cap so teams can request expansion before admission failures page on-call.