VPC-native networking & IP planning

How VPC-native clusters use IPs

In a VPC-native cluster (the default and the only sensible choice today), Pods and Services get IPs from alias IP ranges of the subnet:

Pod IPs are real VPC addresses: routable across the VPC, Shared VPC, peering and hybrid links, visible in flow logs and firewall rules. That's the big advantage, and it's also why the ranges must fit the organisation's IP plan.

The rule that surprises everyone

GKE gives each node a Pod block twice the size of its max Pods per node (rounded to a power of two), so Pods can be replaced without reusing IPs too fast:

Max nodes = Pod range size / per-node block. A cluster that "only" runs 300 Pods on 16 nodes can still be full: the 17th node can't get a block. Lowering max Pods per node on new node pools stretches the range; existing pools keep their setting.

Sizing a cluster

1. Estimate max nodes at peak, including surge during upgrades (each pool can add maxSurge nodes at once) and autoscaling headroom.
2. Choose max Pods per node from your real density (most clusters run 20–60 Pods per node).
3. Pod range = max nodes × block, rounded up. Service range: a /20 (4,096 Services) suits most clusters.
4. Primary range: max nodes + internal load balancers + headroom.

Example: 300 nodes at 64 max Pods → 300 × /25 = 38,400 addresses → a /16 Pod range (65,536). Primary: a /23 (512).

Address space

• RFC 1918 space (10/8, 172.16/12, 192.168/16) is often crowded in large organisations.
• GKE also supports non-RFC 1918 ranges, including Class E (240.0.0.0/4) and privately used public ranges, for Pods. They are routable inside your VPC but not usable on the internet. Check on-prem equipment before sending such ranges over hybrid links: some firewalls and routers drop Class E.
• Pods talking to destinations outside the VPC may be masqueraded (SNAT) to the node IP depending on the destination; the ip-masq-agent configuration decides which ranges keep Pod IPs.
• IPv6 (dual-stack) clusters remove the shortage for Pods, but every system they talk to must support IPv6.

Running out, and fixing it

Symptoms: new nodes fail to be created, the cluster autoscaler logs scale-up failures about IP space, Pods stay Pending while nodes look half empty.

Fixes, least disruptive first:

1. Additional Pod ranges (discontiguous multi-Pod CIDR): add a secondary range to the subnet, and create new node pools that use it (--pod-ipv4-range). Newer versions can also add ranges cluster-wide for auto-provisioned pools.
2. Lower max Pods per node on new pools, then move workloads and delete old pools.
3. As a last resort, a new cluster with a proper plan, and migrate via GitOps.

You can't resize the original Pod or Service range in place, which is why the plan matters.

Dataplane V2 and network policy

Dataplane V2 (eBPF, based on Cilium) is the default for Autopilot and recommended for new Standard clusters (it's chosen at creation):

• Replaces kube-proxy and iptables for Service routing.
• Enforces Kubernetes NetworkPolicy natively, and can log allowed and denied connections.
• Supports FQDN network policies in recent versions (GKE Enterprise features may apply; check your version).

A starting set of policies per namespace:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: shop
spec:
  podSelector: {}
  policyTypes: [ Ingress, Egress ]
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns
  namespace: shop
spec:
  podSelector: {}
  policyTypes: [ Egress ]
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
      ports:
        - { protocol: UDP, port: 53 }
        - { protocol: TCP, port: 53 }

Then allow each real flow explicitly (ingress from the load balancer's health-check and proxy ranges, egress to the database). The Kubernetes Networking track explains policy design in depth.

Recap

• VPC-native clusters use the subnet's primary range for nodes and secondary ranges for Pods and Services.
• Each node takes a Pod block of 2 × max Pods per node: max nodes = Pod range / block.
• Fix exhaustion with additional Pod ranges on new node pools, or lower max Pods per node.
• Consider non-RFC 1918 / Class E space and IPv6 when private space is scarce.
• Dataplane V2 enforces network policy with eBPF; start every namespace from default-deny.