# GKE Cluster Resource Quotas Overprovisioned

> 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.

Source: https://zop.dev/integrations/gcp/recommendations/gke-cluster-resource-quotas-overprovisioned
Updated: 2026-08-19

---

## 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

```bash
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.