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 namespace at 95 percent of quota starts rejecting pods at admission while nodes look healthy, and a compute quota also forces every pod to declare requests.
Rules that fire on ResourceQuota
No active rule family targets ResourceQuota today. Rules that used to are retired, and retired rules publish no pages and fire no findings. Scheduling and permissions coverage are unaffected.
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 is about to start rejecting pods; 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.