GKE Networking Configuration and Best Practices: The Complete Guide

Configure GKE clusters as private, VPC-native deployments with Dataplane V2 enabled, then expose services via Gateway API with Cloud Armor and Managed SSL certificates for production-grade security and performance.

The google/skills repository provides authoritative reference implementations for Google Kubernetes Engine networking. This guide synthesizes the cluster-level configurations from skills/cloud/gke-networking/SKILL.md and service-level patterns from skills/cloud/gke-service-networking/SKILL.md into actionable best practices for secure, scalable deployments.

Cluster-Level Networking Configuration (Day-0)

Establishing a secure foundation requires configuring private cluster architecture and advanced datapath capabilities before workloads are deployed.

Private Cluster Architecture

The golden path defined in skills/cloud/gke-networking/SKILL.md mandates three critical settings at creation time. First, set privateClusterConfig.enablePrivateNodes to true to ensure compute nodes receive only private IP addresses, eliminating public internet exposure. Second, enable masterAuthorizedNetworksConfig.privateEndpointEnforcementEnabled to restrict control plane access to the private endpoint or authorized networks only. Third, configure controlPlaneEndpointsConfig.dnsEndpointConfig.allowExternalTraffic as true to allow DNS-based cluster access from outside the VPC without requiring a VPN tunnel.

Dataplane V2 and IP Management

Modern GKE networking configuration relies on Dataplane V2, specified via networkConfig.datapathProvider: ADVANCED_DATAPATH. This eBPF-based datapath provides built-in NetworkPolicy enforcement without the performance overhead of Calico, while enabling features like intra-node visibility. For DNS, set networkConfig.dnsConfig.clusterDns: CLOUD_DNS to leverage managed Cloud DNS rather than kube-dns.

IP address management should use ipAllocationPolicy.autoIpamConfig.enabled: true and ipAllocationPolicy.createSubnetwork: true to automate CIDR allocation and avoid manual range conflicts. When planning node density, the defaultMaxPodsConstraint.maxPodsPerNode parameter controls IP consumption—48 suits most workloads, while 110 maximizes density for high-utilization scenarios but consumes larger CIDR blocks.

Service-Level Networking and Edge Routing

After establishing the cluster network, configure edge routing and security using the resources defined in skills/cloud/gke-service-networking/SKILL.md.

Gateway API Implementation

For new deployments, Gateway API replaces classic Ingress. The skill provides a manifest using gatewayClassName: gke-l7-global-external-managed, which supports multi-cluster routing and fine-grained listener configuration. Unlike legacy Ingress, Gateway API separates infrastructure concerns from application routing through distinct Gateway and HTTPRoute resources.

Security Hardening with Cloud Armor

Protect public endpoints by creating a Cloud Armor security policy and referencing it via a BackendConfig custom resource. The skill demonstrates this configuration on lines 96-112 of skills/cloud/gke-service-networking/SKILL.md, showing how to attach the policy to a Service using the cloud.google.com/backend-config annotation.

Automated Certificate Management

Eliminate certificate expiration risks using Managed SSL Certificates. The skill provides two approaches: the legacy ManagedCertificate resource for simple domains, and the modern Certificate Manager integration using the networking.gke.io/cert-map annotation on Gateway resources for complex multi-domain scenarios.

Container-Native Load Balancing (NEGs)

Enable Network Endpoint Groups (NEGs) by adding the cloud.google.com/neg: '{"ingress": true}' annotation to your Service manifest. This allows the Google Cloud load balancer to target individual pods directly rather than routing through ClusterIP, reducing latency and improving traffic distribution during scaling events.

Private Service Connect

For cross-VPC service sharing without peering, implement Private Service Connect (PSC). The skill outlines the ServiceAttachment workflow, which creates a dedicated NAT subnet and generates a service attachment URI that consumer VPCs use to establish secure, private connectivity to GKE workloads.

GKE Networking Best Practices Checklist

Implement these configurations to optimize security, performance, and cost:

• Enable Dataplane V2 (ADVANCED_DATAPATH) for eBPF-based networking and native NetworkPolicy support
• Use Gateway API for all new ingress requirements to ensure future-proof, role-based routing
• Deploy Cloud Armor on all public-facing endpoints to enable WAF and DDoS protection
• Automate SSL certificates via Certificate Manager to eliminate manual renewal processes
• Enable NEGs on Services to achieve direct pod-to-load-balancer routing
• Enable intra-node visibility (enableIntraNodeVisibility: true) to capture VPC Flow Logs for east-west traffic analysis
• Implement default-deny NetworkPolicies per namespace, then explicitly allow required flows (see skills/cloud/gke-workload-security/SKILL.md)
• Reserve adequate IP space using auto-IPAM with /17 pod CIDRs and /20 service CIDRs for large clusters
• Use Private Service Connect instead of VPC peering for cross-project service consumption

Implementing the Golden Path

Follow these code patterns from the google/skills repository to implement the recommended configuration:

Create a Private VPC-Native Cluster

gcloud container clusters create-auto my-gke-cluster \
  --region us-central1 \
  --enable-private-nodes \
  --enable-master-authorized-networks \
  --quiet

Retrieve Cluster Credentials (DNS Endpoint)

gcloud container clusters get-credentials my-gke-cluster \
  --region us-central1 \
  --dns-endpoint \
  --quiet

Deploy a Gateway and HTTPRoute

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: my-gateway
  namespace: default
spec:
  gatewayClassName: gke-l7-global-external-managed
  listeners:
    - name: http
      protocol: HTTP
      port: 80

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: my-route
  namespace: default
spec:
  parentRefs:
    - name: my-gateway
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /
      backendRefs:
        - name: my-service
          port: 80

Configure Cloud Armor Protection

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backend-config
  namespace: default
spec:
  securityPolicy:
    name: my-cloud-armor-policy

Apply the annotation to your Service:

metadata:
  annotations:
    cloud.google.com/backend-config: '{"default":"my-backend-config"}'

Enable Container-Native Load Balancing

metadata:
  annotations:
    cloud.google.com/neg: '{"ingress": true}'

Create a Private Service Connect Attachment

apiVersion: networking.gke.io/v1
kind: ServiceAttachment
metadata:
  name: my-attachment
  namespace: default
spec:
  connectionPreference: ACCEPT_AUTOMATIC
  natSubnets:
    - my-psc-nat-subnet
  resourceRef:
    kind: Service
    name: my-service

Summary

• Private, VPC-native clusters with Dataplane V2 provide the security foundation and observability required for production GKE networking configuration
• Gateway API supersedes classic Ingress for modern traffic management, offering superior flexibility and multi-cluster support
• Cloud Armor and Managed SSL automatically secure public endpoints without operational overhead
• NEGs and Private Service Connect optimize traffic routing for both internet-facing and internal workloads
• Reference implementations in skills/cloud/gke-networking/SKILL.md and skills/cloud/gke-service-networking/SKILL.md provide copy-ready manifests for Day-0 and Day-1 operations

Frequently Asked Questions

What is the difference between VPC-native and routes-based GKE clusters?

VPC-native clusters utilize alias IP ranges (VPC subnets) for pod addressing, enabling direct integration with VPC firewall rules, Cloud NAT, and Private Service Connect. Routes-based clusters rely on static routes managed by GKE, which limits advanced networking features and creates scalability bottlenecks. The google/skills repository exclusively recommends VPC-native mode via ipAllocationPolicy.autoIpamConfig.enabled: true.

Should I use Gateway API or classic Ingress for new GKE deployments?

Gateway API is the recommended approach for all new deployments. According to skills/cloud/gke-service-networking/SKILL.md, Gateway API supports multi-cluster gateways, HTTP/HTTPS listener separation, and role-based resource organization that classic GCE Ingress cannot match. Use classic Ingress only for legacy maintenance scenarios.

How do I implement network policies in GKE?

Enable Dataplane V2 (networkConfig.datapathProvider: ADVANCED_DATAPATH) during cluster creation, which embeds NetworkPolicy enforcement directly into the eBPF datapath. Then apply a default-deny policy per namespace and explicitly allow required traffic flows. For comprehensive policy templates, reference skills/cloud/gke-workload-security/SKILL.md.

What CIDR ranges should I reserve for GKE pod and service IPs?

For auto-pilot and standard clusters using auto-IPAM, allocate a /17 CIDR for pod IPs and /20 for service IPs to support growth without reconfiguration. Setting defaultMaxPodsConstraint.maxPodsPerNode to 48 conserves IP space while supporting typical workload densities. The gke-networking skill enforces these defaults to prevent exhaustion during horizontal scaling events.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}