DevOps Dictionary

Kubernetes ResourceQuota is a Kubernetes API object that sets usage limits for a namespace. It controls how much CPU, memory, storage, and how many Kubernetes objects a team, application, or environment can consume inside that namespace.

ResourceQuota helps platform and DevOps teams prevent one workload or team from consuming shared cluster capacity. For example, you can limit a development namespace to 20 CPU cores, 40Gi of memory, 500Gi of persistent volume claims, and 50 Pods.

What Kubernetes ResourceQuota does

A ResourceQuota defines hard limits at the namespace level. Kubernetes checks those limits when users or controllers create or update resources in that namespace.

You can use it to limit resources such as:

• CPU requests and limits, such as requests.cpu and limits.cpu
• Memory requests and limits, such as requests.memory and limits.memory
• Storage requests, such as total requested storage for PersistentVolumeClaims
• Object counts, such as the number of Pods, Services, Secrets, ConfigMaps, Jobs, or PersistentVolumeClaims
• Extended resources, such as GPUs, when configured in the cluster

How ResourceQuota works

A ResourceQuota is created inside a namespace. It uses the hard field to define the maximum allowed usage.

When someone creates a Pod, PVC, Service, or another tracked object, Kubernetes compares the new total usage against the quota. If the request would exceed the limit, the Kubernetes API server rejects it.

For CPU and memory quotas, Pods usually need resource requests or limits defined. If a namespace has a quota for CPU or memory and a Pod does not specify the required values, Kubernetes may reject the Pod. Teams often pair ResourceQuota with LimitRange to set default requests and limits automatically.

Example ResourceQuota

This example limits a namespace to 10 CPU cores, 20Gi of memory, 100 Pods, and 200Gi of requested storage:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-a-quota
  namespace: team-a
spec:
  hard:
    requests.cpu: "10"
    requests.memory: 20Gi
    limits.cpu: "20"
    limits.memory: 40Gi
    pods: "100"
    requests.storage: 200Gi
    persistentvolumeclaims: "20"

If workloads in team-a already request 10 CPU cores, Kubernetes rejects any new Pod that asks for more CPU until usage drops or the quota is increased.

Common use cases

• Multi-team clusters: Give each team a namespace with clear resource boundaries.
• Startup cost control: Prevent a test workload from scaling until it consumes most of the cluster.
• Development environments: Keep dev and staging namespaces smaller than production namespaces.
• Platform guardrails: Limit how many Services, Secrets, Jobs, or PVCs a namespace can create.
• Batch workloads: Keep CI jobs, data processing tasks, or Airflow workers from starving long-running services.

For example, if you run Apache Airflow on EKS, ResourceQuota can limit worker Pods and storage usage in the Airflow namespace. This is useful when workflows can create bursts of compute demand. See this guide to deploy Apache Airflow on AWS Elastic Kubernetes Service for related Kubernetes deployment context.

Key fields and related concepts

• metadata.namespace: The namespace where the quota applies.
• spec.hard: The maximum allowed usage for each resource type.
• status.used: The current amount consumed in the namespace.
• status.hard: The enforced limits after Kubernetes accepts the ResourceQuota.
• scopeSelector: Allows quota rules to apply only to matching resource scopes, such as Pods with a specific priority class.

ResourceQuota often appears in infrastructure-as-code workflows. If your team manages namespaces, Deployments, and policies with Terraform, you can define quotas alongside other cluster resources. This guide on how to deploy Kubernetes resources using Terraform shows the kind of workflow where quota definitions usually fit.

ResourceQuota vs LimitRange

ResourceQuota and LimitRange are related, but they solve different problems.

• ResourceQuota sets total namespace limits. Example: the namespace can use up to 40Gi of memory.
• LimitRange sets per-object defaults and boundaries. Example: each container gets a default memory request of 256Mi and cannot request more than 2Gi.

In practice, teams often use both. LimitRange gives workloads sane defaults, while ResourceQuota protects the namespace boundary.

Benefits

• Prevents noisy-neighbor issues: One namespace cannot consume all shared cluster resources.
• Improves cost discipline: Teams get clear limits for CPU, memory, and storage usage.
• Supports self-service platforms: Teams can deploy independently inside controlled namespaces.
• Reduces operational surprises: Object count quotas can prevent runaway Jobs, Secrets, or ConfigMaps.

Tradeoffs and limitations

• Quota does not guarantee capacity: A namespace may be allowed to request 20 CPU cores, but the cluster still needs enough available nodes.
• Bad limits can block deployments: If quotas are too low, normal rollouts may fail during surge updates.
• Requests matter: CPU and memory quotas depend on resource requests and limits, so missing values can cause rejected Pods.
• It is namespace-scoped: ResourceQuota does not apply directly across the whole cluster unless you define quotas per namespace.
• It does not replace monitoring: You still need metrics and alerts to understand real usage trends.

Before cluster upgrades, check quota usage and rollout behavior. A Deployment update may temporarily create extra Pods, and strict quotas can block the rollout. This matters during planned maintenance and version upgrades, especially in smaller startup clusters. See these practical tips for Kubernetes upgrades for startups for related planning steps.

Simple real-world example

Assume a startup runs one shared Kubernetes cluster with three namespaces:

• dev for engineers testing feature branches
• staging for release validation
• prod for customer-facing workloads

The platform team might set these quotas:

• dev: 10 CPU cores, 20Gi memory, 50 Pods
• staging: 20 CPU cores, 40Gi memory, 100 Pods
• prod: 80 CPU cores, 160Gi memory, 300 Pods

This setup gives development teams room to work while protecting production capacity. If a developer accidentally deploys a loop that creates Jobs continuously, the namespace quota stops the damage at a known limit.

How it fits with cloud resource provisioning

ResourceQuota controls Kubernetes namespace usage. It does not directly limit cloud resources such as AWS RDS databases, S3 buckets, or IAM roles. If you use Crossplane to provision cloud resources through Kubernetes APIs, quotas can still limit the Kubernetes objects created in a namespace, but cloud-side limits and cost controls need separate policies. For context, see this guide on how to deploy AWS resources using Crossplane on Kubernetes.

Best practices

• Set quotas per namespace, especially in shared clusters.
• Pair ResourceQuota with LimitRange so Pods get default CPU and memory requests.
• Start with realistic limits based on recent usage, then adjust after observing deployments.
• Leave enough headroom for rolling updates, HPA scaling, and incident response.
• Monitor status.used and alert when usage approaches important limits, such as 80% or 90%.
• Document who owns each namespace and how teams request quota changes.

In short, Kubernetes ResourceQuota gives platform teams a practical way to divide shared cluster capacity by namespace. It works best when combined with resource requests, LimitRange defaults, monitoring, and clear ownership.