A Kubernetes resource quota is a hard limit on the total CPU, memory and object count a namespace may consume, and it is one of the most direct ways to control spend in a shared cluster. Because the cluster autoscaler adds nodes to satisfy whatever pods are scheduled, an unbounded namespace can grow the node count, and the bill, without anyone deciding to. A quota caps the requests a namespace can hold, which caps the nodes it can drive, which caps its cost. This guide walks through setting quotas and limit ranges so each team runs inside a known budget rather than an open tab.
This how-to is part of our Kubernetes and container cost cluster. For the full picture, see the complete guide to Kubernetes cost optimization, the pillar this article links up to. Quotas only make sense on top of sensible per-pod requests, which is covered in how to rightsize Kubernetes requests and limits.
Step 1 · Map namespaces to owners and budgets
A quota is only a cost control if each namespace maps to a team or workload with an owner who answers for its spend. Start by giving every namespace a label that identifies the owning team and cost center, the same allocation backbone described in Kubernetes cost allocation by namespace, label and pod. Then translate each team's budget into a CPU and memory ceiling. The point is that the quota is not an arbitrary technical number, it is the team's budget expressed in cluster resources, which is what makes it defensible when someone hits the wall.
Step 2 · Set a ResourceQuota on requests
Apply a ResourceQuota object that caps the sum of CPU and memory requests across all pods in the namespace. Cap requests rather than limits, because the scheduler reserves capacity by requests and that is what drives node count and cost. Setting a request quota means the namespace can never reserve more capacity than its budget allows, so it can never push the cluster to add nodes beyond its share. Add an object-count quota too, capping pods and other objects, to stop a runaway controller from creating thousands of objects that each carry overhead.
Want quotas set to real budgets, not guesses?
Our cost audit translates each team's budget into the right quota, sets the limit ranges that make them work, and wires the alerts that warn before a namespace hits its ceiling. On the performance model, you pay only from realized savings. No savings, no fee.
Book a cloud cost audit →Step 3 · Add a LimitRange so quotas actually bind
A ResourceQuota on requests has a catch: if pods are created without requests set, the quota cannot account for them. A LimitRange fixes this by setting default requests and limits for any pod in the namespace that does not specify its own, and by setting minimum and maximum bounds per container. With a LimitRange in place, every pod carries a request the quota can count, no pod can claim an absurd amount, and the quota becomes enforceable. Quotas and limit ranges are a pair: the quota sets the namespace ceiling, the limit range makes every pod countable against it.
Step 4 · Right-size the quota, do not just cap it
A quota set far above real usage controls nothing, and a quota set too tight blocks legitimate work and generates noise. Size each quota from observed usage plus a sensible headroom for growth and bursts, then revisit it as the workload changes. The goal is a ceiling that sits a little above genuine need, so it never interferes with normal operation but stops the runaway cases. This is the same discipline as cluster-wide rightsizing, covered in the cost of over-provisioned Kubernetes clusters, applied at the namespace boundary.
Step 5 · Alert before the ceiling, and review monthly
A quota that silently rejects pods at full utilization creates incidents, not savings. Alert when a namespace crosses a high share of its quota so the owning team can rightsize or request more budget before work is blocked, turning the ceiling into a conversation rather than a surprise. Review quotas monthly against actual usage and against the showback numbers from how to build Kubernetes showback, so budgets and quotas stay aligned and teams see the cost behind their ceiling.
| Control | What it caps | Why it matters for cost |
|---|---|---|
| ResourceQuota (requests) | Namespace CPU and memory | Caps nodes a team can drive |
| ResourceQuota (objects) | Pod and object counts | Stops runaway creation |
| LimitRange defaults | Per-pod requests | Makes pods countable |
| LimitRange max | Per-container ceiling | Blocks absurd claims |
| Quota alerts | Approach to ceiling | Prevents blocked work |
Quota and limit-range behavior above reflects Kubernetes as of May 2026. Verify the current API objects and fields in the Kubernetes documentation before applying, as defaults and scopes evolve across versions.
The Kubernetes Cost Optimization Handbook includes the quota-sizing worksheet and the limit-range templates referenced here. It is the downloadable companion.
The short version
Resource quotas turn a shared cluster into a set of budgets. Map namespaces to owners, cap requests with a ResourceQuota, make every pod countable with a LimitRange, size the ceiling from real usage plus headroom, and alert before anyone hits the wall. Together these stop one team's growth from quietly expanding everyone's bill. When you want quotas set to real budgets and held in place, that is what our rightsizing and waste elimination service delivers.