Client’s GKE Cluster Ate Their Entire VPC: The Class E Rescue (Part 2)

In Part 1, we diagnosed the crime scene: a production GKE cluster flatlined because its /20 subnet (4,096 IPs) hit a hard ceiling at exactly 16 nodes.

The “official” consultant solution? Rebuild the VPC with a /16. The actual engineering solution? GKE Class E IP address space. If you are reading this, you likely don’t have the luxury of a maintenance window to tear down your entire networking stack. You need IPs, and you need them now. This is the field guide to the rescue operation.

The Math: Why Your Subnet Disappeared

Before we fix it, let’s explain exactly why a /20 vanishes so fast. It comes down to GKE’s default formula for VPC-native clusters, which prioritizes anti-fragmentation over efficiency.

(Max Pods per Node × 2) rounded up to the nearest subnet mask

By default, GKE assumes 110 pods per node. The math: 110 × 2 = 220 IPs. The nearest CIDR block to hold 220 IPs is a /24 (256 IPs). So the math for your /20 subnet becomes brutal:

• Total IPs: 4,096 (/20)
• Cost per node: 256 (/24)
• Result: 4096 / 256 = 16 nodes maximum

It doesn’t matter if you run 1 pod or 100 — that /24 slice is locked exclusively to that node the moment it boots. The full IP math breakdown and how to audit your cluster before hitting this ceiling is covered in GKE IP Exhaustion 2026: The /24 Trap & Autopilot’s Hidden Cost.

The GKE Class E IP Fix: Why Class E? (And Why Not CGNAT?)

To rescue the cluster without a rebuild, we need to attach a massive amount of contiguous IP space to the existing subnet. We chose Class E (240.0.0.0/4).

• Why not CGNAT (100.64.0.0/10)? In complex enterprise environments, CGNAT ranges often conflict with carrier-grade peering or existing transit setups. We needed zero routing conflicts.
• Why not IPv6? IPv6 is the correct strategic answer. But flipping a legacy IPv4-only environment to dual-stack during an active outage is a high-risk gamble.
• The Class E advantage: It offers ~268 million IPs. Most modern operating systems (Linux kernels 3.x+) and GCP’s software-defined network handle it natively.

Note that this fix addresses Pod IP exhaustion only. If you have also exhausted your Service (ClusterIP) range, that is a different problem — Service CIDRs behave differently at the API layer. The GKE Service CIDR post covers exactly that edge case.

Step 1: Verify Prerequisites

Stop. This is a rescue operation, not a standard architecture. Verify these constraints before running any commands:

1. GKE Standard only: GKE Autopilot manages this automatically. This guide is for Standard clusters.
2. VPC-native: Your cluster must use Alias IPs.
3. Hardware warning: While GCP’s SDN handles Class E perfectly, physical on-prem firewalls (Palo Alto, Cisco) often drop these packets. If your pods need to talk to on-prem databases via VPN or Interconnect, verify your hardware firewall rules first.
4. Pod ranges only: This fix solves Pod IP exhaustion. If you have exhausted your Service (ClusterIP) range, this guide will not help — Service ranges are immutable at the gcloud layer.

Step 2: The Expansion (No Downtime)

Attach a secondary CIDR range to your existing subnet using a /20 from Class E to match the original scope without massive over-provisioning.

gcloud compute networks subnets update [SUBNET_NAME] \
    --region [REGION] \
    --add-secondary-ranges pods-rescue-range=240.0.0.0/20

Step 3: Create the Rescue Node Pool

Existing pools cannot dynamically change their Pod CIDR. A new pool must be created targeting the pods-rescue-range. You must use the COS_CONTAINERD image type — older Docker-based images or legacy OS versions may not handle Class E routing correctly.

gcloud container node-pools create rescue-pool-v1 \
    --cluster [CLUSTER_NAME] \
    --region [REGION] \
    --machine-type e2-standard-4 \
    --image-type=COS_CONTAINERD \
    --enable-autoscaling --min-nodes 2 --max-nodes 20 \
    --cluster-secondary-range-name pods-rescue-range \
    --node-locations [ZONE_A],[ZONE_B]

Step 4: The Migration (Cordon & Drain)

Once the rescue nodes are online and pulling 240.x.x.x IPs, shift workloads from the starved pool.

Cordon the old nodes:

kubectl get nodes -l cloud.google.com/gke-nodepool=default-pool -o name | xargs kubectl cordon

Drain workloads safely:

kubectl drain [NODE_NAME] --ignore-daemonsets --delete-emptydir-data --timeout=10m0s

Step 5: Validation

Confirm the control plane sees the new ranges:

gcloud container clusters describe [CLUSTER] --format="value(clusterIpv4Cidr,podIpv4Cidr)"

Verify pods are pulling from the new block:

kubectl get pods --all-namespaces -o wide | grep 240.0.

If you see 240.x.x.x addresses, you have successfully engineered your way out of a corner.

Additional Resources