Kubernetes ResourceQuota Management

Kubernetes ResourceQuota Management is the detailed operational practice of configuring, scoping, and monitoring ResourceQuota objects themselves — beyond the basic concept of namespace-level bounding, this covers the specific quota dimensions available, how quotas can be scoped to subsets of Pods within a namespace using scopeSelector, how quota status is tracked and consumed, and the practical workflow of managing quota exhaustion and adjustment over a namespace's operational lifetime.

A ResourceQuota is not a single monolithic limit but a structured object supporting many distinct countable dimensions simultaneously, and effective quota management requires understanding which dimensions matter for a given namespace's actual usage pattern.

Quota Dimensions

Compute Resource Quotas

requests.cpu, requests.memory, limits.cpu, limits.memory, and extended resource equivalents (requests.nvidia.com/gpu) bound aggregate compute consumption across every Pod in the namespace.

spec:
  hard:
    requests.cpu: "20"
    requests.memory: "40Gi"
    limits.cpu: "40"
    limits.memory: "80Gi"

Object Count Quotas

Beyond compute resources, a ResourceQuota can bound the total number of objects of a given type — pods, services, persistentvolumeclaims, secrets, configmaps — preventing a namespace from accumulating an excessive number of objects even if their individual resource footprint is small.

spec:
  hard:
    pods: "50"
    services: "10"
    persistentvolumeclaims: "20"

Storage Quotas

requests.storage bounds the total amount of storage requested across all PersistentVolumeClaims in the namespace, and this can be further broken down per storage class (<storage-class-name>.storageclass.storage.k8s.io/requests.storage) for namespaces using multiple storage tiers.

spec:
  hard:
    requests.storage: "500Gi"
    codartium-ssd.storageclass.storage.k8s.io/requests.storage: "200Gi"

Scoping Quotas with scopeSelector

Applying Different Quotas to Different Pod Priorities

scopeSelector allows a ResourceQuota to apply only to Pods matching specific criteria — most commonly, Pods of a particular PriorityClass — enabling different quota rules for, say, high-priority production workloads versus best-effort batch jobs sharing the same namespace.

apiVersion: v1
kind: ResourceQuota
metadata:
  name: codartium-high-priority-quota
spec:
  hard:
    pods: "10"
  scopeSelector:
    matchExpressions:
      - operator: In
        scopeName: PriorityClass
        values: ["codartium-critical"]

Terminating vs. NotTerminating Scopes

Quotas can also be scoped to Terminating (Pods with an activeDeadlineSeconds set, typically batch-style workloads) versus NotTerminating Pods, allowing separate governance for finite, time-bounded work versus long-running services within the same namespace.

Quota Status and Consumption Tracking

Reading Current Usage Against Hard Limits

kubectl describe resourcequota codartium-team-quota -n codartium-team

The output reports both hard (the configured ceiling) and used (current aggregate consumption) for every dimension, giving a direct view of how much headroom remains before any given quota dimension is exhausted.

Resource           Used   Hard
--------           ----   ----
requests.cpu       15     20
requests.memory    32Gi   40Gi
pods               38     50

Handling Quota Exhaustion

A Pod creation attempt that would exceed any single quota dimension is rejected at admission time with a specific error identifying which dimension was violated — resolving this requires either freeing existing consumption (deleting or scaling down other workloads in the namespace) or raising the quota itself, a decision typically requiring the same governance process that established the original quota.

kubectl create -f new-pod.yaml
# Error: exceeded quota: codartium-team-quota, requested: requests.memory=2Gi,
# used: requests.memory=39Gi, limited: requests.memory=40Gi

Operational Workflow

Establishing Initial Quotas from Baseline Usage

New namespaces typically receive an initial quota informed by projected or historical usage from a comparable existing workload, rather than an arbitrary starting value, avoiding both premature blocking of legitimate work and an effectively meaningless, overly generous ceiling.

Periodic Review and Adjustment

Because workload needs evolve, quota values benefit from periodic review against actual used consumption trends — a namespace consistently operating near its ceiling signals a legitimate need for adjustment, while one using only a small fraction of its quota signals an opportunity to reclaim unused headroom for allocation elsewhere.

kubectl get resourcequota -A -o custom-columns=NAMESPACE:.metadata.namespace,NAME:.metadata.name,USED_CPU:.status.used.requests\\.cpu,HARD_CPU:.status.hard.requests\\.cpu

Example

apiVersion: v1
kind: ResourceQuota
metadata:
  name: codartium-full-quota
  namespace: codartium-team
spec:
  hard:
    requests.cpu: "15"
    requests.memory: "30Gi"
    limits.cpu: "30"
    limits.memory: "60Gi"
    pods: "40"
    persistentvolumeclaims: "10"
    requests.storage: "200Gi"