exceeded quota: The namespace's ResourceQuota does not allow this object

A ResourceQuota caps what a namespace may consume. Exceeding it rejects the object at admission, and when the rejection hits a controller rather than a person, it shows up as pods that never appear.

Applies to: All Kubernetes versions

What it means

A ResourceQuota limits a namespace's total consumption — CPU and memory requests and limits, object counts, storage. Requests that would exceed it are rejected with a message naming the quota, the resource, the amount requested, the amount used, and the limit. Two consequences are worth separating. When you apply a manifest directly, you see the error immediately. When a Deployment's ReplicaSet hits the quota, the rejection lands on the controller, so kubectl get pods shows fewer pods than expected and no error anywhere obvious — the message is on the ReplicaSet's events. There is also a rule that catches people: once a quota constrains CPU or memory, every container in the namespace must declare requests and limits for the constrained resources, or it is rejected outright.

Most common causes

• The namespace has genuinely reached its allocation.
• A container without resource requests or limits in a namespace whose quota constrains those resources.
• A rollout temporarily needing more than the quota allows, because old and new pods coexist during the update.
• Object count quotas — too many Services, Secrets, or PersistentVolumeClaims.
• A quota on storage that a new claim would exceed.
• Resources held by objects nobody is tracking, such as completed Job pods that were never cleaned up.

How to diagnose it

1. See usage against limits: kubectl describe quota -n NAMESPACE. This is the whole picture in one command.
2. If pods are missing rather than erroring, read the ReplicaSet's events: kubectl describe replicaset RS -n NAMESPACE.
3. Find what is consuming the quota: kubectl get pods -n NAMESPACE -o custom-columns=NAME:.metadata.name,CPU:.spec.containers[*].resources.requests.cpu,MEM:.spec.containers[*].resources.requests.memory.
4. Look for completed Job pods and other leftovers holding object counts.
5. Check for a LimitRange in the namespace, which supplies defaults and can interact with the quota in ways that are not obvious.

How to fix it

1. Raise the quota, if the namespace's allocation is genuinely too small for what it now runs.
2. Set requests and limits on every container. Under a quota this is mandatory, not advisory.
3. Add a LimitRange with defaults so containers that omit resources still satisfy the quota.
4. Reduce requests that were set far above real usage — over-requesting is the most common reason a namespace hits a quota it should not.
5. Set ttlSecondsAfterFinished on Jobs and history limits on CronJobs so completed pods do not accumulate.
6. Allow headroom for rollouts, or use maxSurge: 0 so an update does not need capacity for extra pods.

Notes

The rollout interaction is the one that surprises people most: a Deployment that fits comfortably within quota when running can fail to update, because the default strategy briefly needs capacity for extra pods. The symptom is a rollout that stalls with no obvious error on the Deployment itself.

Related

• LimitRange violation — The pod's resources fall outside the namespace's allowed range
• FailedCreate — A controller could not create its pods

Sources

• Kubernetes documentation — Resource Quotas
• Kubernetes documentation — Limit Ranges
• Kubernetes documentation — Resource Management for Pods and Containers