Namespaces get budgets and defaults

Study notes

• Per-Pod requests and limits are only half of resource governance. In a shared cluster, platform teams set namespace-level budgets with a ResourceQuota, which caps the total requests, limits, object counts and storage a namespace may use, and defaults with a LimitRange, which supplies default requests and limits for containers that omit them and can set per-container minimums and maximums.
• Both are enforced by admission controllers, which is the stage before persistence. A request that would exceed the quota is rejected outright and the Pod object is never created. This is why a quota failure looks like a Pod that simply vanished, with the explanation only in the error returned to the client or in the owning ReplicaSet's events. Contrast that with a scheduling failure, where the Pod exists, shows Pending, and carries a FailedScheduling event.
• Confusing the two wastes real debugging time. When a Deployment shows fewer Pods than desired and kubectl get pods lists no Pending Pods, check the ReplicaSet events and the namespace quota. When you do see Pending Pods, check node capacity, taints and affinity.
• LimitRange is a quiet safety net: with a sensible defaultRequest, a developer who forgets a resources block still gets Burstable QoS rather than BestEffort. Combine both with admission policy engines (Kyverno, Gatekeeper) to require requests on every workload.

Deck map