In a shared cluster, one namespace can consume all the capacity unless it is bounded. A ResourceQuota caps the total resources and object counts a namespace may use, and a LimitRange supplies defaults and bounds per container, so pods cannot run without limits.
Before you start
You should be comfortable with resource requests and limits. This article covers quotas and limit ranges.
Step-by-step walkthrough
Step 1: Set a quota for the namespace total
A ResourceQuota limits aggregate CPU, memory, storage and object counts such as the number of pods or services. Once the quota is reached, new objects are rejected, which prevents one team from starving the cluster.
Step 2: Use a LimitRange to supply defaults
Without limits, a pod may request nothing and consume unbounded memory. A LimitRange sets default requests and limits for containers that omit them, so every pod has a baseline and the scheduler can plan. It can also enforce a maximum to reject oversized pods.
Step 3: Reconcile quota and scheduling
A quota on requests and limits means every pod must declare both, and the scheduler uses requests for placement. Set the default request below the default limit, and make sure the quota is large enough for expected replica counts, or deployments stall on admission.
Worked scenario
The quota caps CPU and pods, and the LimitRange sets defaults.
apiVersion: v1
kind: ResourceQuota
metadata:
name: team-quota
namespace: team-a
spec:
hard:
requests.cpu: "20"
requests.memory: 40Gi
pods: "50"
---
apiVersion: v1
kind: LimitRange
metadata:
name: defaults
namespace: team-a
spec:
limits:
- default: { cpu: 500m, memory: 512Mi }
defaultRequest: { cpu: 100m, memory: 128Mi }Walk through the example
team-a may request at most twenty CPUs, forty gigabytes and fifty pods in total. Pods that omit resources receive the defaults from the LimitRange, so they are schedulable and bounded. A deployment that would exceed the quota is rejected at admission, which surfaces the limit early.
Common mistake
Setting a quota without defaults, so pods with no requests fail admission or run unbounded. Another is a quota too small for normal replica counts, which blocks deploys during a rollout.
Verify the behavior
Create pods that omit resources and confirm the LimitRange fills them in. Push the namespace past its quota and confirm new objects are rejected. Check a Deployment rollout succeeds within the quota.
Interview exercise
Why pair a LimitRange with a ResourceQuota?
Answer and reasoning
The quota caps the namespace total, but it needs every pod to declare resources to account correctly; a LimitRange supplies those declarations when a pod omits them and rejects oversized pods. Together they bound both the aggregate and each container, so one unbounded pod cannot consume a namespace’s whole budget.
Continue learning
Compare limits in Resource requests and isolation in Namespace boundaries. Read the Kubernetes resource quotas documentation and try the Kubernetes interview questions.