GKE node pools averaging under 50% node CPU that fit a smaller machine type
What does ZopNight detect here?
GKE Standard node pools are billed as Compute Engine VMs of one machine type, so an oversized type costs money on every node. ZopNight flags node pools whose measured average and peak node CPU both stayed under 50% over 30 days, and prices a move to the next-smaller machine type in the same family from real rates.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1228 |
| Category | rightsizing |
| Severity | low |
| Metric | node CPU utilization |
| Threshold | average node CPU under 50% and peak under 50% (with at least 7 days of peak data) |
| Evaluation window | 30d |
| Source | ZopNight |
| Permissions used | container.clusters.get · container.nodes.list · compute.machineTypes.list · monitoring.timeSeries.list |
Where it applies
Machine type is the pool’s unit price
Every node in a GKE Standard node pool is a Compute Engine VM of the pool’s machine type. If that type is one step too large, the overspend repeats on every node, and the cluster autoscaler adds more of the same size as load grows. Picking the right type is the lever that scales with the pool.
Checking pool machine types and node CPU
gcloud container node-pools list --cluster=CLUSTER_NAME --location=LOCATION \ --format="table(name,config.machineType,initialNodeCount)"For utilization, chart kubernetes.io/node/cpu/allocatable_utilization in Metrics Explorer,
grouped by node pool. Cloud Monitoring defines it as the fraction of allocatable CPU in use on the
node.
The CPU condition for a smaller type
ZopNight reads 30 days of node CPU for the pool and fires when the average is under 50%. The peak must also stay under 50% across all the CPU history ZopNight holds, with at least 7 days of hourly peak data, so a pool that spikes is left alone. Without measured utilization it does not recommend anything, however attractive the price difference: a machine type and a rate table alone are not evidence.
Pools it does not size
The target must be the next-smaller machine type in the same family. A pool already at the family floor, or on a custom machine type ZopNight cannot step down, gets no finding. Both the current and target rates must be known, the target must actually be cheaper, and the pool must have a known cost. A pool that is low on both CPU and memory peaks is also a candidate for GKE Node Pool Underutilized.
Pricing the smaller type
saving = current pool cost x (current type rate - target type rate) / current type rateRolling the pool to a smaller type
-
Confirm the largest pod’s CPU and memory requests fit the smaller node with room for system pods.
-
Update the pool, following Google’s node pool guide:
Terminal window gcloud container node-pools update POOL_NAME --cluster CLUSTER_NAME \--location=LOCATION --machine-type MACHINE_TYPE -
Expect the pool’s nodes to be recreated using its upgrade strategy; PodDisruptionBudgets decide how fast.
-
Watch for
Pendingpods, which mean the new nodes are too small for some workloads.