← Debugging Guides

阅读中文版本

Kubernetes: exceeded quota for pods or requests

Diagnose Kubernetes quota errors when creating pods, and understand ResourceQuota limits on counts and aggregate CPU/memory requests.

intermediatedebuggingkubernetesquotascheduling

Symptoms

  • Error from server (Forbidden): exceeded quota: pods, requested: 1, used: 10, limited: 10
  • A deployment cannot create new pods
  • Rolling updates stall with quota errors

Possible causes

  • The namespace ResourceQuota caps pod count and it is full
  • Aggregate requests or limits for CPU/memory are exhausted
  • Old pods from a previous rollout still hold quota
  • A new workload requests more resources than the quota allows

Diagnosis steps

Inspect the quota and its usage

kubectl describe resourcequota -n <ns>

Interpretation

The Used vs Hard columns show exactly which dimension is exhausted.

Count running pods in the namespace

kubectl get pods -n <ns>

Interpretation

Lingering or completed pods still consume the pods quota.

Check the new workload resource requests

Interpretation

A request larger than the remaining quota is rejected even when pod count is under the limit.

Root cause

A ResourceQuota caps the aggregate pod count and the sum of resource requests and limits in a namespace. Creating a pod that would push any dimension past its Hard value is rejected by the API server. Completed or orphaned pods still count until deleted, so quota can appear full while few pods run.

Fix

Delete completed or orphaned pods, scale down unneeded workloads, or raise the quota within cluster policy. Reduce the new workload resource requests to fit, and set delete policies so finished Jobs do not accumulate. In clusters with quota on requests, ensure every pod declares requests so scheduling is accurate.

Verify the fix

Retry the deployment; pods are admitted, and `kubectl describe resourcequota` shows usage below the Hard limits for every dimension.

Symptoms

The API server rejects pod creation with exceeded quota. Deployments stall or fail to roll forward, while existing pods keep running.

Diagnosis

Compare usage to limits and count pods:

kubectl describe resourcequota -n prod
kubectl get pods -n prod --field-selector status.phase!=Running

Completed pods often still hold the pods quota.

Fix

Free quota and right-size requests:

kubectl delete pod -n prod --field-selector status.phase=Succeeded
resources:
  requests: { cpu: "100m", memory: "128Mi" }   # fit within remaining quota

Verification

Re-apply the deployment; pods are admitted and kubectl describe resourcequota shows every Used value below its Hard limit, confirming the quota is no longer blocking.

Quota Dimensions People Forget

ResourceQuota limits more than pod count: it can cap the sum of CPU and memory requests and limits, the number of services, secrets, and persistent volume claims, and even storage bytes across the namespace. A failure naming pods is easy to read, but a request larger than remaining CPU is rejected with a message about requests that many people skim past. When a deployment cannot scale, list all dimensions in the quota and check each Used value, because the blocking dimension is often object count or aggregate memory rather than the one the error seems to name at first glance.