Orchestration

Master Kubernetes Quotas & LimitRanges: Best Practices

August 3, 2026 Kubezilla Team 15 min read

Introduction

Managing resources efficiently in a multi-tenant Kubernetes cluster is a perpetual challenge. Without proper guardrails, a single misbehaving application or an overzealous developer can consume disproportionate amounts of CPU, memory, or storage, leading to resource starvation for other critical workloads. This “noisy neighbor” problem not only degrades performance across the cluster but can also lead to unpredictable costs and operational headaches. How do you ensure fair resource allocation and prevent resource hogs from impacting the stability and performance of your entire infrastructure?

Enter Kubernetes Resource Quotas and LimitRanges. These powerful admission controllers are your first line of defense against resource contention and a cornerstone of effective cluster management. Resource Quotas restrict the aggregate resource consumption within a given namespace, acting as a hard budget. LimitRanges, on the other hand, enforce default resource requests and limits for pods and containers within a namespace, ensuring that no container runs without these crucial specifications. Together, they provide a robust mechanism for enforcing resource governance, improving cluster stability, and optimizing resource utilization. This guide will walk you through best practices for implementing and managing these essential Kubernetes features.

TL;DR: Kubernetes Resource Quotas & LimitRanges Best Practices

Kubernetes Resource Quotas and LimitRanges are crucial for managing resource consumption in multi-tenant clusters. Resource Quotas set aggregate limits per namespace, while LimitRanges enforce default requests/limits for individual Pods.

  • ResourceQuota: Define overall CPU, memory, storage, and object counts for a namespace.
  • LimitRange: Set default and maximum CPU/memory requests/limits for containers within a namespace.
  • Best Practice: Always use both. Quotas for namespace-level budgeting, LimitRanges for container-level enforcement.
  • Key Commands:

# Apply a ResourceQuota
kubectl apply -f my-resource-quota.yaml

# Apply a LimitRange
kubectl apply -f my-limit-range.yaml

# Describe a ResourceQuota to see usage
kubectl describe resourcequota my-quota -n my-namespace

# Describe a LimitRange
kubectl describe limitrange my-limit-range -n my-namespace

# Check resource usage for a namespace
kubectl top pod -n my-namespace --containers

These tools are essential for cost optimization and cluster stability. For further cost-saving strategies, check out Karpenter Cost Optimization.

Prerequisites

Before diving into Resource Quotas and LimitRanges, ensure you have the following:

  • A running Kubernetes cluster (any version 1.10+ is sufficient, but newer is always better). You can use Minikube, Kind, or a cloud-managed cluster like GKE, EKS, or AKS.
  • kubectl command-line tool configured to connect to your cluster. Refer to the official Kubernetes documentation for kubectl installation.
  • Basic understanding of Kubernetes concepts: Pods, Deployments, Namespaces, and resource requests/limits.
  • Administrative access to create and manage namespaces, Resource Quotas, and LimitRanges.

Step-by-Step Guide: Implementing Resource Quotas and LimitRanges

1. Understanding Resource Quotas

A ResourceQuota object provides constraints that limit aggregate resource consumption per namespace. This means you can define a “budget” for CPU, memory, storage, or even the number of Kubernetes objects (like pods, services, or deployments) that can exist within a specific namespace. When a new resource is created or an existing one is updated, Kubernetes checks if the total resource consumption for that namespace, including the new/updated resource, exceeds the defined quota. If it does, the operation is denied. This prevents a single namespace from hogging all available cluster resources, ensuring fairness and stability across different teams or applications.

Resource Quotas are applied at the namespace level and are critical for multi-tenant environments. They enforce a hard limit, preventing resource exhaustion and promoting responsible resource usage. For instance, you can limit a “development” namespace to a total of 10 CPU cores and 20GiB of memory, while a “production” namespace might have a higher quota. This helps in capacity planning and prevents unexpected resource spikes from impacting other workloads. For advanced networking controls that complement resource management, explore Kubernetes Network Policies.

Example ResourceQuota

Let’s create a namespace and then apply a ResourceQuota to it. This quota will limit the namespace to 2 CPU cores, 4GiB of memory, and a maximum of 5 pods.


apiVersion: v1
kind: Namespace
metadata:
  name: dev-team-a
---
apiVersion: v1
kind: ResourceQuota
metadata:
  name: dev-quota
  namespace: dev-team-a
spec:
  hard:
    requests.cpu: "2"
    requests.memory: "4Gi"
    limits.cpu: "4"
    limits.memory: "8Gi"
    pods: "5"
    persistentvolumeclaims: "2"
    requests.storage: "10Gi"


kubectl apply -f resourcequota.yaml

Verify ResourceQuota

After applying, you can describe the ResourceQuota to see its current state, including its limits and current usage.


kubectl describe resourcequota dev-quota -n dev-team-a

Expected Output:


Name:           dev-quota
Namespace:      dev-team-a
Resource        Used    Hard
--------        ----    ----
limits.cpu      0       4
limits.memory   0       8Gi
pods            0       5
persistentvolumeclaims  0       2
requests.cpu    0       2
requests.memory 0       4Gi
requests.storage        0       10Gi

The output shows that currently, no resources are used against the defined hard limits.

2. Understanding LimitRanges

While Resource Quotas set the aggregate limits for a namespace, LimitRanges provide constraints on individual Pods, Containers, and PersistentVolumeClaims within a namespace. They ensure that every container created in a given namespace has default resource requests and limits, and that these values fall within specified minimum and maximum bounds. This is crucial because if a container doesn’t specify requests and limits, it can potentially consume unbounded resources, leading to instability or even OOMKilled (Out Of Memory Killed) containers.

LimitRanges serve multiple purposes:

  1. Default Values: Automatically injects default CPU and memory requests/limits if a container doesn’t specify them. This prevents “naked” containers that could starve other workloads.
  2. Max/Min Limits: Enforces minimum and maximum CPU/memory values for containers. This prevents developers from requesting ridiculously small amounts (which could lead to thrashing) or excessively large amounts (which might exceed node capacity or cluster quotas).
  3. Ratio Enforcement: Can enforce a ratio between requests and limits, promoting quality of service (QoS) classes.

Together with Resource Quotas, LimitRanges ensure that every workload has a well-defined resource footprint, contributing to a more predictable and stable cluster environment. For optimizing resource usage and cost, especially with dynamic workloads, consider solutions like Karpenter for Kubernetes Cost Optimization.

Example LimitRange

Let’s create a LimitRange in our dev-team-a namespace. This LimitRange will:

  • Set default requests of 100m CPU and 256Mi memory.
  • Set default limits of 200m CPU and 512Mi memory.
  • Enforce a maximum limit of 500m CPU and 1Gi memory for any container.
  • Enforce a minimum request of 50m CPU and 128Mi memory for any container.

apiVersion: v1
kind: LimitRange
metadata:
  name: dev-limits
  namespace: dev-team-a
spec:
  limits:
  - default:
      cpu: "200m"
      memory: "512Mi"
    defaultRequest:
      cpu: "100m"
      memory: "256Mi"
    max:
      cpu: "500m"
      memory: "1Gi"
    min:
      cpu: "50m"
      memory: "128Mi"
    type: Container


kubectl apply -f limitrange.yaml

Verify LimitRange

Describe the LimitRange to confirm it’s applied correctly.


kubectl describe limitrange dev-limits -n dev-team-a

Expected Output:


Name:       dev-limits
Namespace:  dev-team-a
Type        Resource        Min     Max     Default Request Default Limit Max Limit/Request Ratio
----        --------        ---     ---     --------------- ------------- -----------------------
Container   cpu             50m     500m    100m            200m          -
Container   memory          128Mi   1Gi     256Mi           512Mi         -

3. Deploying a Pod and Observing Effects

Now, let’s deploy a simple Nginx Pod into the dev-team-a namespace. We will intentionally omit resource requests and limits from the Pod definition to see how the LimitRange injects them.

Example Pod (without requests/limits)


apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod-1
  namespace: dev-team-a
spec:
  containers:
  - name: nginx
    image: nginx:latest
    ports:
    - containerPort: 80


kubectl apply -f pod-no-limits.yaml

Verify Pod Resources

Check the description of the created Pod to see the injected requests and limits.


kubectl describe pod nginx-pod-1 -n dev-team-a | grep -A 5 "Limits:"

Expected Output:


    Limits:
      cpu:     200m
      memory:  512Mi
    Requests:
      cpu:     100m
      memory:  256Mi

As you can see, the LimitRange successfully injected the default CPU and memory requests and limits into our Nginx container, even though they weren’t explicitly defined in the Pod manifest. This is a powerful feature for enforcing best practices across all workloads in a namespace. For advanced observability of these resource usages, tools leveraging eBPF and Hubble can provide deep insights.

4. Testing Resource Quota Violations

Let’s try to deploy a Pod that would exceed our namespace’s ResourceQuota or a container that violates the LimitRange’s max limits. This demonstrates the admission controller at work.

Example 1: Pod Exceeding Namespace Pod Quota

Our dev-quota has a limit of 5 pods. Let’s try to create 6 pods (assuming you only have 1 running from the previous step).


apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment-quota-test
  namespace: dev-team-a
spec:
  replicas: 6 # This will exceed the 'pods: 5' quota
  selector:
    matchLabels:
      app: nginx-quota-test
  template:
    metadata:
      labels:
        app: nginx-quota-test
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        resources:
          requests:
            cpu: "50m"
            memory: "128Mi"
          limits:
            cpu: "100m"
            memory: "256Mi"


kubectl apply -f deployment-quota-violation.yaml

Expected Output (Error):


Error from server (Forbidden): error when creating "deployment-quota-violation.yaml": deployments.apps "nginx-deployment-quota-test" is forbidden: exceeded quota: dev-quota, requested: pods=6, used: pods=1, limited: pods=5

The deployment was rejected because it tried to create 6 pods, exceeding the quota of 5 pods for the dev-team-a namespace. This demonstrates the protective nature of Resource Quotas.

Example 2: Container Exceeding LimitRange Max CPU Limit

Our dev-limits LimitRange sets a max CPU limit of 500m (0.5 CPU core). Let’s try to deploy a Pod that requests 1 CPU core.


apiVersion: v1
kind: Pod
metadata:
  name: cpu-hog-pod
  namespace: dev-team-a
spec:
  containers:
  - name: high-cpu-app
    image: busybox
    command: ["sh", "-c", "echo 'Hello Kubezilla!'; sleep 3600"]
    resources:
      requests:
        cpu: "200m"
        memory: "256Mi"
      limits:
        cpu: "1" # This exceeds the 500m max limit
        memory: "512Mi"


kubectl apply -f pod-limitrange-violation.yaml

Expected Output (Error):


Error from server (Forbidden): error when creating "pod-limitrange-violation.yaml": pods "cpu-hog-pod" is forbidden: container "high-cpu-app" has a cpu limit of 1, which is greater than the maximum cpu limit of 500m in namespace dev-team-a

Again, the operation is forbidden, showing that LimitRanges effectively enforce per-container resource constraints. This is particularly important when dealing with specialized workloads like LLMs requiring specific GPU scheduling, where precise resource allocation is paramount.

Production Considerations

Implementing Resource Quotas and LimitRanges in production requires careful planning and continuous monitoring. Here are key considerations:

  1. Start with Reasonable Defaults: Don’t set quotas too restrictively initially. Start with generous but not unbounded limits and requests. Gradually tighten them based on actual usage patterns observed in your cluster.
  2. Monitor Resource Usage: Regularly monitor resource consumption per namespace and per application. Tools like Prometheus and Grafana, along with kubectl top, are invaluable. This helps you identify namespaces nearing their quotas and applications that are under- or over-provisioned. For deeper insights into network and resource usage, consider exploring eBPF Observability with Hubble.
  3. Communicate with Developers: Educate your development teams on the importance of defining resource requests and limits. Explain how Quotas and LimitRanges affect their deployments. Provide guidelines and best practices for setting these values.
  4. Namespace Strategy: Align your namespace strategy with your resource governance needs. Each team or application environment (dev, staging, prod) should ideally have its own namespace with appropriate quotas. This also aids in network isolation, which can be further enhanced with tools like Cilium WireGuard Encryption.
  5. Storage Quotas: Don’t forget PersistentVolumeClaim (PVC) quotas. Limiting storage requests and the number of PVCs prevents a single team from exhausting shared storage resources.
  6. Object Quotas: Beyond CPU/memory, consider limiting the number of specific objects (e.g., deployments, services, ingress) per namespace. This prevents accidental or malicious proliferation of resources that can impact the Kubernetes API server itself.
  7. QoS Classes: Understand how requests and limits influence Kubernetes Quality of Service (QoS) classes (Guaranteed, Burstable, BestEffort). Aim for Guaranteed or Burstable for critical applications to ensure predictable performance.
  8. Admission Controllers: Resource Quota and LimitRange are implemented as Kubernetes Admission Controllers. Ensure they are enabled in your cluster (they usually are by default).
  9. Automation: Integrate the creation of namespaces, Resource Quotas, and LimitRanges into your GitOps or infrastructure-as-code workflows. This ensures consistency and reproducibility.
  10. Review and Adjust: Resource requirements change over time. Regularly review your quotas and limits. Adjust them as applications evolve, new services are deployed, or cluster capacity changes.
  11. Service Mesh Integration: While not directly related to quotas, if you’re using a service mesh like Istio Ambient Mesh, ensure that its components (e.g., sidecars or ztunnels) also respect the defined resource limits and requests, or are excluded where appropriate.

Troubleshooting

Even with careful planning, issues can arise. Here are some common problems and their solutions:

  1. Issue: Pods are stuck in Pending state with a Forbidden error.

    Problem: This usually indicates a violation of either a ResourceQuota or a LimitRange.

    Solution:

    • Check the Pod’s events: 
      kubectl describe pod <pod-name> -n <namespace>

      Look for messages related to Forbidden, exceeded quota, or exceeds maximum.

    • Check the namespace’s ResourceQuota: 
      kubectl describe resourcequota <quota-name> -n <namespace>

      Compare Used vs. Hard values.

    • Check the namespace’s LimitRange: 
      kubectl describe limitrange <limitrange-name> -n <namespace>

      Ensure the Pod’s resource requests/limits fall within the defined min/max.

    • Adjust the Pod’s resource requests/limits, increase the ResourceQuota, or create more cluster capacity.
  2. Issue: Containers are getting OOMKilled (Out Of Memory Killed) frequently.

    Problem: The container is trying to use more memory than its assigned limit. This is a runtime issue, not an admission issue.

    Solution:

    • Increase the memory limits for the affected container in its Pod/Deployment definition.
    • Analyze application memory usage using monitoring tools (e.g., Prometheus, Grafana) to determine appropriate limits.
    • Ensure your LimitRange’s max memory limit is not too restrictive for the application’s actual needs.
  3. Issue: Pods are being throttled (experiencing CPU starvation).

    Problem: The container’s CPU limit is too low, or its request is too low causing it to be scheduled on an overloaded node.

    Solution:

    • Increase the CPU requests and limits for the affected container.
    • Monitor CPU usage with tools like kubectl top pod or Prometheus to identify the bottleneck.
    • Review the LimitRange to ensure the max CPU limit is not preventing adequate resource allocation.
    • Consider optimizing the application code to be more CPU efficient.
  4. Issue: ResourceQuota error: must specify a resource name.

    Problem: This error typically occurs when you define a ResourceQuota for a specific resource, but the resource definition itself is missing the necessary resource requests or limits.

    Solution:

    • Ensure that any Pods or Deployments in the namespace specify resources.requests and resources.limits for CPU and memory.
    • If you have a LimitRange in place, ensure it has appropriate defaultRequest and default limits, so resources are automatically injected.
  5. Issue: A LimitRange is present, but Pods are still created without requests/limits.

    Problem: This usually means the LimitRange is not applying as expected.

    Solution:

    • Verify the LimitRange is in the correct namespace: 
      kubectl get limitrange -n <namespace>
    • Check the type field in your LimitRange. It should typically be Container for Pod resources.
    • Ensure the Pods being created are indeed in the namespace where the LimitRange is applied.
    • Sometimes, older Pod definitions in a Deployment might not pick up new LimitRange rules without a rolling update.
  6. Issue: Quota for requests.storage is exceeded, but I have few PVCs.

    Problem: This quota limits the sum of all requested storage capacities, not just the number of PVCs.

    Solution:

    • Check the size of each PersistentVolumeClaim in the namespace.
    • kubectl get pvc -n <namespace> -o custom-columns=NAME:.metadata.name,SIZE:.spec.resources.requests.storage
    • Sum these sizes and compare with your quota. You might need to increase the requests.storage quota or reduce the size of your PVCs.

FAQ Section

  1. Q: What is the difference between Resource Quotas and LimitRanges?

    A: Resource Quotas operate at the namespace level, limiting the aggregate resource consumption (e.g., total CPU, total memory, total number of pods) for all resources within that namespace. LimitRanges operate at the Pod/Container level, enforcing default resource requests/limits and setting minimum/maximum bounds for individual containers within a namespace. They work hand-in-hand: Quotas set the budget, LimitRanges ensure individual items fit within that budget and have sensible defaults.

  2. Q: Do I need both Resource Quotas and LimitRanges?

    A: Yes, for robust resource management, it’s highly recommended to use both. LimitRanges ensure that every container has defined requests and limits, preventing “naked” containers that can consume unbounded resources. Resource Quotas then ensure that the sum of all these defined requests and limits for all containers in a namespace doesn’t exceed a predefined budget. This combination provides comprehensive control.

  3. Q: What happens if a Pod doesn’t specify resource requests or limits when a LimitRange is present?

    A: If a LimitRange is configured with defaultRequest and default values for CPU and memory, Kubernetes’ admission controller will automatically inject these default values into the Pod’s containers. This ensures that every container has a baseline resource footprint, even if the developer forgets to specify them.

  4. Q: Can I apply Resource Quotas or LimitRanges to individual Pods or Deployments?

    A: No, both Resource Quotas and LimitRanges are namespace-scoped objects. They apply to all resources within the namespace where they are defined. If you need different resource constraints for specific applications, you should consider placing them in separate namespaces, each with its own Resource Quota and/or LimitRange.

  5. Q: How do Resource Quotas affect Kubernetes scheduling?

    A: Resource Quotas themselves don’t directly influence the Kubernetes scheduler (Kube-scheduler). However, the resource requests defined on Pods (either explicitly or injected by LimitRanges) are crucial for scheduling. The scheduler uses these requests to find a node with enough available resources to accommodate the Pod. If a Pod’s requests cannot be met by any node, it will remain in a Pending state. Resource Quotas ensure that the sum of these requests within a namespace doesn’t exceed the defined budget, indirectly influencing what can be scheduled within that namespace.

Cleanup Commands

To remove the resources created in this tutorial:


# Delete the Pods and Deployments
kubectl delete deployment nginx-deployment-quota-test -n dev-team-a
kubectl delete pod nginx-pod-1 cpu-hog-pod -n dev-team-a

# Delete the LimitRange
kubectl delete limitrange dev-limits -n dev-team-a

# Delete the ResourceQuota
kubectl delete resourcequota dev-quota -n dev-team-a

# Delete the namespace
kubectl delete namespace dev-team-a

Next Steps / Further Reading

Congratulations! You’ve successfully implemented and tested Kubernetes Resource Quotas and LimitRanges. To deepen your understanding and further enhance your cluster management:

Conclusion

Kubernetes Resource Quotas and LimitRanges are indispensable tools for any cluster administrator striving for stability, fairness, and efficiency. By strategically implementing these controls, you can prevent resource contention, ensure predictable application performance, and foster a healthy multi-tenant environment. While they might seem like a barrier at first, they are ultimately a mechanism for promoting best practices and safeguarding your cluster’s integrity. Embrace them as a foundational layer of your Kubernetes governance strategy, and your cluster (and your developers) will thank you.

Leave a comment