GKE clusters whose namespace quotas outstrip real pod requests
What does ZopNight detect here?
GKE clusters where namespace ResourceQuota allocations far exceed actual pod requests strand node capacity. ZopNight's discoverer computes a packing density and stamps clusters as over-provisioned, but the rule abstains from a dollar figure today: the cluster-level price it holds is only the ~$74/month management fee, the wrong base.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1227 |
| Category | rightsizing |
| Severity | low |
| Metric | none — pure configuration read |
| Source | gke_resource_quota.go |
Where it applies
Quota slack becomes stranded nodes
Namespace quotas and generous pod requests reserve CPU the workloads never use, and the
scheduler treats reservations as facts: nodes fill up on paper while their actual
utilization idles. The cluster then holds more nodes than the real workload needs,
capacity stranded by bookkeeping. ZopNight’s discoverer measures this directly, computing
a packing density (the ratio of summed pod CPU requests to summed allocatable node CPU
across the cluster) and stamping quota_overprovisioned=true on clusters where the gap
is material. The stamp is a positive signal; clusters where it is absent or false are
never evaluated further.
The management fee is not the node bill
GKE bills two very different things: a flat per-cluster management fee (about $74 a
month for a Standard cluster) and the Compute Engine cost of the nodes, which is where
quota slack actually burns money. The only cluster-level price ZopNight holds for a
gke-cluster resource is that management fee, because the member VMs are discovered and
priced individually and pricing them again at the cluster would double-count. Tightening
quotas does not shrink the management fee by one cent, so the fee is the wrong base for
this saving.
What a real figure would need
The honest number is node rate × reclaimable capacity, where reclaimable is the summed allocatable CPU times one minus density. Today the producer persists only the boolean, not the density and not the reclaimable millicores, and the rule refuses to substitute the management fee or a guessed fraction. It therefore abstains: the finding surfaces through the stamp, the dollars wait for the producer to persist the quantity.
Look at requests versus allocatable
gcloud container clusters list \ --format="table(name,location,currentNodeCount,status)"Then, per cluster, compare kubectl describe nodes requested-CPU percentages against
actual utilization. A fleet of nodes showing 80% requested but 15% used is this finding
in the flesh. Remediation is workload hygiene: shrink over-stated pod requests, tighten
namespace ResourceQuota and LimitRange objects, and let the autoscaler remove the nodes
that frees.