Resource Quotas and LimitRanges in Kubernetes: Fair Sharing for Shared Clusters
Learn how Kubernetes stops one team from eating the whole cluster, how it fills in missing resource settings automatically, and how the two features work together to keep shared platforms fair, predictable, and affordable.
Picture a shared apartment where four flatmates split one refrigerator, one electricity bill, and one water tank. Without any house rules, one flatmate can fill every shelf with party food, run the heater all night, and leave nothing for the others. The fix is not a bigger fridge. The fix is simple rules: each person gets two shelves, and nobody may take more than half a shelf for a single dish. Kubernetes has exactly these two kinds of house rules. A ResourceQuota is the rule that says how much each household may use in total. A LimitRange is the rule that says how big any single item may be, and what size to assume when someone does not say. This tutorial explains both from the ground up.
1Why Shared Clusters Need Rules
A cluster is a pool of computers, and pools are shared by many teams who do not always behave politely.
One cluster, many tenants
Running a separate Kubernetes cluster for every team is expensive and hard to manage. Most companies instead run a few large clusters and give each team its own namespace, which is a named section of the cluster that keeps one team’s objects apart from another’s. A payments team gets one namespace, a search team gets another, and a data science team gets a third. Everyone shares the same pool of processors, memory, disks, and network addresses underneath.
This sharing is efficient, but it creates a famous problem called the noisy neighbor. Kubernetes by default does not limit how much a namespace may ask for. If a single team accidentally deploys an application with a runaway loop that creates thousands of copies, or requests far more memory than it needs, it can use up the capacity that every other team was counting on.
Three kinds of damage
Starvation
One namespace consumes so much processing power and memory that other teams’ new applications cannot find a machine with room, and their pods sit waiting forever.
Surprise bills
On cloud providers every extra machine and every extra load balancer costs real money. A mistake that creates fifty load balancers overnight is a bill nobody planned.
Control plane overload
Kubernetes stores every object in its database. Millions of tiny objects, such as configuration entries or finished job records, can slow the whole cluster down, even if they use almost no processing power.
A public library lets every member borrow books. Without a borrowing limit, one enthusiastic reader could check out every book on gardening, and nobody else could ever read about tomatoes. A limit of ten books per person keeps the shelves useful for everyone.
A namespace with no quota and no limit range is unlimited by default. The built-in default namespace and any new namespace you create start in exactly this open state.
2Requests and Limits: The Foundation
Before quotas make sense, you must understand how a single container describes the resources it needs.
Two numbers per resource
Every container can state two numbers for processing power and two numbers for memory. The first number is called the request. It is the amount the container is guaranteed, and it is the amount the scheduler uses when deciding which machine has room. The second number is called the limit. It is the ceiling the container may never cross while running.
When you book a restaurant table, the number of seats you reserve is your request. The restaurant holds that space for you. The limit is the most seats the restaurant will ever let your group squeeze into, even if your friends keep arriving.
How each resource is measured
| Resource | Unit and examples | What happens at the limit |
|---|---|---|
| Processing power (CPU) | Whole cores or thousandths of a core called millicores. Half a core is five hundred millicores. | The container is slowed down, which is called throttling. It keeps running but gets less time on the processor. |
| Memory | Bytes, usually written in binary multiples such as mebibytes and gibibytes | The container is killed for running out of memory and is usually restarted. |
| Ephemeral storage | Bytes of temporary disk space on the machine | The pod can be evicted if it uses more than its allowance. |
Why this difference matters
Processing power is compressible. If a container wants more than its limit, Kubernetes simply makes it wait a little. Memory is not compressible. You cannot take back memory that a program is already holding without destroying the program. That is why exceeding a memory limit ends in a hard kill while exceeding a CPU limit only slows things down.
Quantity suffixes are case sensitive and easy to confuse. A lowercase letter m means thousandths, so a memory value written with a lowercase m means a tiny fraction of a byte rather than megabytes. Also, the binary suffixes with an i, such as Mi and Gi, differ slightly from the decimal ones such as M and G. Always double check units when writing quota numbers.
Who reads which number
The scheduler reads requests to find a machine with enough free room. The kubelet, which is the agent running on each machine, enforces limits while the container runs. Quotas and limit ranges, as you will soon see, can control both numbers, which is why they are such useful guardrails.
3Quality of Service Classes
The way a pod sets requests and limits decides how it is treated when a machine runs short of resources.
Three classes, assigned automatically
Kubernetes sorts every pod into one of three quality of service classes, based purely on how its containers set requests and limits. You never choose the class directly. It is worked out for you.
Guaranteed
Every container sets both a request and a limit for processing power and memory, and the request equals the limit. These pods are the last to be removed when a machine is under pressure.
Burstable
At least one container sets a request or a limit, but the pod does not meet the strict rule for Guaranteed. These pods may use more than they requested when spare room exists.
BestEffort
No container sets any request or limit at all. These pods get whatever is left over and are the first to be removed when a machine runs short.
Think of a flight. Guaranteed pods hold confirmed seats. Burstable pods hold seats but may be upgraded if the cabin has room. BestEffort pods are on the standby list and are the first to be asked to step off if the plane is overweight.
Why quotas care about this
BestEffort pods are especially troublesome in shared clusters. Because they declare nothing, they look free to the scheduler, so many of them can pile onto one machine. When that machine runs short of memory, they are evicted, and the churn can disturb neighbors. Quotas and limit ranges give platform teams a way to refuse or fix such pods before they ever start.
A LimitRange that adds default requests and limits quietly moves pods out of the BestEffort class, because they no longer declare nothing.
4What a ResourceQuota Is
A ResourceQuota is a budget for an entire namespace.
The idea in one sentence
A ResourceQuota is a Kubernetes object that sets hard totals for a namespace. It can cap the sum of processing power and memory the namespace requests, the sum of limits it declares, the amount of storage it claims, and the number of objects of various kinds it may create.
How it behaves
When someone tries to create or change an object in the namespace, Kubernetes checks the quota. If the new total would stay within the budget, the request is accepted and the quota’s used amount goes up. If it would push the namespace over any limit, the request is refused immediately with a clear error. The object is never created, so there is no half way state.
The quota object itself carries two sets of numbers. The hard set is the maximum you configured. The used set is what the namespace currently consumes. You can read both at any time to see how much room is left.
A ResourceQuota is a monthly allowance on a prepaid card. Each purchase is checked against the remaining balance. If there is enough, it goes through and the balance drops. If not, the card is declined on the spot.
What it does not do
It does not reserve capacity
A quota is a ceiling, not a guarantee. Giving a team a large quota does not mean machines are set aside for them. If the cluster itself runs out of room, quota or not, their pods will wait.
It does not remove running objects
If you lower a quota below what a namespace already uses, running pods are left alone. Only new creations are blocked until usage falls back under the new limit.
It does not look at actual usage
The numbers counted are the declared requests and limits, not the real memory or processing a container uses at runtime. A container that asks for a lot and uses a little still consumes quota in full.
Many beginners assume a quota guards actual live consumption. It guards what you asked for on paper. This is why accurate requests matter so much, a point we return to when discussing right sizing.
5What a LimitRange Is
A LimitRange sets the size rules for individual items inside a namespace and fills in missing values.
The idea in one sentence
A LimitRange is a Kubernetes object that defines the smallest, largest, and default sizes for a single container, a single pod, or a single storage claim in a namespace.
Two jobs in one
A LimitRange does two different things. First, it fills in defaults. If a container arrives without a request or a limit, the LimitRange adds one. Second, it enforces boundaries. If a container asks for less than the allowed minimum or more than the allowed maximum, the whole pod is refused.
A tailor shop might have a rule that every shirt order must be between small and extra large, and that if a customer forgets to say a size, the shop assumes medium. The rule protects the shop from impossible orders and saves customers from filling in every detail.
What it can cover
Container
Rules for each container individually, such as the largest memory any single container may ask for. This is the most commonly used type.
Pod
Rules for the combined total of all containers in one pod, useful when a pod has several helper containers.
PersistentVolumeClaim
Rules for the minimum and maximum size of a single storage claim, so nobody requests a tiny useless disk or an enormous expensive one.
A quota controls the total for the whole namespace. A limit range controls the size of each individual piece. You almost always want both.
6ResourceQuota and LimitRange Side by Side
The two features look related, but they answer different questions.
| Aspect | ResourceQuota | LimitRange |
|---|---|---|
| Question it answers | How much can this whole namespace use in total? | How big can one container, pod, or storage claim be, and what is the default? |
| Level of control | Namespace total | Each individual item |
| Fills in defaults | No | Yes, for requests and limits |
| Can count objects | Yes, such as the number of pods, services, or secrets | No |
| Can cap storage totals | Yes | Only the size of each single claim |
| Affects existing objects | No | No |
| Scope | One namespace | One namespace |
| When refusal happens | When the new total would exceed the budget | When one item is outside the allowed size range |
Why each needs the other
A quota alone has a weakness. Within a generous quota, one team member can still create a single enormous container that swallows most of the budget and leaves nothing for colleagues in the same namespace. A limit range caps the size of each piece, so no single container can dominate.
A limit range alone has the opposite weakness. It keeps each piece reasonable, but there is nothing to stop someone from creating thousands of reasonably sized pieces. A quota caps the total count and size.
Finally, quotas on requests and limits actually refuse pods that do not declare those values at all. A limit range solves this by supplying defaults. Together they form a smooth system: the limit range prepares each pod, and the quota decides whether the namespace can afford it.
7Where They Act: The Admission Path
Both features run inside the API server, at the moment a request arrives, before anything is stored.
Admission control in a nutshell
Every request that creates or changes an object enters the Kubernetes API server and passes through a series of stages. After the caller has been identified and authorized, the request meets a group of checkpoints called admission controllers. Some can modify the request, and some can only accept or refuse it. Both the limit range feature and the quota feature are built-in admission controllers that are switched on in standard clusters.
The order of events
Request arrives for a new pod
Someone, or a controller acting for them, asks to create a pod in a namespace. The pod may or may not declare its requests and limits.
LimitRange fills in defaults
If the namespace has a limit range, any missing requests and limits are added to the pod, so it now carries complete values.
LimitRange checks boundaries
The final values are compared with the minimum, maximum, and ratio rules. Anything outside is refused here.
Other changes may happen
Other admission steps, including any custom ones installed by the platform team, can still modify or reject the pod. For example, a helper container might be injected.
ResourceQuota is checked last
The quota check is designed to run at the end of the admission chain, so it counts the pod exactly as it will be stored, including defaults and any injected containers.
Pod is stored
If every check passed, the pod is saved, the quota’s used amount is increased, and the scheduler can start looking for a machine.
flowchart LR
A[Pod request] --> B[LimitRange adds defaults]
B --> C[LimitRange checks min and max]
C --> D[Other admission steps]
D --> E[ResourceQuota check]
E --> F[Pod saved]
C --> X[Refused]
E --> X
Why the order is sensible
Defaults are applied first so that the later checks see complete, realistic numbers. The quota is checked last so it sees the final shape of the pod. If it ran early, a later change, such as an injected helper container, could push the namespace over budget after the quota had already approved.
Admission happens before the scheduler looks at the pod. A refused pod never reaches the scheduler, so it never appears as a Pending pod. This often confuses people searching for a missing pod.
8Compute Quotas: CPU, Memory, and Ephemeral Storage
The most popular use of a quota is to cap the total processing power and memory a namespace may claim.
The compute fields
requests for CPU
The sum of all CPU requests across non finished pods in the namespace may not exceed this number.
requests for memory
The sum of all memory requests may not exceed this number.
limits for CPU
The sum of all CPU limits may not exceed this number.
limits for memory
The sum of all memory limits may not exceed this number.
ephemeral storage
Requests and limits for temporary disk space can be capped in the same way.
extended resources
Special hardware such as graphics cards can be capped by their request counts. Extended resources cannot be over committed, so only the request form is accepted.
The “must declare it” rule
Here is the rule that surprises almost every newcomer. If a namespace has a quota covering CPU or memory requests or limits, then every new pod must declare that value. A pod that leaves it blank is refused, because Kubernetes cannot add an unknown number to the running total. The error message tells the person which value was missing.
This is the exact moment when a LimitRange becomes valuable. With defaults supplied by a limit range, a pod that forgot to declare its numbers is filled in before the quota check, and everything goes through smoothly.
What counts toward the total
Only pods that are still active
Pods that have finished, either successfully or by failing, stop counting. A job that completed hours ago does not hold on to quota even if its pod record still exists.
All containers in the pod
Every regular container, helper container, and init container is considered. For init containers that run one after another before the main ones, Kubernetes counts whichever is larger: the biggest init container or the sum of the regular containers.
Pod overhead
Some container runtimes add a fixed extra cost per pod. When a runtime class declares this overhead, it is added to the pod’s total and counted against the quota too.
Imagine a corporate travel budget where every trip request must list its cost before approval. A request with a blank cost cannot be added to the monthly total, so it bounces back. A travel desk that fills in a typical cost for forgetful travelers keeps the process moving.
Adding a quota on a busy namespace without adding a limit range first. Suddenly deployments that worked yesterday start failing to create pods because they never declared their numbers.
9Storage Quotas
Disks cost money and cannot be shrunk easily, so storage deserves its own budget.
What can be capped
A quota can cap the total amount of storage that persistent volume claims in a namespace may request, and it can cap how many such claims may exist. It can also do this separately for each storage class, which is how you give a team plenty of cheap slow storage but only a little expensive fast storage.
| What you cap | Plain meaning | Example reason |
|---|---|---|
| Total storage requested | Sum of the sizes asked for by all claims in the namespace | Stop a team from claiming terabytes by accident |
| Number of claims | How many separate storage claims may exist | Prevent thousands of tiny volumes that clutter the cloud account |
| Storage per class | Totals and counts for one specific storage class | Limit expensive fast disks while allowing cheaper ones |
| Ephemeral storage | Temporary disk on machines used by pods | Protect machines from filling up with scratch files |
Pairing with a LimitRange
A limit range can set a minimum and maximum size for each individual storage claim. A quota then caps the namespace’s total. Together they stop both the single giant disk and the swarm of tiny ones.
Per storage class quotas are one of the simplest ways to steer teams toward cheaper storage. Give the expensive class a small allowance and a visible reason to ask for more.
10Object Count Quotas
Some resources cost almost nothing to run but a great deal to track or to pay for.
Counting things instead of measuring them
A quota can also limit how many objects of a given kind a namespace may hold. Pods, services, secrets, configuration entries, and storage claims can all be counted. Newer versions of Kubernetes let you count almost any kind of object, including those from custom extensions, using a generic count syntax that names the resource and its group.
Why count objects
Protect the database
Every object is stored in the cluster’s database. Hundreds of thousands of configuration entries or secrets can slow down listing and watching operations for everyone.
Control cloud costs
Services of the load balancer type often create a paid cloud resource each. A quota that limits them to a small number prevents a costly surprise.
Limit scarce network resources
Services of the node port type use ports from a limited range shared by the whole cluster. Capping them prevents one team from exhausting the range.
Catch runaway automation
A buggy script that keeps creating jobs or pods in a loop is stopped at the count ceiling instead of flooding the cluster.
Tidy up after batch work
Finished job records pile up. A count limit encourages teams to clean up, or to use automatic cleanup settings for finished jobs.
Setting a count quota on pods also means the platform must leave room for rolling updates, jobs, and autoscaling, all of which temporarily create extra pods. A limit set exactly at current usage will block routine operations.
11Quota Scopes: Applying a Quota to a Slice of Pods
A scope narrows a quota so it only counts certain kinds of pods.
Why scopes exist
Not all pods are alike. Some run forever, like web servers. Some have a deadline, like batch jobs. Some are critical, and some are optional. Scopes let you give each category its own budget inside the same namespace.
Terminating
Matches pods that have a time limit set for how long they may run. Typical for batch work with a deadline.
NotTerminating
Matches pods with no time limit, meaning long running services.
BestEffort
Matches pods that declare no requests or limits at all. A quota with this scope can only cap the pod count, which is a clean way to ban or restrict them.
NotBestEffort
Matches pods that declare at least some requests or limits, and can cap their compute totals.
PriorityClass
Matches pods by their priority class through a selector, so critical pods and low priority pods get separate budgets.
CrossNamespacePodAffinity
Matches pods that ask to be placed near or away from pods in other namespaces, a feature that can leak information and is usually restricted.
A worked idea
Imagine a data team namespace. Long running services get a generous budget. Batch jobs with deadlines get a separate, smaller budget so a flood of jobs cannot crowd out the services. A third budget allows only a handful of pods that declare nothing. Each of these is the same kind of object with a different scope.
A household may have a separate grocery budget and an entertainment budget. Splitting the money by purpose stops a movie binge from eating into the food money.
Priority based quotas
Priority class scopes deserve a special note. Kubernetes lets pods carry a priority, and higher priority pods can push lower priority ones out of the way when room is short. Without limits, any team could simply label everything as the highest priority. A quota scoped to a high priority class lets the platform team hand out only a small number of high priority slots, and it can even restrict which namespaces may use a class at all.
Start without scopes. Add them only when you can name a real problem, such as batch work starving services, that a separate budget would solve.
12LimitRange Fields in Depth
A handful of fields control everything a limit range can do.
default
The limit applied to a container that does not declare its own. Despite the short name, this value is the default limit.
defaultRequest
The request applied to a container that does not declare its own request.
min
The smallest allowed value. A container that requests or limits below this is refused.
max
The largest allowed value. A container that requests or limits above this is refused.
maxLimitRequestRatio
The largest allowed gap between a limit and its request, expressed as a ratio. It prevents pods that request very little but are allowed to burst enormously.
Why the ratio matters
Imagine a container that requests a tiny amount of memory but has a huge limit. The scheduler believes it needs almost nothing and packs many such containers onto one machine. When they all grow toward their limits at the same time, the machine runs out of memory and containers are killed. A ratio cap, for example allowing the limit to be at most twice the request, keeps the gap between promise and possibility reasonable and the machine safer.
How defaults interact
Container declares nothing
Both the default request and the default limit from the limit range are added.
Container declares only a limit
The request is taken from the default request if one is set. Otherwise, the standard Kubernetes rule applies and the request becomes equal to the declared limit.
Container declares only a request
The limit is taken from the default limit if one is set. If no default exists, the container has a request but no limit and can burst upward.
Container declares both
Nothing is added. The declared values are checked against the minimum, maximum, and ratio.
Rules the limit range itself must obey
A limit range is validated when it is created. Its default values must fit between its own minimum and maximum, and its default request may not exceed its default limit. A limit range that contradicts itself is rejected, which prevents confusing situations later.
The field called default is the default limit, and the field called defaultRequest is the default request. Reading them quickly, many people swap the meaning and end up with surprising pods.
13How the Two Work Together
A short story shows the whole system in motion.
A day in a team namespace
The platform team has given the search team a namespace. It holds a quota on total requests and limits, and a limit range with sensible defaults and a maximum container size. A developer submits a new deployment without bothering to declare resources. Here is what happens.
sequenceDiagram
participant Dev as Developer
participant API as API server
participant LR as LimitRange
participant RQ as ResourceQuota
participant S as Scheduler
Dev->>API: Create deployment with no resources
API->>API: Controller asks for a pod
API->>LR: Check the pod
LR-->>API: Defaults added and sizes within range
API->>RQ: Would namespace stay within budget
RQ-->>API: Yes and used totals increase
API->>S: Pod saved and ready to schedule
S-->>Dev: Pod runs on a machine
When the budget runs out
Later the team scales the deployment up. The twelfth pod would push the namespace past its memory request budget. The quota check refuses the pod. The deployment itself was accepted, since a deployment object uses almost no resources, but its helper component, the replica set, cannot create the new pod. The deployment shows fewer ready pods than desired, and the explanation lives in the events of the replica set.
A hotel front desk applies a house rule that fills in the standard room type for guests who did not choose one, and also checks whether the company’s block of rooms still has space. The guest sees one smooth check in, while two different rules quietly cooperated.
Where people look and get confused
| What you check | What you see | Why |
|---|---|---|
| The deployment | Fewer ready replicas than desired, but no obvious error | The deployment object itself was accepted |
| The replica set | Events showing failed pod creation with a quota message | The replica set is the one that tried to create pods |
| The pod list | The missing pods are simply absent | Refused pods are never stored |
| The namespace quota | Used values close to or at the hard values | This confirms the cause |
When a deployment will not reach its desired count, look at the replica set events first. That is where quota and limit range refusals are written down.
14Gotchas: Rollouts, Autoscaling, and Jobs
Quotas interact with routine operations in ways that catch teams by surprise.
Rolling updates need headroom
When a deployment updates, Kubernetes by default starts some new pods before it removes the old ones. During that window the namespace holds extra pods, and every one of them counts against the quota. If a team has set the quota exactly equal to the steady state usage, the update cannot create its first new pod and the rollout stalls. Always leave room for the surge, or adjust the update strategy to remove old pods first.
Autoscalers hit the ceiling
A horizontal pod autoscaler decides how many copies are wanted based on load. If the quota blocks creation of the extra pods, the autoscaler keeps asking while the namespace cannot deliver. During a traffic spike, the application is stuck at the quota ceiling even though the autoscaler wants more. Quotas should be sized with the maximum autoscaling range in mind.
Jobs and finished pods
Finished pods do not count toward compute quota, but pod objects still exist until cleaned up. Count quotas on the number of jobs or other kinds of objects can still be consumed by old, finished records. Automatic cleanup of finished jobs keeps both the database and the quotas tidy.
Injected helper containers
Many platforms add helper containers to pods automatically, such as a networking proxy or a log collector. These are added before the quota check, so their requests count toward the namespace budget. A team may find its quota consumed faster than expected because every pod carries a hidden companion.
Slow accounting after changes
When a quota is first created or changed, a background controller needs a short time to calculate current usage. During that moment, creating objects can briefly be refused or the used numbers may look incomplete. This usually resolves within seconds.
Problem
A quota is set exactly at the namespace’s current usage, so a normal rolling update cannot create even one extra pod.
Why It’s Harmful
Deployments stall in the middle of an update, and engineers waste time looking for an application bug that does not exist.
Correct Approach
Set the quota above steady state usage by at least the surge capacity, and include autoscaling growth in the calculation.
15Choosing the Numbers
The hardest part of quotas is not the object, it is deciding what the numbers should be.
Start from evidence, not guesses
Setting quotas by gut feeling creates either wasted capacity or frustrated teams. A better approach is to look at what teams really use and add a comfortable margin. Monitoring tools show actual memory and processor use over weeks, and the gap between that and what teams request tells you how much slack is hidden in requests.
Measure current reality
Collect weeks of real usage and the declared requests per namespace, including peaks and the busiest time of the week.
Right size requests
Where requests are far above real usage, work with teams to lower them. Quota based on inflated requests wastes capacity for everyone.
Add headroom
Include room for rolling updates, autoscaling peaks, and growth over the next quarter.
Compare with cluster capacity
Decide consciously whether the sum of all quotas may exceed the real capacity of the cluster, and who gets priority if everyone demands their full share.
Review regularly
Revisit the numbers every quarter, because applications grow and teams change.
Using size tiers
Many platform teams avoid negotiating every namespace separately. They offer a small menu of standard sizes, in the style of small, medium, and large t-shirts, and let each team pick one. This keeps conversations simple and policies consistent.
| Tier | Typical use | What the quota covers |
|---|---|---|
| Small | Experiments, prototypes, learning environments | A few cores, a few gigabytes of memory, a handful of pods and services |
| Medium | One production service with a few components | Tens of cores, tens of gigabytes, moderate counts and storage |
| Large | A busy product team with many services | Hundreds of cores, hundreds of gigabytes, larger counts, several storage classes |
| Special | Needs outside the menu, such as specialized hardware | Custom values agreed through a short request process |
Overcommitting the cluster on purpose
The sum of all quotas is allowed to be larger than the real cluster. This is called overcommitment and it is common, because teams rarely use all of their allowance at once. The trade-off is that on a busy day, whichever team asks first gets the machines, and a team that is still within quota can still find its pods waiting. Decide how much overcommitment you accept, and use priorities and autoscaling of the cluster itself to soften the impact.
Quota stops a team from taking too much. It does not guarantee that enough machines exist. Capacity planning and cluster scaling are separate jobs that quotas support but do not replace.
16Security and Multi-Tenancy
Resource controls are one layer of keeping tenants safe from each other.
Availability is a security property
A denial of service does not always come from an attacker. A single compromised or buggy workload that grabs unbounded memory or creates endless objects can take down neighbors just as effectively. Quotas and limit ranges limit the damage any single namespace can do, which makes them an important part of the defense.
Who may change the rules
The tenant should not be able to remove their own limits. Permission to create, edit, or delete quota and limit range objects should belong only to the platform team. If a team can edit its own quota, the quota is a suggestion and not a control. Use access control rules to grant teams read access to see their usage, but not write access.
Combine with other protections
Access control
Decides who can do what in each namespace, including who may edit quotas.
Network policies
Control which pods may talk to which, limiting the spread of any problem.
Pod security settings
Prevent privileged containers and dangerous host access.
Quotas and limit ranges
Cap how much any tenant can consume and how large any single piece can be.
Policy checks
Reject objects that break company rules before they are stored, including missing labels or forbidden settings.
Protecting the control plane itself
Object count quotas protect the cluster’s database and API server from being overloaded by huge numbers of small objects. A malicious or accidental flood of secrets or configuration entries stops at the count ceiling. For this reason, many hardened setups apply count limits even on namespaces where compute is plentiful.
Create the quota and limit range as part of the same automated process that creates the namespace, so no namespace ever exists without its guardrails, even for a single hour.
17Monitoring and Alerting
A quota that nobody watches turns into a surprise outage.
Reading usage directly
The simplest tool is to describe the quota object. The output lists every resource with its used amount and its hard maximum side by side. This is the first thing to check when a team reports that their pods are not appearing.
Metrics for dashboards and alerts
The common cluster state metrics exporter publishes the used and hard values of every quota as metrics, along with the same for limit ranges. Dashboards can chart used divided by hard for each namespace, and alerts can fire before a team hits the wall.
Quota utilization
Used divided by hard for each resource. Alert when it passes a threshold such as eighty or ninety percent.
Creation failures
Events that mention exceeded quota or forbidden creation. A spike indicates a team is already blocked.
Pending pods
Pods waiting for a machine, which points to cluster capacity problems rather than quota.
Request versus real use
The gap between what pods request and what they actually consume. A large gap means quota is wasted on inflated requests.
Evictions and memory kills
Pods killed for exceeding memory or evicted by the machine. These suggest limits or requests that are too low or poorly matched.
CPU throttling
How often containers hit their processor limit and are slowed. Persistent throttling suggests limits are too tight.
Two audiences, two views
Platform teams want a cluster wide view: which namespaces are near their ceilings, how much total quota has been promised compared with real capacity, and which teams hold the most unused allocation. Application teams want a view of their own namespace: how much room remains and how it compares with their real usage. Giving both groups a dashboard reduces support requests.
Alerting etiquette
Warn teams early at a moderate threshold and escalate at a higher one. A quota alert at ninety nine percent is too late to act on. Also avoid alerts that fire constantly, because people stop reading them. Tie alerts to a clear next step, such as requesting more quota or right sizing requests.
Tools that recommend request values from observed usage can reduce wasted allocation. Treat their output as input to a human decision, especially for workloads with rare but important traffic peaks.
18Reading Error Messages and Troubleshooting
The error messages are very clear once you know their shape.
Typical messages and what they mean
| Message theme | Meaning | Typical fix |
|---|---|---|
| Must specify requests or limits for a resource | A quota covers that resource, and the pod did not declare it, with no default available | Add values to the pod or add a limit range with defaults |
| Exceeded quota with requested, used, and limited numbers | The new pod would take the namespace over its budget | Free up usage, right size requests, or request a higher quota |
| Maximum usage per container is smaller than the limit | The container asks for more than the limit range allows | Lower the container’s values or ask for a larger maximum |
| Minimum usage per container is larger than the request | The container asks for less than the allowed minimum | Raise the container’s values to at least the minimum |
| Limit to request ratio is too large | The gap between limit and request exceeds the allowed ratio | Bring the request closer to the limit |
| Forbidden to create more of an object type | A count quota for that object type is exhausted | Delete unused objects or raise the count |
A calm routine
Find the right object’s events
Check events on the deployment’s replica set, or on the job, because that controller tried to create the pod and recorded the refusal.
Read the numbers in the message
Quota messages list what was requested, what is used, and what the limit is. The arithmetic usually reveals the cause immediately.
Describe the quota and limit range
See current usage and the exact rules in force for the namespace.
Decide the right remedy
Choose between lowering the demand, freeing room, or raising the budget, and involve the platform team only if a raise is justified.
Other puzzling situations
Pods are pending, not refused
The pod passed all admission checks but no machine has room. This is a cluster capacity problem, not a quota problem.
New defaults are not applied to old pods
A limit range affects only new pods. Existing pods keep whatever they had until they are recreated, for example by restarting a deployment.
Two limit ranges disagree
When several limit ranges exist in the same namespace, which default is applied is not predictable. Keep exactly one limit range per namespace.
Quota usage looks stale
Usage is recalculated by a background process. After large changes, wait a short time, and if the numbers still look wrong, investigate leftover objects.
19Real-World Usage Patterns
These setups appear again and again in companies that run shared clusters.
Team namespaces with standard tiers
A platform team creates every team namespace from a template that includes a size tier, a limit range with defaults, and access rules. New teams get working guardrails on day one.
Environment based budgets
Development namespaces get small quotas and low maximums, since they run many short experiments. Production namespaces get larger quotas with stricter ratios, so workloads behave predictably.
Cost showback and chargeback
Because quotas and requests are per namespace, finance teams can attribute spending to teams by reading requested resources. Namespaces that hold large unused quotas become visible, which encourages cleanup.
Protecting shared services
Namespaces that host shared tools such as monitoring or logging receive priority scoped quotas, so critical platform pods always have room even when application teams are busy.
Batch and interactive separation
Data teams use scoped quotas to separate deadline driven batch pods from always running services, so a large batch run cannot starve a dashboard that people are watching.
Training and demo clusters
Workshops use tight count quotas and small compute budgets per student namespace, so one learner’s mistake never affects the rest of the room.
Multi-customer platforms
Software providers that run each customer in its own namespace use quotas to guarantee fairness between customers and to tie the allowance to the customer’s pricing plan.
Beyond the built-in tools
The built-in quota object is namespace scoped. Organizations that want a quota spanning several namespaces, or a queue that shares unused capacity between teams, often add extra tools. Examples include batch queueing systems and multi-tenancy frameworks. These build on the same concepts of requests, limits, and fair sharing, so the ideas in this tutorial carry over directly.
20Design Patterns That Work
Teams that run shared clusters calmly tend to follow these habits.
Pair every quota with a limit range
Defaults keep deployments working under a quota, and size caps stop any one piece from dominating.
Automate namespace creation
Create the namespace, quota, limit range, and access rules together from one template or pipeline.
Offer size tiers
A small menu of standard sizes keeps policy consistent and conversations short.
Alert before the wall
Warn at moderate utilization so teams can act before they are blocked.
Right size continuously
Review requests against real use regularly so that quota is spent on actual need.
Keep rules in version control
Store quotas and limit ranges as files, reviewed and tracked like application code, so changes have an owner and a history.
One limit range per namespace
A single, clear set of defaults avoids unpredictable behavior from conflicting rules.
Patterns to avoid
Problem
A quota is added to an existing busy namespace with no limit range and no warning to the teams.
Why It’s Harmful
Every deployment that omits resource values is suddenly refused, causing confusing failures and rushed escalations.
Correct Approach
Introduce the limit range first, announce the change, and then add the quota with comfortable headroom.
Problem
Default values in the limit range are set very high so that nobody ever gets refused.
Why It’s Harmful
Every careless pod claims a large share of the budget, the quota fills up quickly, and real capacity is wasted on resources nobody uses.
Correct Approach
Set defaults to modest values that fit a typical small service, and let teams ask for more deliberately.
Problem
Tenants hold permission to edit or delete their own quota and limit range objects.
Why It’s Harmful
The guardrails become optional. Any frustrated engineer can remove them, and the control gives a false sense of safety.
Correct Approach
Restrict write access to the platform team and give tenants read access plus a clear request process.
Problem
Quotas are set once and never reviewed, and nobody watches utilization.
Why It’s Harmful
Teams discover the ceiling in the middle of an incident or a launch, and unused allocations from retired projects hold capacity hostage.
Correct Approach
Dashboard and alert on utilization, and review the numbers every quarter.
Problem
Limits are copied from one app to every other app, regardless of how each one behaves.
Why It’s Harmful
Some apps are starved and throttled or killed, while others hold far more than they need, so both stability and cost suffer.
Correct Approach
Base each workload’s requests and limits on its own measured behavior, and use namespace defaults only as a safety net.
21Advantages, Limitations, and Best Practices
An honest balance helps you set the right expectations.
Advantages
- Stops one namespace from starving the rest of the cluster.
- Turns surprise cloud bills into bounded, predictable costs.
- Protects the control plane from floods of small objects.
- Limit ranges save developers from writing resource settings for every container.
- Built into Kubernetes, with nothing extra to install.
- Gives platform teams a simple vocabulary for capacity conversations, such as tiers.
Disadvantages / Trade-offs
- Quotas count declared values, not real usage, so inflated requests waste budget.
- Quotas do not guarantee capacity, and overcommitted clusters can still run short.
- Namespace boundaries only, with no built-in quota across several namespaces.
- Added friction for teams, including refused pods and the need for headroom planning.
- Limit ranges apply only to new pods, so older workloads are unaffected until recreated.
A practical checklist
Define tiers and defaults
Agree on a small set of sizes and sensible default requests and limits before creating any namespace.
Create the limit range first
Make sure defaults exist before any compute quota is added.
Add quotas with headroom
Include space for rolling updates, autoscaling, and growth, and cap object counts that protect the control plane.
Lock down who can change them
Give write access only to the platform team.
Observe and alert
Chart utilization per namespace and alert before teams are blocked.
Right size and review
Compare requests with real use each quarter and adjust numbers and tiers accordingly.
Adding a quota without a limit range, setting a quota with no room for rolling updates, mixing up the meaning of default and defaultRequest, confusing memory unit suffixes, and forgetting that existing pods are not changed by new rules.
22Frequently Asked Questions
No. A ResourceQuota caps the total a whole namespace may use. A LimitRange sets the size rules and defaults for each individual container, pod, or storage claim. They solve different problems and work best together.
Either the namespace has a compute quota and your pod did not declare the required requests or limits, or the namespace is simply near its ceiling. The error message states which one, with the numbers.
No. Quotas and limit ranges are checked when objects are created or changed. Existing pods keep running even if the new rules would have refused them.
Look at the events of the replica set that belongs to the deployment. The refusal is recorded there because the replica set is the one that tried and failed to create the pods.
No. A quota is only a ceiling. Machines are not set aside. If the cluster lacks capacity, pods can wait even when you are within your quota.
The request normally defaults to the same value as the limit, unless a limit range supplies a default request. The result is often a pod in the Guaranteed class if all other values match.
Yes, and all of them must be satisfied. This is how scoped quotas work, for example one for long running pods and another for batch pods. Multiple limit ranges are allowed but discouraged, because default selection becomes unpredictable.
Finished pods stop counting toward compute and pod count quotas, but the job and pod records may still count toward object count quotas until they are cleaned up. Use automatic cleanup for finished jobs.
Updates briefly run extra pods. Those pods count toward the quota, so if there is no headroom, the update cannot start new pods. Leave room for the surge or change the update strategy.
Opinions differ, because CPU limits cause throttling even when the machine has spare power. Many teams set accurate CPU requests and memory limits, and skip CPU limits. Note that a quota that caps total limits for CPU will require every pod to declare a CPU limit, so choose your policy deliberately.
The built-in object works within one namespace. Cross namespace budgets need extra tools or an organizational process that divides one large budget among several namespace level quotas.
Defaults are added only when a pod is created. Restart or redeploy the workload so its pods are recreated and pick up the new values.
23Summary and Key Takeaways
Resource quotas and limit ranges are the quiet house rules that make shared Kubernetes clusters livable. A ResourceQuota gives each namespace a budget for compute, storage, and object counts, so no single team can starve the others or run up a surprise bill. A LimitRange defines how big any single piece may be and fills in sensible defaults, so developers are not forced to hand write resource settings and no one container can dominate. Both act at admission time, defaults first and the quota check last, which means refused requests fail fast and clearly. Used together with access control, monitoring, and a habit of right sizing, they give platform teams a fair, predictable, and affordable foundation. Used carelessly, they cause confusing refusals and stalled rollouts. The difference lies in pairing them, leaving headroom, watching utilization, and keeping the numbers grounded in real usage.
Key Takeaways
- Quota is the namespace budget, limit range is the item rule — one caps the total, the other sets minimum, maximum, ratio, and default sizes for each container, pod, or storage claim.
- They act at admission — defaults and size checks run first, the quota check runs last, and refused objects are never stored, so look at replica set events when pods go missing.
- Compute quotas demand declared values — pods that omit requests or limits are refused unless a limit range provides defaults, so create the limit range first.
- Count quotas protect cost and the control plane — cap load balancers, node ports, secrets, and other objects to avoid bills and database overload.
- Leave headroom — rolling updates, autoscaling, and injected helper containers all consume quota, and a ceiling set exactly at current usage will stall routine work.
- Quota is a ceiling, not a reservation — it counts declared values rather than real usage and does not guarantee machines, so pair it with right sizing and capacity planning.
- Lock down and observe — only the platform team should edit these objects, and utilization should be charted and alerted per namespace before teams hit the wall.