Question
Ensuring ResourceQuota Compatibility with LimitRange Defaults in Kubernetes Development Namespaces
Rahul Dey
0 reputation · 22 Mar 2024, 06:01 UTC
12.3K views1
Loading…
0 reputation · 22 Mar 2024, 06:01 UTC
In a Kubernetes development namespace, ResourceQuota defines the maximum aggregate CPU, memory, and storage that pods may consume, while LimitRange supplies default request and limit values for containers that omit explicit resource specifications.
However, when a pod’s inferred minimum request from LimitRange exceeds the namespace’s ResourceQuota allocation, the pod is rejected with a 403 error, creating an inconsistent development experience; it remains unclear whether the API server evaluates the effective request before applying the quota and how administrators can reconcile these mechanisms for repeatable environments.
What is the precedence order between LimitRange‑derived minimum requests and ResourceQuota limits? Can ResourceQuota be configured to consider the effective request derived from LimitRange? How should development teams ensure pods respect both constraints without unnecessary rejections?
35275 reputation · 22 Mar 2024, 16:58 UTC
Confirmed Kubernetes behavior: the LimitRanger admission plugin mutates incoming pods first, injecting default requests and limits for containers that omit them. The Quota admission plugin then runs against the resulting spec. ResourceQuota does not inspect the original, empty resource fields; it validates the effective, post-default values. If a LimitRange-derived minimum request exceeds the remaining namespace quota, the API server rejects the pod with a 403 Forbidden quota-exceeded error.
No. There is no ResourceQuota option to exclude LimitRange-injected values from accounting. Quota enforcement always validates the final admitted container spec. A LimitRange default that is too large relative to the quota will therefore always cause rejections for pods that omit explicit resources.
kuberneteskubectl describe limitrange and kubectl describe resourcequota to compare default requests against hard limits.requests.cpu, requests.memory, limits.cpu, and limits.memory above the sum of LimitRange defaults multiplied by the expected concurrent pod count.kubectl get events -n <namespace> for FailedCreate or quota admission messages.Use kubectl create --dry-run=server -f pod.yaml to surface admission rejection before applying a manifest. After admission, kubectl get pod -o yaml confirms whether LimitRange defaults were injected into the container spec.
Use comments to ask for clarification. Post a solution as an answer.
6,640 reputation · 22 Mar 2024, 15:41 UTC
Assuming both LimitRanger and ResourceQuota admission plugins are enabled in their standard order, LimitRange defaults are applied per container before quota evaluation. A multi-container pod that omits resource specifications can therefore consume multiple default request allocations against a single namespace quota, which often explains unexpected 403 rejections. ResourceQuota has no mode to skip defaulted values; it always checks the admitted object after mutation. To reconcile this, inspect the admitted spec with kubectl get pod POD_NAME -o yaml rather than the submitted manifest, and size quota as expected pod count times container count times the LimitRange default request. If that ceiling is too tight, either reduce the LimitRange defaults or enforce explicit container resources through admission policy.