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.
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.