About the Quota & LimitRange Generator
ResourceQuota and LimitRange both constrain resource usage in a namespace, but they operate at different levels and are routinely confused. A ResourceQuota caps the total across the namespace — the sum of all CPU requests, all memory limits, or simply the number of pods. A LimitRange constrains an individual container, supplying defaults when a manifest omits them and rejecting values outside an allowed band.
They are most useful together. A LimitRange that sets default requests and limits means no container arrives unspecified, and a ResourceQuota then makes the namespace total enforceable. Without the LimitRange, the first pod deployed with no resource requests into a namespace that has a CPU quota is simply rejected, which produces a confusing failure a long way from its cause.
The distinction to keep clear underneath all of this is requests versus limits. Requests are what the scheduler reserves and are what determine whether a pod fits on a node. Limits are what the runtime enforces at execution time — exceeding a CPU limit throttles the container, while exceeding a memory limit kills it.
Frequently asked questions
What is the difference between ResourceQuota and LimitRange?
ResourceQuota is a namespace-wide ceiling on aggregate consumption, such as total memory requested across all pods or the number of persistent volume claims that may exist. LimitRange applies per container or per pod, providing defaults for omitted values and enforcing minimum and maximum bounds. One caps the whole namespace, the other shapes each workload.
Why is my pod rejected with a failed quota error?
Once a ResourceQuota specifies a request or limit for a resource, every container in that namespace must specify the corresponding value, and a pod omitting it is rejected outright. The clean fix is a LimitRange in the same namespace supplying defaults, so existing manifests keep working. The other possibility is the obvious one: the namespace total really is exhausted.
Should I set CPU limits at all?
This is genuinely contested. A CPU limit throttles the container through the kernel quota mechanism, and throttling can add latency even when the node has idle capacity — so for latency-sensitive services many teams set requests and deliberately omit limits. Memory is different: memory is not compressible, so an unlimited container can consume the node and cause evictions elsewhere. Setting memory limits is close to always correct.
What happens when a container exceeds its limits?
The two resources behave completely differently. Exceeding a CPU limit throttles the container, which shows up as latency rather than failure. Exceeding a memory limit means the kernel out-of-memory killer terminates the process, and the pod is reported as OOMKilled with exit code 137. That is why memory limits need headroom over observed peak usage rather than being set at the average.
Do quotas apply to existing pods when I add one?
No. Quota enforcement happens at admission, so a new ResourceQuota does not evict anything already running, even if the namespace is already over the new ceiling. It only blocks subsequent creations. Expect a period where usage exceeds the quota until workloads are rescheduled or resized.