Kubernetes Compute ResourceQuota Management

Kubernetes Compute ResourceQuota Management is the focused practice of bounding CPU and memory consumption specifically — requests.cpu, requests.memory, limits.cpu, limits.memory, and their extended-resource equivalents — as distinct from the broader ResourceQuota object's other dimensions like object counts and storage. Compute quotas are the dimension most directly tied to a cluster's physical node capacity, and they are also the dimension with the most significant secondary consequence: once any compute-resource quota exists in a namespace, every Pod created there is required to declare explicit requests for that resource, or be rejected outright at admission.

This mandatory-declaration side effect is what most distinguishes compute quota management from object-count or storage quota management, where no equivalent per-Pod declaration requirement is triggered.

The Aggregate Sum Constraint

The Governing Inequality

For any compute resource dimension under quota, the sum of that resource's requests (or limits, for the corresponding limits.* dimension) across every Pod in the namespace must not exceed the configured hard value.

Every Pod creation, deletion, or resource-affecting update in the namespace re-evaluates this running sum, with admission rejected immediately if a new or modified Pod would push the total past the hard ceiling.

apiVersion: v1
kind: ResourceQuota
metadata:
  name: codartium-compute-quota
spec:
  hard:
    requests.cpu: "20"
    requests.memory: "40Gi"
    limits.cpu: "40"
    limits.memory: "80Gi"

The Mandatory Request Consequence

Why Quota Forces Explicit Declaration

Because a quota system needs a concrete number to subtract from its running total for every Pod, a namespace with any compute ResourceQuota in effect requires every container to specify an explicit requests.cpu and/or requests.memory value corresponding to whichever quota dimensions are active — a Pod omitting them is rejected with an explicit error citing the missing declaration, not silently treated as zero consumption.

kubectl create -f pod-without-requests.yaml
# Error: failed quota: codartium-compute-quota: must specify requests.cpu,requests.memory

Pairing with LimitRange to Avoid Friction

Because this requirement can surprise teams unaccustomed to declaring resources explicitly, pairing a compute ResourceQuota with a LimitRange supplying defaultRequest values in the same namespace avoids outright rejection for Pods that omit requests, instead having them silently receive the namespace's default values.

apiVersion: v1
kind: LimitRange
metadata:
  name: codartium-defaults
spec:
  limits:
    - defaultRequest:
        cpu: "100m"
        memory: "128Mi"
      type: Container

Requests vs. Limits Quota Separately

Two Independent Ceilings

requests.cpu/requests.memory and limits.cpu/limits.memory are tracked as entirely separate quota dimensions — a namespace can, in principle, have a tight requests quota (controlling guaranteed baseline reservation) alongside a much looser limits quota (allowing generous burst headroom across the namespace's Pods), or vice versa, depending on the governance intent.

Interaction with QoS Classes

Because Guaranteed QoS Pods have requests equal to limits, they consume identically against both the requests and limits quota dimensions simultaneously — a namespace populated mostly with Guaranteed Pods will see its requests and limits quotas track each other closely, while a namespace with many Burstable Pods (requests well below limits) will show more headroom remaining on the requests dimension than the limits dimension.

Sizing Compute Quotas

Grounding in Node Capacity Allocation

Compute quotas are most meaningfully set as a deliberate fraction of overall cluster (or node pool) capacity allocated to a given team or application, reflecting an explicit capacity-planning decision rather than an arbitrary number — a quota disconnected from actual cluster capacity either constrains legitimate work unnecessarily or provides no real governance value.

Monitoring Consumption Trends Over Time

kubectl get resourcequota codartium-compute-quota -o jsonpath='{.status.used.requests\.cpu}/{.status.hard.requests\.cpu}'

Tracking this ratio over time (rather than only checking it reactively when a Pod creation is rejected) allows proactive capacity conversations before a namespace's quota becomes a genuine blocker to legitimate scaling needs.

Example

apiVersion: v1
kind: ResourceQuota
metadata:
  name: codartium-compute-quota
  namespace: codartium-team
spec:
  hard:
    requests.cpu: "10"
    requests.memory: "20Gi"
    limits.cpu: "20"
    limits.memory: "40Gi"
    requests.nvidia.com/gpu: "2"