Namespace quotas: reserve room for a safe rollout

Operational decision

A claims namespace normally requests seven CPU cores and sixteen gibibytes of memory. Set an aggregate request budget with room for one replacement Pod, then rehearse the maximum-surge rollout under the quota. The YAML block is a namespace quota, not a sizing recommendation for another cluster. Inventory existing Deployments, Jobs, and PVCs before applying it. Test a new Pod that should be admitted and one that should be denied; read the admission message rather than blaming the scheduler. If a LimitRange injects default requests, check the resulting Pod spec and quota usage. A quota can protect neighbors from runaway work but can also stop incident recovery if the only spare capacity lies beyond the namespace cap.

apiVersion: v1
kind: ResourceQuota
metadata: {name: claims-budget, namespace: claims}
spec:
  hard:
    requests.cpu: '9'
    requests.memory: 22Gi
    limits.memory: 34Gi
    pods: '47'

Cost and verification

The quota itself costs little at runtime, yet it creates operational review when teams add workloads. Overly generous limits do not reserve node capacity; overly tight ones can prevent a replacement from being admitted. Compare quota headroom with scheduler capacity and the Deployment's surge policy. Monitor hard and used values, especially during backfills and failed Jobs. Apply per-container defaults deliberately because an injected memory limit can trigger out-of-memory kills in software never tested at that limit.

Common Mistakes

• Do not size quota only for steady-state replicas.
• Do not assume quota creates nodes or storage capacity.
• Do not add a LimitRange without checking injected defaults on real Pods.

Connected lessons

• DevOps: delivery, infrastructure, and reliable operations
• Kubernetes requests and limits: schedule for real load
• Kubernetes Deployment: rolling update capacity
• Pod disruption budgets: make node drains measurable
• Cloud cost and capacity: assign an owner to each recurring resource

Practice and check

• Project: stage and recover a stateful release
• DevOps stateful operations decisions

Platform operating-contract follow-up

• Self-service provisioning: make the request contract explicit