ResourceQuota
Does ZopNight manage ResourceQuota?
ResourceQuotas cap a namespace's total CPU, memory, storage, and object counts, and ZopNight records both the hard ceilings and current used values side by side. A pod whose requests would push the namespace past its hard limit is rejected at admission while nodes look healthy, and a compute quota also forces every pod to declare requests.
Rules that fire on ResourceQuota
A ResourceQuota caps what a namespace may consume in total: CPU and memory requests and limits, storage, and object counts. On a shared cluster it is the guardrail that stops one team’s namespace from absorbing everyone else’s capacity, and its absence is itself a governance gap.
Hard versus used, captured side by side
Discovery stores both halves of every quota: the hard map of ceilings and the used map of current consumption. Reading them together is the entire skill of quota review. A namespace at 95 percent of its request quota will reject any pod whose requests do not fit in the remaining 5 percent; a namespace using 10 percent of a generous cap has a quota in name only; and the gap between requested-under-quota and actually-consumed is the same over-provisioning signal the workload rightsizing rules chase, aggregated to the namespace.
Quota pressure fails pods before nodes do
When a quota is exhausted, new pods are rejected at admission, and the API refuses them with a quota error before the scheduler ever sees them. That failure mode confuses on-call engineers precisely because the nodes look fine: capacity exists, but the namespace’s allowance is spent. Deploys that fail only in one environment, while identical manifests work elsewhere, are the classic symptom.
A quota is also a requests mandate
A quota that constrains CPU or memory has a sharp side effect: every pod in the namespace must declare requests or limits for the constrained resources, or admission rejects it outright. Pairing the quota with a LimitRange that injects defaults is the standard fix, letting unannotated pods land while still counting against the cap. Namespaces with a compute quota and no LimitRange are where “works in dev, rejected in prod” bugs come from.
kubectl get resourcequota -A -o custom-columns=NS:.metadata.namespace,NAME:.metadata.name,HARD:.status.hard,USED:.status.usedWhere quotas fit in cost governance
Quotas do not save money directly, since nodes bill regardless, but they convert capacity into an explicit allocation that can be reviewed, right-sized, and charged back. Namespaces running for years with no quota at all are the first thing this inventory makes visible, and on multi-tenant clusters that list is rarely empty.