GKE clusters with node auto-upgrade turned off on their node pools
What does ZopNight detect here?
GKE clusters are flagged when ZopNight records node auto-upgrade as off, the legacy per-pool `management.autoUpgrade` setting that Google enables by default. Nodes then stop following the control plane version, and keeping them within the GKE version skew policy, including security patch releases, becomes a manual job until GKE forces an upgrade at end of support.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-120 |
| Category | compliance |
| Severity | medium |
| Metric | none — pure configuration read |
| Threshold | node auto-upgrade recorded as disabled |
| Source | ZopNight |
| Permissions used | container.clusters.list · container.clusters.get |
Where it applies
What happens when nodes stop upgrading
GKE upgrades the control plane on your behalf. Node auto-upgrade keeps node pools moving with it. Google’s auto-upgrade page says what you take on when you switch it off: responsibility for keeping node versions compatible with the control plane under the GKE version skew policy. It also notes that disabling only delays upgrades until the end of standard support, after which GKE upgrades the nodes anyway, on its own timing rather than yours.
So a disabled flag rarely prevents an upgrade forever. It turns a steady stream of small, scheduled node updates into one forced upgrade on a date you did not choose.
Checking each node pool
gcloud container node-pools list --cluster=CLUSTER_NAME --location=LOCATION \ --format="table(name,version,management.autoUpgrade)"Compare the node versions with the control plane version from
gcloud container clusters describe CLUSTER_NAME --location=LOCATION --format="value(currentMasterVersion)".
The signal ZopNight uses
ZopNight rolls up the auto-upgrade setting of a cluster’s node pools into one value per cluster during inventory, and fires only when that value is explicitly off. A cluster with no recorded value is not flagged.
Pauses this rule cannot see
Google now recommends maintenance exclusions, not the per-pool flag, as the way to hold upgrades back. An exclusion leaves the flag on, so a cluster paused that way does not appear here. Review exclusions with the cluster’s maintenance policy if you need a complete picture. Autopilot clusters always auto-upgrade and cannot be switched off.
Patch risk, no dollar figure
There is no saving; the fixed estimate is $0. The risk is nodes missing security fixes, and a forced upgrade arriving at an inconvenient time.
Re-enabling upgrades safely
- Set a maintenance window so upgrades land when you want them.
- Turn auto-upgrade back on for each pool:
gcloud container node-pools update POOL_NAME --cluster=CLUSTER_NAME --location=LOCATION --enable-autoupgrade. - Configure a surge upgrade strategy or PodDisruptionBudgets so upgrades do not take down too many replicas at once.
- Keep auto-repair on too; see GKE Node Pool Auto-Repair Disabled.