In this lesson, you will learn how to implement ResourceQuotas to enforce hard limits on the total compute resources and object counts consumed by a specific namespace in a shared cluster.
Why Resource Quotas?
While LimitRanges (which we covered previously) set constraints on individual Pods or containers, they cannot stop a single user from deploying 10,000 tiny Pods that overwhelm the cluster's control plane. ResourceQuotas solve this by providing a "cluster-level budget" for a namespace. They act as a governance tool, ensuring that "Team A" cannot inadvertently exhaust the entire cluster’s CPU or memory, thereby starving other teams.
Implementing a Quota
A ResourceQuota defines a total limit for a namespace. When you apply this object, Kubernetes will track the aggregate usage of all objects in that namespace and reject any request that would cause the total usage to exceed the defined limit.
For example, the following configuration prevents the production namespace from using more than 20 CPUs, 100Gi of RAM, or deploying more than 10 StatefulSets:
apiVersion: v1
kind: ResourceQuota
metadata:
name: team-quota
namespace: production
spec:
hard:
requests.cpu: "20"
requests.memory: 100Gi
limits.cpu: "40"
limits.memory: 200Gi
count/statefulsets.apps: "10"
How It Works
Once this ResourceQuota is active:
- Admission Control: When a user tries to create a new Pod or
StatefulSet, the Kubernetes API server checks the total requested resources against the quota. - Rejection: If the new object causes the total to exceed the
hardlimit, the API server will return an error, preventing the object from being created. - Visibility: You can check the current usage against your limits by running
kubectl describe resourcequota team-quota -n production.
This mechanism is essential for maintaining fairness in multi-tenant environments where you need to guarantee that no single team consumes a disproportionate share of the shared infrastructure.
Key Takeaway: ResourceQuotas provide a top-down aggregate ceiling on namespace consumption, effectively preventing individual teams from starving the cluster of compute resources or exceeding object counts.