How to Set Up GKE Private Cluster Networking and VPC-Native Clusters

GKE private cluster networking with VPC-native (IP-alias) configuration hides node IPs behind a VPC subnet while assigning each pod its own routable IP address from secondary ranges, eliminating the need for NAT and enabling Dataplane V2.

Google Kubernetes Engine (GKE) allows you to deploy a private cluster where worker nodes have no external IP addresses, combined with VPC-native networking that integrates pod and service IPs directly into your VPC. According to the google/skills repository, this architecture—known as the "golden path"—provides the foundation for secure, scalable, and observable Kubernetes workloads.

Why Use a Private, VPC-Native GKE Cluster?

A private, VPC-native cluster offers significant security and operational advantages over the legacy routed model. The skills/cloud/gke-basics/references/gke-golden-path.md file identifies this as the default recommendation for new cluster deployments.

• Reduced attack surface – Nodes have no external IPs and cannot be reached from the Internet.
• Improved network isolation – Pods use VPC alias IP ranges, enabling IAM-based firewall rules and traffic-visibility tools.
• Better scalability – IP-alias avoids the 65,535-IP per node limitation of the legacy routing model.
• Native integration with Cloud services – Workload Identity, Cloud SQL, Cloud Storage, and Pub/Sub can be accessed without exposing credentials.
• Dataplane V2 – Provides high-performance, gVisor-compatible networking with lower latency and better observability, enabled automatically for VPC-native clusters as documented in skills/cloud/gke-basics/references/gke-networking.md.

Core Architecture of Private GKE Networking

Four key components work together to create the private, VPC-native environment described in the source repository.

VPC-Native (IP-Alias) Networking

GKE creates secondary IP ranges within your chosen VPC subnet: one range for pods and one for services. The control plane routes pod traffic through the VPC without requiring NAT, allowing you to apply VPC firewall rules directly to workload traffic.

Private Nodes

Node VMs receive internal IPs only. While the control plane retains a public endpoint for API calls, access is secured through authorized networks or private-service-access endpoints. This configuration is implemented in skills/cloud/gke-basics/references/gke-security.md.

Dataplane V2

Enabled automatically for VPC-native clusters, Dataplane V2 replaces the legacy kube-proxy path with a kernel-native implementation. This delivers higher performance and enables network policy enforcement without sidecars.

Workload Identity

Pods authenticate to Google Cloud services using their Kubernetes service account rather than embedded secrets. This is configured via the --workload-pool flag at cluster creation time.

Creating a Private VPC-Native GKE Cluster

All architectural components must be configured at cluster creation time. The following examples from skills/cloud/gke-basics/references/gke-cluster-creation.md demonstrate the golden-path defaults.

Using gcloud CLI

Create a private, VPC-native Autopilot cluster with the required flags:

# Set variables

PROJECT=my-gcp-project
REGION=us-central1
NETWORK=custom-vpc
SUBNET=custom-subnet
POD_RANGE=pod-ip-range
SERVICE_RANGE=svc-ip-range

# Enable required APIs (once per project)

gcloud services enable container.googleapis.com \
    compute.googleapis.com \
    iam.googleapis.com

# Create the cluster

gcloud container clusters create-auto ${PROJECT}-autopilot \
    --region ${REGION} \
    --network ${NETWORK} \
    --subnetwork ${SUBNET} \
    --enable-ip-alias \
    --enable-private-nodes \
    --master-ipv4-cidr ${SERVICE_RANGE} \
    --cluster-ipv4-cidr ${POD_RANGE} \
    --enable-master-authorized-networks \
    --no-enable-basic-auth \
    --no-issue-client-certificate \
    --workload-pool=${PROJECT}.svc.id.goog

Key flags explained:

• --enable-ip-alias – Activates VPC-native networking and creates secondary IP ranges.
• --enable-private-nodes – Assigns only internal IPs to node VMs.
• --enable-master-authorized-networks – Restricts API server access to specific CIDR blocks.
• --workload-pool – Enables Workload Identity using the project-specific pool format.

Using Terraform

For reproducible infrastructure as recommended in skills/cloud/gke-basics/references/gke-infrastructure-as-code.md:

resource "google_container_cluster" "autopilot" {
  name               = "my-autopilot"
  location           = var.region
  project            = var.project
  enable_autopilot   = true

  network            = var.vpc
  subnetwork         = var.subnet
  ip_allocation_policy {
    use_ip_aliases = true
  }

  private_cluster_config {
    enable_private_nodes = true
    enable_private_endpoint = false
  }

  master_authorized_networks_config {
    cidr_blocks = [{
      cidr_block   = "203.0.113.0/24"
      display_name = "AdminNetwork"
    }]
  }

  workload_identity_config {
    workload_pool = "${var.project}.svc.id.goog"
  }
}

Verifying the Configuration

Confirm that secondary ranges are properly allocated and nodes have no external IPs:

# List the secondary ranges attached to the subnet

gcloud compute networks subnets describe ${SUBNET} --region ${REGION} \
  --format="json[?secondaryIpRanges[?rangeName!=''].secondaryIpRanges]"

# Check that pods have internal IPs only

kubectl get pods -o wide | grep -v ExternalIP

Managing Additional Pod IP Ranges

For high-traffic workloads requiring network isolation, you can allocate additional secondary ranges to specific namespaces. This technique is documented in the networking reference files.

Reserve a new secondary range and assign it to a namespace:

# Reserve a new secondary range in the same subnet

gcloud compute networks subnets update ${SUBNET} \
    --region ${REGION} \
    --add-secondary-ranges=extra-pod-range=10.10.0.0/16

# Create a namespace with a dedicated pod range

kubectl create namespace analytics
kubectl annotate namespace analytics \
    cloud.google.com/secondary-pod-range=extra-pod-range

Summary

• Private VPC-native clusters eliminate public node IPs and integrate pod networking directly into your VPC, providing superior security and scalability.
• Dataplane V2 and Workload Identity are automatically enabled with the golden-path configuration, offering high-performance networking and secure service authentication.
• Cluster creation flags --enable-ip-alias and --enable-private-nodes establish the foundation, while secondary IP ranges support multi-tenant workload isolation.
• Reference the canonical guides in google/skills under skills/cloud/gke-basics/references/ for detailed security hardening, observability setup, and cost optimization.

Frequently Asked Questions

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

VPC-native (IP-alias) networking allocates pod IPs from secondary ranges within your VPC subnet, allowing direct VPC routing and firewall rules. Routes-based networking creates static routes in your VPC for each node, limiting you to 65,535 IPs per cluster and preventing the use of VPC firewall rules for pod-to-pod traffic. The skills/cloud/gke-basics/references/gke-networking.md specifies VPC-native as the required default for new clusters.

Can I convert an existing public GKE cluster to private?

You cannot change the private/public node setting after cluster creation. Nodes are either created with internal IPs only or with external IPs at inception. To migrate, you must create a new private cluster and migrate workloads. However, you can enable VPC-native networking on some existing clusters if they were created with the --enable-ip-alias flag initially.

How does Dataplane V2 improve networking performance?

Dataplane V2 implements Kubernetes Network Policies and service routing directly in the kernel using eBPF, bypassing the iptables-based kube-proxy. As noted in the repository, this reduces latency, increases throughput, and provides better observability through flow logging while maintaining compatibility with gVisor sandboxed workloads.

What CIDR ranges should I reserve for a private GKE cluster?

You need three distinct ranges: a primary subnet range for nodes, a secondary range for pods (typically /14 or larger), and a secondary range for services (typically /20). The control plane also requires a /28 range specified via --master-ipv4-cidr. Ensure these ranges do not overlap with existing VPC subnets or on-premises networks connected via Cloud Interconnect or VPN.

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