GKE clusters carrying a node pool opted out of auto-repair
What does ZopNight detect here?
Auto-repair replaces GKE nodes that fail health checks; with it off, broken nodes linger in the pool while pods fail to schedule. ZopNight rule RC-1226 evaluates the cluster-level auto_repair flag the discoverer aggregates from every pool's management.autoRepair, firing only on an explicit false: a single opted-out pool trips it.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1226 |
| Category | compliance |
| Severity | medium |
| Metric | none — pure configuration read |
| Source | gke_autorepair.go |
Where it applies
Why this finding lands on the cluster, not the pool
An implementation detail worth understanding before you go looking for the culprit: the GCP discoverer aggregates every node pool’s management.autoRepair into one cluster-level auto_repair flag: false if any pool has repair off, true only when all do, omitted when there are no pools to inspect. Rule RC-1226 reads that aggregate (metadata first, tags mirror as fallback) and fires only on the explicit false; the omitted case abstains, fail-closed. The per-pool enrichment never carries the flag at all, which is why the finding names the cluster and leaves identifying the offending pool to you:
gcloud container node-pools list --cluster my-cluster --location us-central1 \ --format='table(name,management.autoRepair)'The slow rot of a pool without repair
Auto-repair is GKE’s janitor: when a node fails consecutive health checks (NotReady beyond the tolerance window, disk pressure, a wedged kubelet), GKE drains and recreates it. With repair disabled, that node simply stays. Kubernetes reschedules what it can onto the healthy remainder, shrinking real capacity while the pool’s node count still looks right; autoscaling reasons over nodes that exist but do not work. The degradation is invisible until enough nodes have rotted that pods go Pending, at which point the on-call inherits a fleet-health backlog that a janitor process would have handled one node at a time. Broken-but-present nodes also keep billing. An unhealthy node is pure waste until someone notices.
The one honest reason it gets disabled
Pools running stateful daemons or licensed software sometimes turn repair off because an automatic node replacement is genuinely disruptive to them. If that trade-off is deliberate, document it against the pool and accept the standing finding. The rule cannot read intent. What it flags is the far more common case: repair switched off during an old incident and never restored.
Restore the default
gcloud container node-pools update my-pool --cluster my-cluster \ --location us-central1 --enable-autorepairConfirm capacity headroom first: a pool at the edge of its resources needs room to host a node’s pods during each repair cycle. Pair it with auto-upgrade, which the sibling RC-120 rule checks; the two management flags cover failure and staleness respectively, and pools healthy on both dimensions need neither finding again.