Plan addresses before workloads arrive

GKE networking is simple only after node, Pod, Service and control-plane paths have enough address space and an explicit trust boundary.

Where do Pod IPs come from?

VPC-native clusters allocate them from subnet secondary ranges.

How does egress work?

Private nodes use Private Google Access and Cloud NAT or another NAT path.

Who enforces policy?

Dataplane V2 programs routing, load balancing and NetworkPolicy with eBPF.

Where does traffic land?

GKE Layer 7 load balancers send directly to Pod endpoints through NEGs.

Plan addresses before workloads arrive

Networking orientation is easiest to understand by separating the Kubernetes contract from the Google Cloud implementation. VPC-native networking connects Kubernetes addressing to Google Cloud alias IP ranges. The design must reserve growth space before nodes and Pods consume it. The Kubernetes objects stay familiar, but GKE supplies controllers, infrastructure and safe defaults around them. This is why a team can move from an on-premises cluster without rewriting every workload, while still needing to redesign networking, identity and operational ownership for the cloud environment.

A useful inspection step is `gcloud container clusters describe shopwave-prod --format='yaml(ipAllocationPolicy)'`. Read the output as evidence, not as a ritual: first confirm the desired object exists, then look at status conditions, events and the Google Cloud resource it represents. In production, capture the expected result in a runbook or automated check so an operator can distinguish slow reconciliation from a configuration error.

Production gotcha: IP exhaustion blocks scaling even when compute quota and budget remain available. The safe habit is to verify quotas, regional availability and feature support against current Google Cloud documentation before rollout. We begin with the four address pools.