> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Resource Governance Defaults Limits and Quotas

> Explains Kubernetes ResourceQuota and LimitRange, their admission-time interaction, and how to use defaults and quotas to prevent noisy-neighbor resource contention

ResourceQuota and LimitRange are fundamental guardrails for multi-tenant Kubernetes clusters. In this lesson we deep-dive into both objects, how they interact during admission, and how to apply them to prevent noisy-neighbor incidents and uncontrolled resource consumption.

By the end of this lesson you will be able to:

* Describe the purpose of ResourceQuota and LimitRange.
* Set namespace-level limits using ResourceQuota.
* Apply default container limits using LimitRange.
* Explain how both interact during pod admission.

![A slide titled "Learning Objectives" listing four numbered goals about Kubernetes resource management—describe ResourceQuota and LimitRange, set namespace-level limits with ResourceQuota, apply default container limits with LimitRange, and explain the rule linking them.](https://mintcdn.com/kodekloud-c4ac6d9a/jFwNGqGMK4QeJs-g/images/Prep-Course-Certified-Cloud-Native-Platform-Engineering-CNPE/Platform-Architecture-and-Infrastructure/Resource-Governance-Defaults-Limits-and-Quotas/kubernetes-learning-objectives-resourcequota-limitrange.jpg?fit=max\&auto=format\&n=jFwNGqGMK4QeJs-g\&q=85\&s=7f33d5e33fbb1e2350d6834096bbcf35)

What happens without governance?

Imagine a shared staging cluster used by multiple teams. One developer runs a large load test and scales a Deployment to hundreds of replicas on a cluster with limited CPU. Those replicas quickly consume most available CPU and memory. Other teams’ pods cannot be scheduled, existing pods may be evicted, and critical demos fail — a classic noisy neighbor problem.

![A diagram titled "Noisy-Neighbor Problem" showing a staging Kubernetes cluster where Team A's load test scales to hundreds of replicas and consumes cluster CPU/memory. As a result, Team B's new pods are shown pending due to exhausted capacity.](https://mintcdn.com/kodekloud-c4ac6d9a/jFwNGqGMK4QeJs-g/images/Prep-Course-Certified-Cloud-Native-Platform-Engineering-CNPE/Platform-Architecture-and-Infrastructure/Resource-Governance-Defaults-Limits-and-Quotas/noisy-neighbor-kubernetes-staging-pending-pods.jpg?fit=max\&auto=format\&n=jFwNGqGMK4QeJs-g\&q=85\&s=d6f6ade8c82fdf2135ac9bf27c2482b0)

This is more common than it sounds: accidental large replica counts, CI/CD job bugs creating many pods, or namespaces with no defaults/limits. Without guardrails, Kubernetes will accept resource requests and schedule until capacity is exhausted.

![A slide titled "The Problem" with three colored boxes labeled "Accidental Replicas", "CI/CD Deployment Bugs", and "Limitless Namespaces", all linked by dashed lines down to a box labeled "Missing Guardrails." It’s a simple diagram illustrating deployment/runtime issues.](https://mintcdn.com/kodekloud-c4ac6d9a/jFwNGqGMK4QeJs-g/images/Prep-Course-Certified-Cloud-Native-Platform-Engineering-CNPE/Platform-Architecture-and-Infrastructure/Resource-Governance-Defaults-Limits-and-Quotas/deployment-runtime-missing-guardrails.jpg?fit=max\&auto=format\&n=jFwNGqGMK4QeJs-g\&q=85\&s=7674fa531ebfc4f8e400effad359086c)

A simple ResourceQuota prevents runaway resource use. For example, setting a 50-pod limit per namespace causes the API server to reject scale-ups beyond that limit.

![A slide titled "The Solution" showing a diagram labeled "ResourceQuota" with a large rounded box for a "Staging Cluster." Inside is a dashed "Target Namespace" containing a small label that reads "Quota: 50 Pods."](https://mintcdn.com/kodekloud-c4ac6d9a/jFwNGqGMK4QeJs-g/images/Prep-Course-Certified-Cloud-Native-Platform-Engineering-CNPE/Platform-Architecture-and-Infrastructure/Resource-Governance-Defaults-Limits-and-Quotas/resourcequota-staging-target-namespace-50-pods.jpg?fit=max\&auto=format\&n=jFwNGqGMK4QeJs-g\&q=85\&s=c25f859bb9bdfe59ba246f3496be366f)

Kubernetes scheduling is effectively first-come, first-served if you don’t apply quotas. On clusters without quotas:

![A presentation slide titled "First-Come, First-Served" showing a blue rounded panel listing resource settings: "CPU quota: unlimited," "Memory quota: unlimited," "Pod count: unlimited," and "Container defaults: none." The slide is © KodeKloud.](https://mintcdn.com/kodekloud-c4ac6d9a/jFwNGqGMK4QeJs-g/images/Prep-Course-Certified-Cloud-Native-Platform-Engineering-CNPE/Platform-Architecture-and-Infrastructure/Resource-Governance-Defaults-Limits-and-Quotas/first-come-first-served-unlimited-resources.jpg?fit=max\&auto=format\&n=jFwNGqGMK4QeJs-g\&q=85\&s=ac6be6abfa14f39993b498723f9eedd6)

Whoever deploys first claims resources. For shared clusters, ResourceQuota and LimitRange are baseline guardrails — similar to rules in a shared office: they prevent one team from monopolizing the space.

ResourceQuota: namespace budget caps

ResourceQuota enforces a namespace-level budget. It caps aggregate resource consumption across all objects in the namespace: CPU and memory requests/limits, pod counts, object counts (ConfigMaps, Services), and storage usage.

Example ResourceQuota YAML:

```yaml theme={null}
apiVersion: v1
kind: ResourceQuota
metadata:
  name: rq-example
spec:
  hard:
    requests.cpu: "4"
    requests.memory: "8Gi"
    limits.cpu: "8"
    limits.memory: "16Gi"
    pods: "10"
```

Key effects of this example:

* The sum of all container CPU requests in the namespace cannot exceed 4 cores.
* The sum of all memory requests cannot exceed 8Gi.
* The total number of pods in the namespace cannot exceed 10.

If creating a pod (or updating an object) would cause totals to exceed the quota, the API server rejects the request with a 403 Forbidden before the pod is created.

ResourceQuota commonly covers these categories:

* Compute: `requests.cpu`, `requests.memory`, `limits.cpu`, `limits.memory`.
* Object counts: `count/pods`, `count/configmaps`, `count/services` — prevents object sprawl.
* Storage: `requests.storage`, number of PersistentVolumeClaims, and volume counts.

![A slide titled "ResourceQuota: Namespace Budget Caps" showing three boxes—Compute, Object Count, and Storage—with bullets like requests.cpu, requests.memory, count/pods, count/services, and requests.storage. It summarizes namespace resource limits and notes enforcing storage and volume limits.](https://mintcdn.com/kodekloud-c4ac6d9a/jFwNGqGMK4QeJs-g/images/Prep-Course-Certified-Cloud-Native-Platform-Engineering-CNPE/Platform-Architecture-and-Infrastructure/Resource-Governance-Defaults-Limits-and-Quotas/resourcequota-namespace-budget-caps.jpg?fit=max\&auto=format\&n=jFwNGqGMK4QeJs-g\&q=85\&s=c2c3354cde94e842751449b2c58fea47)

Enforcement: admission-time checks

ResourceQuota is enforced at admission time by the API server. When a create/update request arrives, the API server evaluates whether admitting the change would exceed any hard limits in the ResourceQuota. If it would, the operation is rejected with a 403 Forbidden error. This check runs before scheduling.

![A flowchart titled "ResourceQuota: Namespace Budget Caps" showing a Pod Request sent to the API, which checks if it exceeds quota limits. If not, the request is approved and the pod is created; if yes, the request is rejected with a 403 Forbidden error.](https://mintcdn.com/kodekloud-c4ac6d9a/jFwNGqGMK4QeJs-g/images/Prep-Course-Certified-Cloud-Native-Platform-Engineering-CNPE/Platform-Architecture-and-Infrastructure/Resource-Governance-Defaults-Limits-and-Quotas/pod-request-quota-check-flowchart.jpg?fit=max\&auto=format\&n=jFwNGqGMK4QeJs-g\&q=85\&s=740434a8aa3b08b57ae5e1ac727cf8b3)

LimitRange: per-object defaults and bounds

LimitRange configures defaults and bounds for individual containers, pods, or PersistentVolumeClaims in a namespace. It serves two main purposes:

* Inject defaults (`defaultRequest` / `default`) when containers omit requests or limits.
* Enforce minimum (`min`) and maximum (`max`) bounds for individual containers or pods.

Because ResourceQuota commonly accounts against `requests.*` and `limits.*`, ensuring containers specify these fields is important for accurate quota enforcement. LimitRange automates that by filling in defaults or rejecting pods that fall outside acceptable per-object ranges.

LimitRange applies to types such as Container, Pod, and PersistentVolumeClaim (Container is most commonly used).

![A slide titled "LimitRange: Per-Object Defaults and Bounds" showing a "LimitRange Policy" box with "Inject Defaults" and "Enforce Min/Max" that points to an "Individual Workload" box containing an "Individual Pod."](https://mintcdn.com/kodekloud-c4ac6d9a/jFwNGqGMK4QeJs-g/images/Prep-Course-Certified-Cloud-Native-Platform-Engineering-CNPE/Platform-Architecture-and-Infrastructure/Resource-Governance-Defaults-Limits-and-Quotas/limitrange-inject-defaults-enforce-min-max.jpg?fit=max\&auto=format\&n=jFwNGqGMK4QeJs-g\&q=85\&s=a24572a70ff1aee07e1dbc1e50ec1f8c)

Example LimitRange YAML:

```yaml theme={null}
apiVersion: v1
kind: LimitRange
metadata:
  name: example-limitrange
spec:
  limits:
  - type: Container
    min:
      cpu: 50m
      memory: 64Mi
    max:
      cpu: "1"
      memory: 1Gi
    defaultRequest:
      cpu: 100m
      memory: 128Mi
    default:
      cpu: 500m
      memory: 256Mi
```

This configuration:

* Ensures containers specify at least `50m` CPU and `64Mi` memory.
* Caps containers at `1` CPU and `1Gi`.
* Injects default request values when not provided (so pods are not BestEffort).

LimitRange and ResourceQuota are complementary: ResourceQuota caps aggregate consumption; LimitRange ensures per-object values make quota accounting accurate and predictable.

![A presentation slide titled "LimitRange: Per-Object Defaults and Bounds" showing two labeled boxes: "ResourceQuota" (saying a namespace can use up to 10 CPUs total) and "LimitRange" (saying each container must stay within 100m–2 CPUs). The slide is from KodeKloud.](https://mintcdn.com/kodekloud-c4ac6d9a/jFwNGqGMK4QeJs-g/images/Prep-Course-Certified-Cloud-Native-Platform-Engineering-CNPE/Platform-Architecture-and-Infrastructure/Resource-Governance-Defaults-Limits-and-Quotas/limitrange-resourcequota-per-object-defaults-kodekloud.jpg?fit=max\&auto=format\&n=jFwNGqGMK4QeJs-g\&q=85\&s=0fff9c50e4e2a768967434ecc5ab2abc)

How they work together (admission flow)

Admission order is important. The typical flow for a pod create/update:

1. Pod submitted to the API server (via kubectl, controller, etc.).
2. LimitRange admission controller intercepts:
   * Injects defaults if containers omit requests/limits (`defaultRequest` / `default`).
   * Validates that per-object `min`/`max` constraints are satisfied; rejects if not.
3. ResourceQuota admission controller evaluates whether admitting this pod would exceed namespace-wide budgets by summing requests/limits with current usage; rejects if quota would be exceeded.
4. If both checks pass, the pod is admitted and sent to the scheduler for placement.

Because defaulting happens before quota computation, LimitRange ensures the API server can accurately calculate quota usage.

![A slide titled "How They Work Together" showing a four-step Kubernetes pod admission flow: 01 Pod Submitted, 02 LimitRange (defaults + validate), 03 ResourceQuota (check budget), and 04 Pod Admitted or Rejected. Each step has brief bullet points explaining defaulting/validation, quota checks, and the final admission outcome.](https://mintcdn.com/kodekloud-c4ac6d9a/jFwNGqGMK4QeJs-g/images/Prep-Course-Certified-Cloud-Native-Platform-Engineering-CNPE/Platform-Architecture-and-Infrastructure/Resource-Governance-Defaults-Limits-and-Quotas/kubernetes-pod-admission-flow.jpg?fit=max\&auto=format\&n=jFwNGqGMK4QeJs-g\&q=85\&s=e1d76defcf2c870e831bb5e3700b7e06)

Quick reference: ResourceQuota vs LimitRange

| Feature | ResourceQuota | LimitRange |
| -: | :-: | :-: |
| Scope | Namespace aggregate (budget) | Per-object (pod/container/PVC) |
| Purpose | Cap total usage: CPU, memory, pods, objects, storage | Inject defaults & enforce min/max for containers/pods/PVCs |
| Enforced by | API server admission controller | API server admission controller |
| Typical fields | `requests.cpu`, `requests.memory`, `pods`, `count/configmaps` | `min`, `max`, `defaultRequest`, `default` |
| Useful when | Preventing noisy neighbors, controlling team budgets | Ensuring requests/limits exist so quotas can be calculated; preventing BestEffort QoS |

Practical examples

* `limit-pod-count` (ResourceQuota) — stops a namespace creating more than 10 pods. Useful for development namespaces.
* `team-budget` (ResourceQuota) — caps CPU and memory for a team namespace in multi-tenant clusters.
* `container-defaults` (LimitRange) — injects default requests so containers are not BestEffort and ResourceQuota can account for them.

Combined example manifests:

```yaml theme={null}
apiVersion: v1
kind: ResourceQuota
metadata:
  name: limit-pod-count
spec:
  hard:
    pods: "10"

---
apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-budget
spec:
  hard:
    requests.cpu: "8"
    requests.memory: 16Gi

---
apiVersion: v1
kind: LimitRange
metadata:
  name: container-defaults
spec:
  limits:
  - type: Container
    defaultRequest:
      cpu: 500m
```

Apply LimitRange defaults together with ResourceQuota caps to create predictable, fair resource allocation across teams and environments.

Best practice: Apply a LimitRange that injects reasonable default requests to every namespace, and then use ResourceQuota to cap aggregate consumption per namespace. This prevents BestEffort QoS, enables quota accounting, and reduces noisy-neighbor incidents.

Four takeaways

1. ResourceQuota caps total namespace consumption (aggregate budget).
2. LimitRange sets defaults and enforces min/max per container or pod.
3. Use both together: LimitRange ensures objects have requests/limits so ResourceQuota can account for them accurately.
4. Admission order matters: LimitRange defaulting/validation runs before ResourceQuota’s quota checks, and both run before scheduling.

Links and references

* Kubernetes ResourceQuota: [https://kubernetes.io/docs/concepts/policy/resource-quotas/](https://kubernetes.io/docs/concepts/policy/resource-quotas/)
* Kubernetes LimitRange: [https://kubernetes.io/docs/concepts/policy/limit-range/](https://kubernetes.io/docs/concepts/policy/limit-range/)
* Kubernetes admission controllers overview: [https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/)

> **[Watch Video](https://learn.kodekloud.com/user/courses/prep-course-certified-cloud-native-platform-engineer-cnpe/module/989346de-0207-4837-af11-bf456d188972/lesson/5414db24-0e14-4c28-8e4a-f2f984793617)**


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.