GKE clusters still on routes-based networking instead of VPC-native alias IPs
What does ZopNight detect here?
GKE clusters are flagged when ZopNight records that alias IPs are off, meaning the cluster is routes-based rather than VPC-native. Google cannot convert a routes-based cluster in place, and such clusters miss features that need `useIpAliases`, such as network endpoint groups and firewall rules scoped to Pod IP ranges.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1224 |
| Category | compliance |
| Severity | medium |
| Metric | none — pure configuration read |
| Threshold | alias IPs recorded as disabled |
| Source | ZopNight |
| Permissions used | container.clusters.list · container.clusters.get |
Where it applies
What routes-based clusters give up
A GKE cluster routes Pod traffic in one of two ways. A VPC-native cluster gives Pods addresses from alias IP ranges on the subnet; a routes-based cluster uses custom static routes in the VPC. Google’s VPC-native overview lists what the first model buys: Pod IPs routable across peered VPCs, address ranges reserved before Pods exist so they cannot collide with other resources, no drain on the static route quota, firewall rules that target only Pod ranges, reachability from on-premises over Cloud VPN or Interconnect, and features such as network endpoint groups that work only on VPC-native clusters.
VPC-native is the default for new clusters, so a routes-based cluster today is almost always an
old one, or one created with --no-enable-ip-alias on purpose.
Listing clusters by network mode
gcloud container clusters list \ --format="table(name,location,ipAllocationPolicy.useIpAliases)"An empty or false value in the last column marks a routes-based cluster.
How ZopNight classifies the cluster
During inventory ZopNight records whether each GKE cluster uses alias IPs. The rule fires only when that value is explicitly false. There is no metric or age condition.
Clusters it will not flag
A cluster whose network mode was not recorded is left alone rather than assumed routes-based. VPC-native clusters are silent. The rule makes no judgement about subnet sizing or IP exhaustion on VPC-native clusters.
Why the saving is $0
This is a compliance finding with no dollar value. The cost is architectural: every month on a routes-based cluster is another month of workloads, DNS and load balancer wiring that will have to move.
Migrating to a VPC-native cluster
The routes-based cluster page is explicit that a routes-based cluster cannot be migrated to VPC-native, so the fix is a new cluster:
- Plan Pod and Service secondary ranges on the subnet large enough for growth.
- Create the replacement:
gcloud container clusters create NEW_CLUSTER --enable-ip-alias --region=REGION. - Deploy workloads to the new cluster and move traffic, including load balancers and DNS records.
- Delete the old cluster once nothing points at it.