Kubernetes ResourceQuota & LimitRange Design Prompt
Design multi-tenant resource governance — ResourceQuota for namespace caps, LimitRange for per-pod defaults/maxes, scoped quotas, troubleshooting quota exceeded.
- Target user
- Kubernetes platform engineers managing multi-tenant clusters
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT
The prompt
You are a senior Kubernetes platform engineer who has designed multi-tenant governance — ResourceQuota for capacity, LimitRange for default sizing, scoped quotas for priority classes. I will provide: - Tenant model (per-team namespace, per-env) - Current quotas (if any) - Symptom (quota exceeded, can't create pod, limit too restrictive) Your job: 1. **ResourceQuota**: - Namespace-scoped - Caps total resources (CPU, memory, pods, services, etc.) - Tracks `requests` and `limits` separately - Caps object counts (pods, configmaps, secrets) 2. **LimitRange**: - Namespace-scoped - Sets defaults (when pod doesn't specify) - Min/max bounds - Per-container or per-pod 3. **Together**: - LimitRange ensures pods have requests/limits → ResourceQuota can track - Without LimitRange, BestEffort pods (no requests) bypass quota tracking 4. **For "quota exceeded"**: - Check current usage: `kubectl describe quota` - Identify hogs - Tune quota OR right-size pods OR scale namespace 5. **For scoped quota** (priority-aware): - `scopeSelector` to limit quota to specific priority class - E.g., production-tier quota vs dev-tier quota 6. **For storage quota**: - PVC count - PVC total storage - Per-StorageClass quota 7. **For default sizing via LimitRange**: - `defaultRequest` for containers without - `default` for limits - Prevents BestEffort accidentally 8. **For per-namespace pod count**: - Avoid runaway scaling - Sum across all replicasets/jobs Mark DESTRUCTIVE: lowering ResourceQuota below current usage (existing pods continue but new creates fail), removing LimitRange without specs in pod (BestEffort pods bypass quota), tight quotas during incidents (blocks recovery). --- Tenant model: [DESCRIBE] Current ResourceQuotas: ``` [PASTE `kubectl get quota -A`] ``` LimitRanges: ``` [PASTE `kubectl get limitrange -A`] ``` Symptom: [DESCRIBE]
Why this prompt works
ResourceQuota + LimitRange is the basic governance primitive. Most teams underuse them. This prompt walks the design.
How to use it
- Apply LimitRange first — ensures all pods have requests.
- Apply ResourceQuota to cap totals.
- For tenant tiers, scopeSelector.
- Monitor usage before tightening.
Useful commands
# View quotas
kubectl get quota -A
kubectl describe quota -n <ns>
# View limit ranges
kubectl get limitrange -A
kubectl describe limitrange -n <ns>
# Per-pod resource view
kubectl get pods -n <ns> -o json | \
jq -r '.items[] | "\(.metadata.name) \([.spec.containers[].resources.requests.memory] | join(","))"'
# Sum requests in namespace
kubectl get pods -n <ns> -o json | \
jq '[.items[].spec.containers[].resources.requests | (.cpu // "0") | gsub("m$";"")] | map(tonumber) | add'
Patterns
Production namespace
apiVersion: v1
kind: ResourceQuota
metadata:
name: production-quota
namespace: production
spec:
hard:
requests.cpu: "100"
requests.memory: 200Gi
limits.cpu: "200"
limits.memory: 400Gi
requests.storage: 5Ti
pods: "200"
persistentvolumeclaims: "50"
services: "30"
services.loadbalancers: "5"
---
apiVersion: v1
kind: LimitRange
metadata:
name: default-limits
namespace: production
spec:
limits:
- type: Container
default:
cpu: "500m"
memory: "512Mi"
defaultRequest:
cpu: "100m"
memory: "128Mi"
min:
cpu: "50m"
memory: "64Mi"
max:
cpu: "4"
memory: "8Gi"
- type: PersistentVolumeClaim
min:
storage: 1Gi
max:
storage: 500Gi
Scoped quota by priority
apiVersion: v1
kind: ResourceQuota
metadata:
name: prod-tier-quota
namespace: shared
spec:
hard:
requests.cpu: "50"
requests.memory: 100Gi
scopeSelector:
matchExpressions:
- operator: In
scopeName: PriorityClass
values: [prod-high, prod-standard]
---
apiVersion: v1
kind: ResourceQuota
metadata:
name: batch-tier-quota
namespace: shared
spec:
hard:
requests.cpu: "20"
requests.memory: 40Gi
scopeSelector:
matchExpressions:
- operator: In
scopeName: PriorityClass
values: [batch]
Per-StorageClass quota
apiVersion: v1
kind: ResourceQuota
metadata:
name: storage-quota
spec:
hard:
fast-ssd.storageclass.storage.k8s.io/requests.storage: 1Ti
fast-ssd.storageclass.storage.k8s.io/persistentvolumeclaims: "10"
standard.storageclass.storage.k8s.io/requests.storage: 10Ti
Common findings this catches
- Pod creation rejected: quota exceeded → check current usage; tune quota or pod.
- BestEffort pods don’t count → add LimitRange with defaults.
- PVC create rejected → storage quota; check
kubectl describe quota. - Quota tracking out of sync → recalc by deleting/recreating quota.
- Cross-quota issues with scoped — verify PriorityClass mapping.
- LimitRange
maxblocks legitimate pods → tune for largest expected. - Default request too high → fragmenting capacity.
When to escalate
- Multi-tenant governance design — strategic.
- Quota tuning for growth — capacity planning.
- Tenant exceeding quota — billing / business discussion.
Related prompts
-
Kubernetes Namespace Strategy Prompt
Design namespace strategy — per-team, per-env, per-app; hierarchical namespaces (HNC); namespace-level RBAC; multi-tenancy patterns.
-
Kubernetes Pod Priority & Preemption Prompt
Design PriorityClass hierarchies — critical system pods, tenant tiers, preemption policy, non-preemptive priority, scheduling guarantees.
-
Kubernetes Resource Limits & OOMKilled Tuning Prompt
Tune CPU/memory requests and limits to stop OOMKilled, fix throttling, right-size HPA targets, and avoid noisy-neighbor scheduling issues.