GKE Networking Explained: Pod IPs, VPC-Native Clusters, Services, and NetworkPolicy

GKE networking in simple terms

If Kubernetes networking feels confusing at first, it helps to anchor the core ideas before diving into the mechanics.

• Each pod gets its own IP. Unlike traditional VMs where one host might share an IP across many services, every pod gets a unique routable IP address, even if hundreds of pods run on the same node.
• Pods can talk to each other across nodes. A pod on node A can reach a pod on node B directly, without anything translating the address in between.
• Services give stable access in front of changing pods. Pods restart and get new IPs all the time. A Service gives you one consistent address that always routes to healthy pods behind it.
• DNS helps workloads find each other by name. Instead of hardcoding IPs, your app says “talk to my-api” and CoreDNS resolves that to the right Service IP automatically.
• NetworkPolicy restricts who can talk to what. Without it, every pod in the cluster can reach every other pod. NetworkPolicy lets you define precise allow/deny rules between workloads.
• GKE maps all of this onto your Google Cloud VPC. Pod IPs are first-class VPC citizens, visible to firewall rules, Cloud Monitoring, and VPC Flow Logs.

How GKE networking works

Here is the end-to-end flow from cluster creation to a pod receiving a request:

1. You create a cluster with defined IP ranges. When you run gcloud container clusters create, you specify (or let GKE auto-assign) a node subnet, a pod secondary CIDR, and a service secondary CIDR. These three ranges cannot overlap and cannot be changed later.

2. Nodes receive IPs from the primary subnet. Each GKE node VM gets a standard primary IP from your node subnet, the same way any Compute Engine VM would.

3. Nodes reserve a pod IP block from the secondary range. Each node also gets a slice of the pod secondary range as an alias IP range. Every pod scheduled on that node receives an IP from its node’s pod slice.

4. Services receive stable ClusterIPs from the service range. When you create a Service, Kubernetes assigns it a ClusterIP from the services secondary CIDR. This IP never changes for the life of the Service.

5. kube-proxy or Dataplane V2 routes traffic to pods. When your app sends traffic to a ClusterIP, the kernel intercepts it and rewrites the destination to one of the healthy pod IPs behind the Service, based on rules programmed by kube-proxy (iptables) or Dataplane V2 (eBPF).

6. CoreDNS resolves service names. Every pod’s /etc/resolv.conf points to the CoreDNS Service IP. When your code connects to my-api, CoreDNS returns the ClusterIP for the my-api Service in your namespace.

7. NetworkPolicy optionally restricts traffic paths. If the cluster was created with network policy enforcement enabled, the Calico (or Dataplane V2) dataplane enforces allow/deny rules at layer 3 and 4 before traffic reaches the destination pod.

The Kubernetes networking contract

Kubernetes does not prescribe one specific networking implementation. Instead, it defines a contract that any compliant implementation must satisfy:

1. Every pod gets its own IP address.
2. Every pod can communicate directly with every other pod on any node, without network address translation (NAT).
3. Every node can communicate with every pod, and every pod can communicate with the node it runs on.
4. The IP address a pod sees for itself is the same IP that other pods use to reach it. No address remapping occurs.

These rules mean the cluster looks like a flat layer-3 network from the application’s perspective. No application code needs to know which node a pod lives on. You address a Service in front of the pods, and the cluster handles routing.

VPC-native clusters and alias IP ranges

GKE implements the Kubernetes networking contract on top of Google Cloud VPCs using alias IP ranges. This is what makes a cluster “VPC-native,” and it has been the default since GKE 1.21.

Each GKE node has two types of IP addresses:

• A primary IP address drawn from the node subnet (the address the VM itself uses).
• A secondary alias IP range reserved for the pods scheduled on that node.

When GKE places a pod on a node, it assigns the pod an IP from that node’s alias range. Because the VPC understands alias ranges natively, traffic to a pod IP is routed directly to the right node: no custom routes, no IP masquerade, no NAT.

The practical effects are significant:

• Pod IPs are first-class VPC citizens. Firewall rules, VPC Flow Logs, and Cloud Monitoring all see real pod IPs, not just node IPs.
• You can target firewall rules at pod CIDR ranges or individual pod IPs, not just nodes.
• The pod range is separate from the node range, preventing accidental overlap.
• Pod IPs are reachable from other VPCs connected by VPC peering without extra configuration.

When creating a cluster, you can specify secondary ranges explicitly or let GKE allocate them automatically:

gcloud container clusters create my-cluster \
  --region=europe-west2 \
  --network=my-vpc \
  --subnetwork=my-subnet \
  --cluster-secondary-range-name=pods \
  --services-secondary-range-name=services \
  --enable-ip-alias

VPC-native vs routes-based clusters#

GKE originally used a routes-based model where each node had a VPC route entry pointing to its pod CIDR. This approach had real limitations: Google Cloud VPCs cap the number of routes per network, and routes-based pod IPs were not visible to VPC-level tooling.

Routes-based clusters are no longer recommended. If you are creating a new GKE cluster, VPC-native is what you get by default.

Services and how traffic flows

Pods are ephemeral. They restart, reschedule, and scale up and down constantly. Their IP addresses change with them. A Service solves this by providing a stable virtual IP (the ClusterIP) and DNS name that maps to a dynamic set of pod IPs selected by a label selector.

GKE supports the standard Kubernetes Service types:

When traffic is sent to a ClusterIP, the kernel intercepts it before it leaves the source pod. kube-proxy has programmed iptables rules to rewrite the destination to one of the healthy pod IPs behind the Service. The rewrite happens in the kernel, before the packet hits the network.

Dataplane V2 vs kube-proxy#

Enabling Dataplane V2 (--enable-dataplane-v2) replaces kube-proxy entirely with an eBPF-based implementation built on the Cilium project.

Dataplane V2 is a strong choice for clusters at scale or when you need detailed network observability. It is also the default enforcement mechanism for NetworkPolicy in GKE Autopilot.

For internal-only Services, the LoadBalancer type provisions an Internal TCP/UDP Load Balancer in your VPC, keeping traffic entirely off the public internet.

DNS and service discovery

GKE runs CoreDNS as the cluster DNS server. Every pod’s /etc/resolv.conf is configured to point at the CoreDNS ClusterIP, so DNS queries from any pod go to CoreDNS automatically.

CoreDNS answers queries using a predictable naming scheme:

<service-name>.<namespace>.svc.cluster.local

Examples:

• my-api in the production namespace resolves as my-api.production.svc.cluster.local.
• From a pod in the same namespace, the short name my-api works because /etc/resolv.conf includes production.svc.cluster.local in its search path.
• From a pod in a different namespace, you need at least my-api.production or the fully qualified name.

Pods also get DNS records in the format:

<pod-ip-dashes>.<namespace>.pod.cluster.local

A pod with IP 10.4.2.5 in the default namespace is reachable at 10-4-2-5.default.pod.cluster.local.

When understanding GKE networking matters

You do not need to memorise every detail of GKE networking on day one. But it becomes important fast in these situations:

• Troubleshooting pod-to-pod connectivity. When a service cannot reach another service, the likely cause is a misconfigured NetworkPolicy, a wrong namespace reference in DNS, or a Service selector that does not match the pod labels.
• Designing secure multi-service applications. If you have a frontend, API, and database in one cluster, NetworkPolicy is how you prevent the frontend from talking directly to the database.
• Planning IP ranges for production. Getting this wrong before cluster creation is expensive. Estimate max nodes, max pods per node, and services count, then work backwards to choose subnets.
• Exposing applications internally or externally. Choosing between ClusterIP, LoadBalancer, Ingress controllers, and internal load balancers depends on who needs access and from where.
• Choosing between Standard and Autopilot. GKE Autopilot manages node configuration for you but still uses the same VPC-native networking model, with NetworkPolicy enforcement on by default.
• Connecting GKE to hybrid environments. If your cluster needs to reach on-premises systems or services in other VPCs, you need to know whether pod IPs are advertised over Cloud VPN or Cloud Interconnect and configure Cloud Router BGP advertisement accordingly.
• Using Private GKE clusters. Private clusters remove public IPs from nodes, but pods are still assigned VPC-routable IPs. Private does not mean isolated. NetworkPolicy is still needed for pod-level control.

NetworkPolicy: restricting pod-to-pod traffic

By default, the Kubernetes networking contract means every pod can talk to every other pod in the cluster. For most production workloads, this is too permissive. NetworkPolicy is a Kubernetes resource that defines rules controlling which pods can send traffic to which other pods, and on which ports.

Two things are worth understanding before looking at examples:

1. NetworkPolicy only works if enforcement is active. On GKE Standard clusters, you must enable it at cluster creation with --enable-network-policy. GKE Autopilot enforces it by default.
2. NetworkPolicy operates at layer 3 and 4 only. It sees IP addresses and ports, not HTTP paths or TLS certificates. For layer-7 controls you need a service mesh like Anthos Service Mesh or Istio.

The recommended starting point is a deny-all ingress policy per namespace, which blocks all inbound traffic to every pod in the namespace unless a more specific policy explicitly allows it:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-ingress
  namespace: production
spec:
  podSelector: {}        # matches all pods in the namespace
  policyTypes:
    - Ingress
  # no ingress rules = deny all ingress

Allowing traffic from a specific source. This example allows frontend pods to reach api pods on port 8080:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-api
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: api
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: frontend
      ports:
        - protocol: TCP
          port: 8080

Isolating a database pod. This example accepts connections only from api pods and allows outbound DNS:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: database-isolation
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: database
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: api
      ports:
        - protocol: TCP
          port: 5432
  egress:
    - ports:
        - protocol: UDP
          port: 53   # allow DNS lookups

GKE networking vs traditional VM networking

If you are coming from a background with traditional VM infrastructure, GKE networking has a different mental model in a few important ways:

The key shift is that you stop thinking about where a workload runs and start thinking about what label it carries. Services and NetworkPolicy both use label selectors, so as pods scale up or reschedule, traffic rules and routing adjust automatically without manual intervention.

For a broader comparison of how GKE fits into the wider Google Cloud compute landscape, see GKE vs Cloud Run.