What Does Resource Quotas Mean?
Also known as: Resource Quotas, Kubernetes resource quotas, CKA resource management, namespace quotas, Kubernetes quotas explained
On This Page
Quick Definition
Resource Quotas are like spending limits for a group of projects in a shared office. In Kubernetes, a cluster has a fixed amount of CPU and memory. Resource Quotas let an administrator set caps on how much of those resources a specific team or project (called a namespace) can use. This prevents one team from accidentally taking resources away from others and keeps the whole system running fairly.
Must Know for Exams
The CKA (Certified Kubernetes Administrator) exam includes a dedicated domain called Workloads and Scheduling, which accounts for about 15% of the exam. Within that domain, Resource Quotas appear as part of cluster governance and resource management. You may be asked to create, modify, and verify Resource Quotas from the command line using kubectl.
For example, an exam scenario might describe a namespace that is consuming too many resources and ask you to set a quota of 2 CPUs and 4Gi memory so that the namespace cannot exceed those limits. The exam tests your ability to write the correct YAML manifest for a ResourceQuota object and apply it. You must know the exact API version, kind, and fields.
For CKA, v1 is the correct API version. You also need to understand the difference between spec.hard and spec.scopeSelector. Some questions ask you to create a quota that only applies to BestEffort pods, meaning pods without any resource requests or limits.
This tests your knowledge of quality of service classes in Kubernetes. The exam expects you to know how to inspect current quota usage using kubectl describe quota or kubectl get quota. You might also need to troubleshoot why a pod cannot be created in a namespace, and the answer might involve checking if a quota has been exhausted.
The CKA is a hands-on performance-based exam, so you will use the terminal for all tasks. There are no multiple-choice questions. Therefore, you must be comfortable writing YAML from memory and applying it with kubectl.
Resource Quotas also appear in the context of multi-tenancy, which is a theme in the CKA curriculum. You may be asked to design a solution where multiple teams share a cluster while being isolated by namespaces and quotas. The exam question might provide a scenario: team A needs 4 CPUs and 8Gi memory, team B needs 2 CPUs and 4Gi memory.
You must create two quotas in two namespaces that enforce these limits. Do not confuse Resource Quotas with LimitRanges. LimitRanges define minimum and maximum per container, while quotas define aggregate limits per namespace.
The exam sometimes tests this distinction by asking you to create a LimitRange in addition to a ResourceQuota for a given namespace. To perform well, practice writing the YAML for ResourceQuota from scratch, including all common resource fields like requests.cpu, requests.
memory, limits.cpu, limits.memory, and count resources like pods. Also practice using the --dry-run=client -o yaml flag to generate YAML quickly during the exam.
Simple Meaning
Imagine you are moving into a new apartment building where each floor shares a single water tank. The building manager needs to make sure no single floor uses all the hot water, leaving others cold. To solve this, the manager installs a separate meter on each floor and says, no floor can use more than 100 gallons of hot water per day.
Resource Quotas work exactly like those meters but for a Kubernetes cluster. A Kubernetes cluster is a group of computers (called nodes) that work together to run applications. Inside the cluster, teams often share the same pool of processing power (CPU) and memory (RAM).
Without limits, one team could run a huge application that hogs all the CPU and memory. That would starve other teams applications, causing them to crash or run very slowly. Resource Quotas allow the cluster administrator to say, this team can use at most 10 CPUs and 20 gigabytes of memory total.
Once the team hits that limit, Kubernetes will not allow new applications to start until the team removes some old ones. You can think of it like a group of friends sharing a pizza. If you say everyone can have at most two slices, no one person can eat the whole pizza.
Similarly, Resource Quotas ensure fair sharing of the cluster s resources. They apply per namespace, which is like a virtual fence that separates one team s work from another. Inside a namespace, a quota can limit not just CPU and memory but also the number of objects like pods or services that can be created.
This prevents a buggy script from accidentally creating thousands of useless objects and overwhelming the system. Resource Quotas are a fundamental tool for multi-tenant clusters where many different teams or applications coexist. They give administrators a way to manage capacity, enforce fairness, and protect the stability of the entire cluster.
Without quotas, a single misbehaving application could bring down everyone else s work.
Full Technical Definition
Resource Quotas are a Kubernetes admission control mechanism that enforces aggregate resource consumption limits within a namespace. The Kubernetes API Server validates every resource creation or update request against any applicable ResourceQuota objects before the request is persisted to etcd. If the requested operation would cause the namespace to exceed its defined quota, the API Server rejects the request with a 403 Forbidden status, and the resource is not created.
A ResourceQuota object is defined in YAML or JSON and specifies one or more hard limits. The most common resource types that can be limited are requests.cpu, requests.memory, limits.
cpu, and limits.memory. Requests refer to the minimum amount of resource guaranteed to a container, while limits are the maximum a container is allowed to burst to. Quotas can also apply to count-based resources such as pods, services, persistentvolumeclaims, configmaps, and secrets.
For example, you can set a quota limiting a namespace to 50 pods total. When a user tries to create the 51st pod, the API server will deny the request. Resource Quotas operate on the total sum of resource requests and limits across all containers in the namespace.
If a namespace has a quota of 10 CPUs for requests, and you create five pods each requesting 2 CPUs, the quota is fully consumed, and no further pods can be created until some are deleted or the quota is increased. Quotas are enforced at admission time, meaning the check happens before the object is scheduled or run. This differs from LimitRanges, which enforce per-container or per-pod minimum and maximum values.
Resource Quotas are typically used in multi-tenant clusters where different teams, projects, or environments share the same Kubernetes infrastructure. They help prevent resource starvation, noisy neighbor problems, and runaway cost. Advanced usage includes scoping quotas with label selectors using the scopeSelector field.
For instance, you can create a quota that only applies to pods in the BestEffort quality of service class, or only to pods that match a specific priority class. Kubernetes also supports ResourceQuota for extended resources such as GPUs or custom device plugins. It is important to note that Resource Quotas do not replace per-container resource limits defined in Pod specs.
They are a higher-level governance tool. To implement quotas effectively, cluster administrators should ensure that all pods in a quota-controlled namespace specify resource requests and limits. If a pod omits requests, the API server will reject the pod creation if the quota requires those fields to be specified.
This behavior can be configured using the .spec.scopeSelector or by configuring the ResourceQuota with the .spec.hard that includes resource types that are mandatory. Monitoring quota usage is done via the kubectl describe resourcequota command, which shows the current usage and the hard limit for each resource type.
Alerts can be set up using Prometheus metrics exposed by the kube-apiserver and kube-state-metrics. The Kubernetes scheduler also uses quota information indirectly because it will not schedule pods that cannot be created. Producers of shared clusters should regularly audit quota usage to identify namespaces that are nearing their limits and adjust capacity planning accordingly.
Resource Quotas are a critical component of Kubernetes resource management and a must-know for the CNCF CKA certification.
Real-Life Example
Think of a public library with a central book collection. The library has a finite number of shelves and a limited budget to buy new books. Now imagine the library decides to allow different groups to borrow books for their own meetings.
One group is the children s story hour, another is the adult book club, and a third is the local history society. Without any limits, the history society could borrow all the history books, leaving none for the children s group learning about dinosaurs. The library manager would be unhappy.
To solve this, the manager sets borrowing quotas. Each group can borrow at most 20 books at a time. The children s group gets a quota of 20 children s books, the book club gets a quota of 20 fiction books, and the history society gets 20 history books.
Now, when the history society returns 5 books, they can borrow 5 more, but they can never exceed 20. This is exactly how Resource Quotas work in Kubernetes. The library is the Kubernetes cluster.
The three groups are namespaces. The books are resources like CPU and memory. The borrowing limit of 20 books corresponds to the hard limit defined in a ResourceQuota object. If the history society tries to borrow a 21st book, the librarian (the API server) says no until they return one.
In Kubernetes, the librarian says no to starting a new pod until you delete an old one. The library also has a rule that each group can only borrow a maximum of 10 books in a single checkout session, similar to limiting how many pods can be created at once. The library keeps a ledger that shows how many books each group currently has.
The administrator can look at the ledger (kubectl describe resourcequota) to see if a group is close to its limit and plan whether to raise the limit or advise the group to return books. This analogy helps you see that Resource Quotas are about fairness and protection, not about individual borrowing behavior.
Why This Term Matters
In real IT environments, shared infrastructure is the norm. Whether you work at a startup with one Kubernetes cluster or a large enterprise with dozens, multiple teams often use the same cluster. Without Resource Quotas, a single deployment that has a memory leak or a poorly configured application can consume all available CPU and memory, effectively denying service to other applications.
This creates a noisy neighbor problem where one misbehaving pod degrades performance for everyone. Resource Quotas prevent this by capping the total resources any namespace can consume. This is crucial for production clusters that host customer-facing applications because downtime caused by resource starvation leads to lost revenue and damaged reputation.
From a financial perspective, cloud resources cost money. If teams can spin up unlimited pods without quotas, cloud bills can spiral out of control. Resource Quotas enable cost governance by enforcing budget limits at the namespace level.
You can tie quotas to spending limits, making each team responsible for their own consumption. This also helps capacity planning. If you know namespace A is allowed 10 CPUs and it is consistently using 9, you can proactively allocate more nodes to the cluster before performance degrades.
Security is another dimension. A malicious user who gains access to a cluster without quotas could launch a resource exhaustion attack by creating thousands of CPU-intensive pods. Quotas mitigate this by limiting the blast radius.
For compliance, quotas can be part of a broader governance strategy, ensuring that workloads do not exceed agreed resource allocations. In day-to-day operations, administrators use quotas to enforce policy. For example, you can set a quota of 0 for a namespace to freeze deployments during a maintenance window.
You can also resize quotas dynamically without restarting workloads, which gives flexibility. Kubernetes itself exposes quota usage through metrics, which can feed into dashboards and alerting systems. Understanding Resource Quotas is therefore essential for any Kubernetes administrator, especially for those pursuing the CKA certification.
How It Appears in Exam Questions
Exam questions about Resource Quotas usually fall into four categories: scenario-based creation questions, troubleshooting questions, configuration verification questions, and comparative questions. In scenario-based creation questions, the exam presents a narrative. For example: You are the administrator of a shared Kubernetes cluster.
The finance team has a namespace called finance. They are deploying a critical payment processing application. To prevent resource exhaustion, create a ResourceQuota named finance-quota in the finance namespace that limits total CPU requests to 4 cores and total memory requests to 8Gi.
Also allow a maximum of 10 pods. You must write the YAML and apply it. This tests your knowledge of the syntax and fields. Troubleshooting questions describe a situation where a user reports they cannot deploy a new pod in a namespace.
You must examine the namespace and identify that a ResourceQuota has been exhausted. For example, the question might say: A user in the development namespace tries to create a pod with a resource request of 1 CPU and 2Gi memory, but the pod creation fails. The namespace already has a quota of 2 CPUs and 4Gi memory.
Currently, 3 pods are running, consuming 1.5 CPUs and 3Gi memory. Explain why the new pod cannot be created and correct the mismatch. The answer requires you to calculate the available resources.
Often, the failure is because the sum of existing usage plus the new request would exceed the quota. You would then need to either delete an existing pod, increase the quota, or reduce the new pod s resource requests. Configuration verification questions ask you to use kubectl get quota or kubectl describe quota to retrieve the current usage and hard limits of a given namespace and report whether the namespace is compliant with a policy.
You might be asked to set up a cronjob or script that emails the admin when a namespace reaches 80% of its quota. This tests your understanding of how to extract quota metrics programmatically. Comparative questions present two namespaces with different quotas and ask you to explain the difference in behavior.
For example, namespace A has a quota for CPU and memory but not for pods. Namespace B has a quota for pods but not for CPU or memory. You might be asked which namespace allows unlimited pods or unlimited CPU.
The answer is that namespace A limits CPU and memory but allows unlimited pods, while namespace B limits pods but allows unlimited CPU and memory. This tests conceptual understanding. Another pattern appears in multi-part questions where you are asked to create a namespace, then create a ResourceQuota in that namespace, then create a deployment that respects the quota, and finally verify that the deployment is running.
This simulates real workflow and is common in the CKA. Overall, expect to use kubectl, write YAML, and reason about resource consumption.
Study cncf-cka
Test your understanding with exam-style practice questions.
Example Scenario
You are a cluster administrator at a medium-sized company. The company has two teams: the frontend team and the backend team. They share a single Kubernetes cluster. Last week, the backend team deployed a machine learning model that used 8 CPUs and 32Gi of memory.
This caused the frontend team s web server pods to crash because the cluster ran out of memory. The company CTO is not happy. You decide to implement Resource Quotas. You create two namespaces: frontend-ns and backend-ns.
In the frontend namespace, you apply a ResourceQuota that limits CPU requests to 4 cores, memory requests to 8Gi, and the number of pods to 20. In the backend namespace, you apply a quota that limits CPU requests to 6 cores, memory requests to 16Gi, and pods to 10. Now, if the backend team tries to deploy a pod that requests 10 CPUs, the Kubernetes API server will reject it because that alone would exceed the 6 CPU quota for the namespace.
The backend team must either reduce the pod s resource requests or delete other pods. The frontend team is now protected because the backend team cannot monopolize resources. This example shows how Resource Quotas enforce fairness and prevent one team from crashing another s applications.
Common Mistakes
Thinking that Resource Quotas limit resources per pod or per container
Resource Quotas are aggregate limits for an entire namespace, not per individual pod. Setting a quota of 2 CPUs means the sum of all pod requests in the namespace cannot exceed 2 CPUs, not that each pod is limited to 2 CPUs.
Remember that quotas apply to the sum of all pods in the namespace. Use LimitRanges if you need to set per-pod or per-container min/max values.
Forgetting to set both requests and limits in the quota
If you only set limits.cpu in the quota but pods only specify requests.cpu, the quota will not track those requests. Kubernetes will allow pods that do not specify the tracked resource type, leading to inconsistent enforcement.
Always include both requests and limits for CPU and memory in your ResourceQuota spec, unless you have a specific reason not to.
Believing that Resource Quotas prevent existing pods from exceeding the quota
Resource Quotas are enforced at admission time, meaning they only block new resource creation. If a quota is reduced after pods are running, those pods continue to consume resources even if they exceed the new limit. The quota only prevents new pods from being created.
To enforce stricter limits on running pods, you must delete or scale down existing pods to comply with the new quota.
Confusing Resource Quotas with namespace resource limits from cloud providers
Cloud providers have their own resource limits at the account or project level, such as AWS service quotas or Azure subscription limits. Kubernetes Resource Quotas are separate and only affect the Kubernetes cluster itself.
Understand that Kubernetes quotas are for cluster resource governance, while cloud provider quotas are for API rate limits or service usage in the cloud account.
Assuming that creating a ResourceQuota automatically sets resource requests on all pods
Resource Quotas do not inject resource requests or limits into pod specs. If a pod s spec does not include resource requests, and the quota requires tracking requests.cpu, the API server will reject the pod creation. But the quota does not modify the pod.
Ensure that all pods in a namespace with a quota include appropriate resource requests and limits in their YAML spec.
Exam Trap — Don't Get Fooled
On the CKA exam, you might be asked to create a ResourceQuota that only applies to pods of a specific quality of service class, such as BestEffort. Many learners write a quota with hard limits for CPU and memory without using the scopeSelector field, thinking it will only apply to those pods, but it actually applies to all pods in the namespace. Read the question thoroughly. If it says apply only to BestEffort pods or pods with priority class, you must include the spec.scopeSelector section in your YAML. For BestEffort, use a scope like this:
scopeSelector: matchExpressions: - key: qos-class operator: In values: - BestEffort
Then define the hard limits. Practice writing this YAML before the exam. Also, test your quota with kubectl describe quota after applying it to verify the scope is correct.
Commonly Confused With
LimitRanges set minimum and maximum resource constraints per container or per pod within a namespace. Resource Quotas set aggregate limits for the entire namespace. A LimitRange says a single container cannot request more than 2 CPUs, but a ResourceQuota says the sum of all containers cannot exceed 10 CPUs.
If you have a LimitRange with max CPU of 2 per container, you can create 10 containers each using 2 CPUs. But if you also have a ResourceQuota of 10 CPUs total, the 11th container would be denied even though each container is under the LimitRange max.
Pod Priority determines which pods get scheduled first when resources are scarce, and it allows higher-priority pods to evict lower-priority pods. Resource Quotas are a hard cap that prevents any pod from being created if the namespace total would exceed the cap, regardless of priority.
A high-priority pod that would exceed the namespace s memory quota will still be rejected by the ResourceQuota. Pod Priority does not bypass the quota limit.
A namespace is a virtual cluster inside a Kubernetes cluster that provides scope for resource names. Resource Quotas are objects that live within a namespace and enforce limits on that namespace. You can have many namespaces without any quotas, but a quota always belongs to exactly one namespace.
Think of namespaces as separate folders on your computer. Resource Quotas are the size limits you set for each folder. The folder itself is just a container; the quota controls how much total data can be in that folder.
Step-by-Step Breakdown
Understand the namespace boundaries
Resource Quotas are tied to a single namespace. Before creating a quota, identify which namespace you want to limit. All resources created in that namespace will count toward the quota.
Determine the resources to limit
Decide whether to limit compute resources (CPU and memory requests and limits) or count-based resources (pods, services, PVCs). You can limit both. Write down the hard limits as numbers.
Create a ResourceQuota YAML manifest
Use the apiVersion v1 and kind ResourceQuota. Under spec.hard, list the resource type as the key and the limit as the value, for example requests.cpu: 4 and pods: 10. Save the YAML file.
Apply the ResourceQuota to the namespace
Use kubectl apply -f quota.yaml to create the quota. The API server validates the YAML syntax and stores the quota in etcd. The quota starts tracking all existing resources in the namespace immediately.
Verify the quota
Run kubectl get resourcequota -n <namespace> to see the quota. Use kubectl describe resourcequota <quota-name> -n <namespace> to see current usage and hard limits. Confirm that the used values match your expectations.
Test the quota enforcement
Try to create a pod that would exceed the quota. For example, if your quota allows 4 CPUs and you already have 3 used, try to create a pod requesting 2 CPUs. The API server should reject it with an error message like exceeded quota.
Monitor and adjust quotas over time
Use kubectl describe resourcequota regularly to track usage trends. Increase quotas if a team needs more resources, or decrease them if they are underutilized. Alter the YAML and reapply it to update the quota.
Practical Mini-Lesson
Resource Quotas are a day-two operation tool meaning they matter most after the cluster is already running. As a Kubernetes administrator, your job is not just to set them up but to monitor and adjust them as workloads change. Start by auditing your cluster.
Determine how many namespaces you have and what workloads run in each. Interview each team to understand their expected resource consumption. For a typical web application, you might allocate 1 CPU and 2Gi memory per replica, with 3 replicas, so you need a quota of at least 3 CPU and 6Gi memory.
Always over-provision slightly to allow for spikes, but not so much that one team wastes resources. When configuring quotas, you must decide which resource types to include. The most important are requests.
cpu and requests.memory because they represent guaranteed resources. If you only set limits.cpu, a pod with a huge limit but zero request will not count against the quota, which defeats the purpose.
A good practice is to include both requests and limits for CPU and memory, plus pods to prevent pod count explosions. Also consider including count resources like persistentvolumeclaims to limit storage usage. In a multi-tenant cluster, use a combination of ResourceQuotas and LimitRanges.
The LimitRange ensures that no single pod can request an unreasonable amount, while the Quota ensures that the sum across all pods stays within budget. For example, set a LimitRange with max CPU 4 and a ResourceQuota with 10 CPUs total. Then a single pod cannot take more than 4, and the whole namespace cannot exceed 10.
When a quota is full, new pods will fail to start. This is a feature, not a bug. It forces teams to clean up old or unused pods. You should communicate this expectation to developers so they know to delete stale pods.
You can automate cleanup with tools like kube-resource-reporter or custom scripts that delete pods beyond a certain age. In production, set up alerts for quota usage. Use Prometheus queries like kube_resourcequota{type="used"} to track consumption.
When usage reaches 80% of the hard limit, notify the team so they can request a quota increase before hitting the wall. Also, when you need to perform a cluster maintenance, you can temporarily set a quota of 0 pods in a namespace to stop any new deployments. This is a quick way to freeze a namespace without deleting existing pods.
Remember that Resource Quotas do not delete running pods when the quota is reduced. If you reduce a quota from 10 CPUs to 5, and 7 CPUs are already in use, the excess is allowed to continue running. But you will not be able to create any new pods until usage drops below 5.
Therefore, plan quota changes carefully and coordinate with teams. In summary, Resource Quotas give you control over resource distribution, enable fair sharing, and help you avoid runaway costs. Master the YAML syntax, practice with kubectl, and always think in terms of aggregate namespace totals.
Memory Tip
Remember the phrase QAP: Quota is Aggregate, Pod is per container, LimitRange is per entity. When you see resource limits on the exam, first ask yourself is this an aggregate (Quota) or per unit (LimitRange).
Covered in These Exams
Related Glossary Terms
A 2-in-1 laptop is a portable computer that can switch between a traditional laptop form and a tablet form, usually by detaching or rotating the keyboard.
The 24-pin motherboard connector is the main power cable that connects the computer's power supply unit (PSU) to the motherboard, supplying electricity to the motherboard and its components.
Two-factor authentication (2FA) is a security method that requires two different types of proof before granting access to an account or system.
32-bit File Allocation Table (FAT32) is a file system that organizes data on storage devices like hard drives and USB flash drives using a 32-bit addressing scheme to track where files are stored.
A 3D printer is a device that creates physical objects by depositing layers of material based on a digital model.
5G is the fifth generation of cellular network technology, designed to deliver faster speeds, lower latency, and support for many more connected devices than previous generations.
The 8-pin CPU connector is a power cable from the power supply that delivers dedicated electricity to the processor on a computer's motherboard.
802.1Q is the networking standard that allows multiple virtual LANs (VLANs) to share a single physical network link by tagging Ethernet frames with VLAN identification information.
Frequently Asked Questions
Can Resource Quotas be applied to a specific set of pods within a namespace?
Yes, using the scopeSelector field. You can create a quota that only applies to pods with a specific quality of service class, priority class, or other label expressions. However, by default, a quota applies to all pods in the namespace.
What happens if I reduce a ResourceQuota while pods are running that exceed the new limit?
The running pods are not affected. They continue to run and consume resources. However, no new pods can be created until the total usage in the namespace drops below the new hard limit. To enforce the new limit, you must manually delete or scale down existing pods.
Can I set a ResourceQuota to zero to block all new resource creation in a namespace?
Yes. Setting the pod count to zero will prevent any new pods from being created. This is useful for freezing a namespace during maintenance or for disabling a team that has overspent. Existing pods continue to run.
Are Resource Quotas enforced for DaemonSets or StatefulSets?
Yes, because they ultimately create pods. Each pod created by a DaemonSet or StatefulSet is counted against the namespace s Pod quota and resource quotas. If the quota is exhausted, the controller will not be able to create new pods until the usage drops.
Do Resource Quotas affect system pods like kube-proxy or coredns?
System pods are typically created in the kube-system namespace. If you apply a ResourceQuota to kube-system, it would affect those pods. However, it is generally not recommended to restrict system pods because it can destabilize the cluster. Leave the kube-system namespace unquotaed or use very high limits.
Can I use Resource Quotas to limit storage usage?
Yes. You can set limits for requests.storage, persistentvolumeclaims, and other storage-related resources in the ResourceQuota. This restricts the total amount of PersistentVolume storage that can be claimed in a namespace.
How do I view the current usage of a ResourceQuota?
Use the command kubectl describe resourcequota <quota-name> -n <namespace>. This shows the hard limit and the current usage for each resource type tracked by the quota.
Is it mandatory to specify resource requests in a pod spec if a ResourceQuota exists?
If the ResourceQuota tracks requests.cpu or requests.memory, then yes. A pod that does not specify these requests will be rejected by the API server because it cannot determine how much of the quota the pod would consume.
Summary
Resource Quotas are a fundamental Kubernetes feature that allows cluster administrators to set hard limits on the total resources a namespace can consume. They are defined as Kubernetes objects using YAML or JSON and are enforced by the API server at admission time. Quotas can limit both compute resources like CPU and memory and count-based resources like the number of pods or services.
Their primary purpose is to ensure fair sharing of cluster resources among multiple teams or projects, prevent resource exhaustion, and enable cost and capacity management. For the CKA exam, you must be able to create, modify, and troubleshoot ResourceQuota objects using kubectl and understand the distinction between quotas and LimitRanges. Common pitfalls include confusing aggregate versus per-pod limits, forgetting to include both requests and limits, and failing to use scopeSelector when required.
In real-world production clusters, Resource Quotas are a critical tool for multi-tenancy and governance. They are not a one-time setup but require ongoing monitoring and adjustment. By mastering Resource Quotas, you ensure that your Kubernetes cluster remains stable, fair, and efficient for all its users.
Study the YAML syntax, practice with hands-on labs, and remember that the quota is always about the sum of everything in the namespace, not individual pods.