Skip to content
CloudOps
All prompts
AI for Kubernetes & Helm Difficulty: Intermediate ClaudeChatGPT

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

  1. Apply LimitRange first — ensures all pods have requests.
  2. Apply ResourceQuota to cap totals.
  3. For tenant tiers, scopeSelector.
  4. 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 max blocks 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

Newsletter

Get weekly AI workflows for DevOps engineers

Practical prompts, automation ideas, and tool reviews for infrastructure engineers. One email per week. No spam.