Resource Quotas and LimitRanges¶

Overview¶

Apply a namespace ResourceQuota and LimitRange so Pods cannot starve the cluster or run without requests.

ResourceQuota caps aggregate usage in a namespace. LimitRange sets default/min/max per container. Together they enable soft multi-tenancy.

This is a core tutorial in Module 8 · Configuration of the REBASH Academy Kubernetes for Cloud & DevOps Engineers series — written for Cloud, DevOps, Platform, and SRE engineers.

Prerequisites¶

ConfigMaps and Secrets

Learning Objectives¶

By the end of this tutorial, you will be able to:

Create ResourceQuota
Create LimitRange defaults
See admission reject over-quota creates

Architecture¶

This topic’s control points and relationships are shown below.

Theory¶

What it is¶

ResourceQuota sets aggregate ceilings for a namespace — total CPU, memory, object counts (Pods, Services, PVCs), and sometimes hugepages or ephemeral storage. LimitRange constrains or defaults resources on individual containers/Pods (min, max, default request/limit, max ratio). Together they implement fair sharing and guardrails for multi-team clusters.

Why it matters¶

Without quotas, one noisy namespace can schedule enough Pods to starve everyone else. Without LimitRanges, Pods with no requests are hard to schedule fairly and may burst unbounded. Platform and SRE teams rely on these objects for soft multi-tenancy before stronger isolation (separate clusters, vCluster, etc.).

How it works (mental model)¶

Create a namespace for a team or environment.
Apply a ResourceQuota — admission tracks usage against the caps.
Apply a LimitRange — when users omit requests/limits, defaults are injected; invalid sizes are rejected.
On create/update, the API server admission plugin checks quota; over-budget requests fail immediately with a clear error.
Controllers still reconcile inside the budget; scale-ups that would exceed quota fail until capacity frees.

Quotas count requests (and sometimes limits, depending on the resource name). Design requests thoughtfully.

Key concepts / comparisons¶

Object	Scope	Effect
ResourceQuota	Namespace aggregate	Caps total usage / counts
LimitRange	Per Pod/container	Defaults and bounds

Example resource name	Meaning
`requests.cpu`	Sum of CPU requests
`limits.memory`	Sum of memory limits
`pods`	Number of Pods

Common pitfalls¶

Quota on requests.cpu while teams set only limits — usage accounting surprises.
LimitRange defaults that are too large — few Pods fit under the quota.
Forgetting that system DaemonSets in other namespaces are unaffected; focus on app namespaces.
Expecting quotas to stop runtime CPU spikes alone — they govern scheduling admission, not CFS throttling by themselves.
Creating quotas in kube-system accidentally and breaking cluster components.

Hands-on Lab¶

Create a workspace for this tutorial.

mkdir -p ~/rebash-k8s/module-08-quota && cd ~/rebash-k8s/module-08-quota

Focus: Enforce hard quotas and default container limits

Step 1 – Apply quota objects¶

kubectl create namespace rebash-lab
cat > limits.yaml <<'EOF'
apiVersion: v1
kind: LimitRange
metadata:
  name: defaults
  namespace: rebash-lab
spec:
  limits:
  - type: Container
    max:
      memory: 256Mi
    default:
      memory: 128Mi
    defaultRequest:
      memory: 64Mi
---
apiVersion: v1
kind: ResourceQuota
metadata:
  name: hard
  namespace: rebash-lab
spec:
  hard:
    requests.memory: 512Mi
    limits.memory: 1Gi
    pods: "5"
EOF
kubectl apply -f limits.yaml

Step 2 – Admit a Pod and attempt an oversize request¶

kubectl -n rebash-lab run ok --image=nginx:1.27-alpine
kubectl -n rebash-lab get pod ok -o jsonpath='{.spec.containers[0].resources}{"
"}'
kubectl -n rebash-lab run too-big --image=nginx:1.27-alpine --overrides='{"spec":{"containers":[{"name":"too-big","image":"nginx:1.27-alpine","resources":{"limits":{"memory":"512Mi"}}}]}}' 2>&1 || true
kubectl -n rebash-lab describe resourcequota hard

Final step – Cleanup note¶

kubectl delete namespace rebash-lab --ignore-not-found
# Workspace kept for notes; remove with: rm -rf "$(pwd)" when finished

Validation¶

Lab commands run under ~/rebash-k8s/module-08-quota/
You can explain each Theory section in your own words
You used modern tooling where it applies to this topic
You can describe one production failure mode for this topic

Code Walkthrough¶

Production practice for Resource Quotas and LimitRanges always combines:

Inspect before you change (status, plan, logs, dry-run)
Prefer reversible, documented changes (Git, IaC, drop-ins, version pins)
Capture evidence (command output, pipeline logs) for handovers
Prefer current tools and APIs over legacy shortcuts
Least privilege — escalate credentials only when required

Keep runbooks short enough to follow under pressure. Automate checks; keep humans for judgement.

Security Considerations¶

Treat credentials and tokens for kubernetes as privileged — never commit them
Prefer short-lived auth (OIDC, roles, SSO) over long-lived keys
Validate blast radius before apply/deploy/delete operations
Restrict who can approve production changes
Collect audit logs; limit who can read sensitive traces

Common Mistakes¶

Quota on requests.cpu while teams set only limits — usage accounting surprises.

Validate assumptions against the Theory section and official docs before changing production.

LimitRange defaults that are too large — few Pods fit under the quota.

Lab shortcuts (open security groups, admin roles, skip approvals) must not ship unchanged.

Changing production without a rollback path

Always know how to revert (previous artefact, prior release, state rollback, DNS failback).

Best Practices¶

Encode Resource Quotas and LimitRanges changes as code and review them in pull requests
Pin versions (images, modules, actions, provider plugins)
Separate environments with clear promotion gates
Alert on symptoms with runbooks attached
Destroy lab resources; tag everything with owner and expiry where possible

Troubleshooting¶

Symptom	Likely cause	Fix
Auth / permission denied	Wrong identity, policy, or scope	Check caller identity, roles, and least-privilege policies
Timeout / no route	Network, DNS, security group, or endpoint	Trace path, DNS, and allow-lists before retrying
Drift / unexpected plan	Manual change or wrong state/workspace	Reconcile desired vs actual; avoid click-ops on managed resources
Pipeline/job red	Flaky step, cache, or missing secret	Read failing step logs; bisect recent workflow/config changes
Cost spike	Idle load balancer, NAT, oversized compute	Inventory billable resources; stop/delete labs promptly

Summary¶

Resource Quotas and LimitRanges is essential for Cloud and DevOps engineers working with kubernetes. Practise the lab until the inspection and change path is muscle memory, then continue the track.

Interview Questions¶

What fields commonly appear under ResourceQuota hard limits?
How does LimitRange set defaults differently from forcing every manifest to declare resources?
Can a LimitRange max block a Pod that a quota would otherwise allow?
How do memory limits interact with OOMKilled behaviour?
What governance process should surround quota changes?

Sample answer — question 2

LimitRange can inject default request/limit values at admission, reducing boilerplate while still enforcing maxima. Teams can override within allowed bounds.

Sample answer — question 4

Exceeding a memory limit triggers OOMKill of the container. Set limits from observed usage plus headroom; too low causes restarts, too high wastes node capacity.

References¶

Resource Quotas