GKE Networking: A Deep Dive

Kubernetes is a container orchestration platform, but under the hood, it is fundamentally a networking problem. Every Pod needs an IP address. Every Service needs a stable endpoint. Every Ingress needs to connect the outside world to the inside world. And in Google Kubernetes Engine (GKE), the way these networking primitives are implemented is tightly coupled to the underlying VPC—far more so than in self-managed Kubernetes clusters. If you understand GKE networking, you understand how Google Cloud connects containers to the real network.

The most important decision you make when creating a GKE cluster is the networking mode. There are two: Routes-Based and VPC-Native. For the PCNE exam and for any production deployment, the answer is always VPC-Native.

VPC-Native Clusters: The Foundation

In a VPC-Native cluster, Pods are assigned IP addresses from the VPC’s secondary IP ranges. This means that every Pod has a “real” IP address that is routable within the VPC—no NAT, no overlay network, no encapsulation.

The IP Ranges

When you create a VPC-Native cluster, you configure three distinct IP ranges:

  1. Node Range (Primary): The subnet’s primary CIDR. Nodes get their IPs from here (e.g., 10.0.0.0/24).
  2. Pod Range (Secondary 1): A secondary CIDR for Pod IPs (e.g., 10.4.0.0/14). This is typically very large because each node can host up to 110 Pods by default.
  3. Service Range (Secondary 2): A secondary CIDR for ClusterIP Services (e.g., 10.8.0.0/20).
Why This Matters

Because Pod IPs are routable VPC addresses, they can be targets for firewall rules, appear in VPC Flow Logs, and be used directly by Internal Load Balancers. There is no translation layer. A VM in the same VPC can talk to a Pod by its IP address directly.

Public vs. Private Clusters
Public Cluster
  1. Nodes get external IP addresses.
  2. The control plane is accessible from the internet (with authorized networks for security).
  3. Simple for development, risky for production.
Private Cluster
  1. Nodes have no external IP addresses.
  2. The control plane gets a private endpoint within your VPC.
  3. Nodes reach the internet only through Cloud NAT (for pulling container images, etc.).
  4. You can optionally enable “Private Endpoint” to make the control plane accessible only from within the VPC or via VPN.

The exam frequently tests: “How does a private GKE node pull images from Docker Hub?” The answer is Cloud NAT.

Dataplane V2: The eBPF Revolution

Traditional GKE networking uses kube-proxy with iptables rules. Every Service creates a chain of iptables rules, and at scale (thousands of Services), this becomes a performance bottleneck—iptables are evaluated linearly.

Dataplane V2 replaces kube-proxy with Cilium, an eBPF-based networking agent. eBPF programs run directly in the Linux kernel, making packet processing dramatically faster.

  1. Network Policy Enforcement: Kubernetes Network Policies are enforced natively by Cilium, not by a separate controller.
  2. Visibility: You get pod-level observability without additional tools—Cilium provides flow logs at the kernel level.
  3. Performance: Hash-based lookups replace linear iptables chains. The difference is measurable at scale.
IP Masquerading: The Hidden NAT

When a Pod sends traffic to the internet, its source IP is a private secondary range address like 10.4.3.15. The internet cannot route back to that address. So GKE performs IP masquerading—the node replaces the Pod’s source IP with its own node IP before sending the packet out.

You can control exactly which destinations trigger masquerading using a ConfigMap called ip-masq-agent:

  • Traffic to the VPC’s internal ranges: Not masqueraded (Pod IP is preserved).
  • Traffic to the internet: Masqueraded (node IP is used).
  • Traffic to on-premises via VPN: Configurable (depends on whether your on-prem router has a route back to the Pod range).
Putting it Together: A Pro-Engineer View

Imagine you are deploying a machine learning inference pipeline on GKE. You create a private VPC-Native cluster with Dataplane V2 enabled. Your Pod range is /14 to support 500 nodes with 110 Pods each. The control plane is private, accessible only from your bastion subnet. Nodes pull model images from Artifact Registry using Cloud NAT. An Internal HTTPS Load Balancer with Zonal NEGs routes inference requests directly to the Pods—bypassing kube-proxy entirely. Network Policies enforced by Cilium ensure that only the frontend Pods can talk to the model-serving Pods. No iptables chains. No overlay networks. Just clean, fast, routable networking.

Related Posts