Kubernetes LimitRanges and ResourceQuotas: Stop Your Cluster from Starving

You've deployed your microservices, everything's humming, and then one day a team deploys a cron job that requests 32GB of memory. Your cluster runs out, pods get evicted, and your payments service goes down at 3am. That's not bad luck — that's missing resource governance.

Kubernetes gives you two tools to prevent this: LimitRanges and ResourceQuotas. They're not optional in any multi-tenant or production cluster. Without them, you're one resources: {} away from a cluster-wide outage.

By the end of this article, you'll know exactly how to configure LimitRanges and ResourceQuotas to protect your cluster, enforce team fairness, and debug the inevitable 'exceeded quota' errors without panicking.

Why You Need Resource Governance: The Noisy Neighbor Problem

Without resource governance, any pod can request any amount of CPU or memory. In a multi-team cluster, one team's misconfigured deployment can consume all available resources, starving other teams' pods. This is the noisy neighbor problem.

ResourceQuotas solve this by capping total resource usage per namespace. LimitRanges solve it by enforcing per-pod resource boundaries. Together they ensure fair sharing and prevent a single bad deployment from taking down the cluster.

Before these tools existed, teams had to rely on manual monitoring and hope. I've seen a single node-exporter daemonset with resources: {} consume 8GB on every node because it defaulted to unlimited. That's a production incident waiting to happen.

// io.thecodeforge — DevOps tutorial

# Without resource limits, this pod can use all node resources
apiVersion: v1
kind: Pod
metadata:
  name: greedy-pod
spec:
  containers:
  - name: stress
    image: polinux/stress
    command: ["stress"]
    args: ["--vm", "1", "--vm-bytes", "64G", "--vm-hang", "1"]
    # No resources specified — will consume 64GB if available

ResourceQuotas: The Hard Cap Per Namespace

A ResourceQuota sets a hard limit on total resource usage within a namespace. You can cap CPU, memory, storage, and even object counts (pods, services, etc.). Once the quota is reached, no new pods can be created until resources are freed.

This is your first line of defense against a team accidentally consuming the entire cluster. But there's a catch: you must set resource requests on every pod, or the quota won't be enforced. Kubernetes rejects pods without requests if a quota exists.

I've seen teams create a quota and then wonder why their pods won't start — they forgot to add resources.requests to their deployments. The error message exceeded quota is clear, but people still miss it.

// io.thecodeforge — DevOps tutorial

apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-quota
  namespace: analytics
spec:
  hard:
    requests.cpu: "4"
    requests.memory: "8Gi"
    limits.cpu: "8"
    limits.memory: "16Gi"
    pods: "10"
    persistentvolumeclaims: "5"
    requests.storage: "50Gi"

LimitRanges: Per-Pod Resource Boundaries

A LimitRange enforces min, max, and default resource values per pod or container within a namespace. This prevents a single pod from requesting an absurd amount of resources while also ensuring every pod gets a baseline.

Without LimitRanges, a team could create a pod with requests.memory: 100Gi — which would be denied by quota if the total exceeds it, but if quota has room, it's allowed. LimitRange catches this at the pod level.

LimitRanges also set default requests and limits for pods that don't specify them. This is useful but dangerous: if your app needs 2Gi but the default is 512Mi, it will get OOMKilled. Always verify defaults match your workload.

// io.thecodeforge — DevOps tutorial

apiVersion: v1
kind: LimitRange
metadata:
  name: container-limits
  namespace: analytics
spec:
  limits:
  - max:
      cpu: "2"
      memory: "4Gi"
    min:
      cpu: "100m"
      memory: "128Mi"
    default:
      cpu: "500m"
      memory: "1Gi"
    defaultRequest:
      cpu: "200m"
      memory: "512Mi"
    type: Container

How LimitRanges and ResourceQuotas Interact

LimitRanges and ResourceQuotas work together but enforce different scopes. LimitRanges validate each pod individually at creation time. ResourceQuotas track cumulative usage across all pods in the namespace.

When a pod is created, Kubernetes first checks the LimitRange (if any) to ensure the pod's resources are within min/max. Then it checks the ResourceQuota to ensure the new pod doesn't exceed the namespace's total cap.

A common pitfall: if you set a LimitRange with a max that is larger than the remaining quota, a pod that passes the LimitRange check may still fail the quota check. This is correct behavior, but it can confuse developers who only see the quota error.

// io.thecodeforge — DevOps tutorial

# Assume quota: requests.memory: 8Gi, used: 7.5Gi
# LimitRange: max memory: 4Gi
# A pod requesting 1Gi memory passes LimitRange (1Gi < 4Gi) but fails quota (7.5+1=8.5 > 8Gi)
# Error: 'exceeded quota: team-quota, requested: memory=1Gi, used: memory=7.5Gi, limited: memory=8Gi'

Production Patterns: Setting Realistic Defaults

In production, you need to balance protection with flexibility. Setting overly restrictive defaults breaks deployments. Setting none leaves you exposed.

Pattern 1: Start with generous limits and tighten over time. Set max high enough to accommodate any reasonable workload, then monitor actual usage and reduce.

Pattern 2: Use defaultRequest and default to match your most common workload. If most services use 256Mi-512Mi, set defaults accordingly. For outliers, teams must explicitly override.

Pattern 3: Always set min to prevent zero-request pods. A pod with requests.cpu: 0 can still consume CPU, causing unpredictability. Set min to at least 10m or 50m.

// io.thecodeforge — DevOps tutorial

apiVersion: v1
kind: LimitRange
metadata:
  name: production-limits
  namespace: production
spec:
  limits:
  - max:
      cpu: "8"
      memory: "32Gi"
    min:
      cpu: "10m"
      memory: "64Mi"
    default:
      cpu: "500m"
      memory: "1Gi"
    defaultRequest:
      cpu: "250m"
      memory: "512Mi"
    type: Container

When Not to Use LimitRanges and ResourceQuotas

In a single-team cluster where everyone trusts each other, you might skip these. But even then, a misconfigured deployment can cause issues. I'd still recommend at least a ResourceQuota.

For ephemeral clusters (CI/CD, test environments), strict quotas can cause unnecessary failures. Consider setting high quotas or none at all for short-lived clusters.

If you use autoscaling (Cluster Autoscaler), quotas can prevent the cluster from scaling up because new pods are rejected before the autoscaler can add nodes. This is a known pain point — you need to ensure quota is high enough to allow burst scaling.

Debugging Resource Governance Issues

When a pod fails to start, the error message usually points to quota or limit range. But sometimes it's not obvious.

Step 1: Run kubectl describe pod <pod-name> and look for events at the bottom. You'll see FailedCreate or Failed with a reason.

Step 2: Check quota: kubectl get quota -n <ns> -o yaml. Look at status.hard vs status.used.

Step 3: Check LimitRange: kubectl describe limitrange -n <ns>. Verify min/max/defaults.

Step 4: If the pod has no resources set, the LimitRange defaults are applied. Check if those defaults are appropriate.

I once spent an hour debugging a pod that kept getting OOMKilled. Turns out the LimitRange default memory limit was 256Mi, but the app needed 1Gi. The fix was to set explicit resources on the deployment.

// io.thecodeforge — DevOps tutorial

# Check pod events
kubectl describe pod my-pod -n my-namespace

# Check quota usage
kubectl get quota -n my-namespace -o yaml

# Check LimitRange details
kubectl describe limitrange -n my-namespace

# See all resources in namespace
kubectl get pods -n my-namespace -o custom-columns=NAME:.metadata.name,REQ_CPU:.spec.containers[*].resources.requests.cpu,REQ_MEM:.spec.containers[*].resources.requests.memory,LIM_CPU:.spec.containers[*].resources.limits.cpu,LIM_MEM:.spec.containers[*].resources.limits.memory

Common Mistakes and How to Avoid Them

Mistake 1: Setting defaultRequest higher than default for the same resource. Kubernetes rejects the LimitRange. Fix: ensure defaultRequest <= default.

Mistake 2: Forgetting to set resource requests on pods when a quota exists. Pods fail with exceeded quota. Fix: always set resources.requests in your deployments.

Mistake 3: Setting quota too low, causing valid deployments to fail. Fix: monitor usage over time and adjust quota accordingly. Use kubectl describe quota to see usage.

Mistake 4: Not setting limits.storage in quota, allowing unbounded PVC usage. Fix: always include requests.storage and persistentvolumeclaims in quota.