GKE networking (VPC-native) in GCP - Mini Project: Build & Apply

GKE Networking with VPC-native Clusters

📖 Scenario: You are setting up a Google Kubernetes Engine (GKE) cluster that uses VPC-native networking. This means the cluster will use alias IP ranges from a Virtual Private Cloud (VPC) network for pod IPs, improving network management and scalability.

🎯 Goal: Build a VPC-native GKE cluster configuration step-by-step. You will first define the network and subnetwork, then configure the IP ranges, create the cluster with VPC-native settings, and finally enable the cluster's IP aliasing feature.

📋 What You'll Learn

Create a VPC network named gke-vpc-network

Create a subnetwork named gke-subnet in region us-central1 with IP range 10.0.0.0/16

Define secondary IP ranges for pods and services

Create a GKE cluster named vpc-native-cluster using the VPC-native IP aliasing

Enable IP aliasing in the cluster configuration

💡 Why This Matters

🌍 Real World

VPC-native GKE clusters improve network scalability and management by assigning IP addresses to pods from VPC secondary ranges, avoiding IP conflicts and simplifying routing.

💼 Career

Understanding VPC-native GKE networking is essential for cloud engineers and DevOps professionals managing scalable Kubernetes clusters on Google Cloud.

1

Create the VPC network and subnetwork

Create a VPC network called gke-vpc-network with autoCreateSubnetworks set to false. Then create a subnetwork called gke-subnet in region us-central1 with IP range 10.0.0.0/16.

GCP

# Create VPC network 'gke-vpc-network' with autoCreateSubnetworks false
# Create subnetwork 'gke-subnet' in 'us-central1' with IP range '10.0.0.0/16'

Hint

Use google_compute_network resource for the VPC and google_compute_subnetwork for the subnet.

2

Define secondary IP ranges for pods and services

Add two secondary IP ranges to the gke-subnet: one named pods with IP range 10.4.0.0/14 and another named services with IP range 10.8.0.0/20.

GCP

resource "google_compute_network" "gke_vpc_network" {
  name                    = "gke-vpc-network"
  auto_create_subnetworks = false
}

resource "google_compute_subnetwork" "gke_subnet" {
  name          = "gke-subnet"
  ip_cidr_range = "10.0.0.0/16"
  region        = "us-central1"
  network       = google_compute_network.gke_vpc_network.id
  # Add secondary IP ranges for pods and services here
}

Hint

Use secondary_ip_range blocks inside the google_compute_subnetwork resource.

3

Create the GKE cluster with VPC-native IP aliasing

Create a GKE cluster resource named vpc-native-cluster in region us-central1 that uses the gke-subnet and enables IP aliasing with the secondary ranges pods and services.

GCP

resource "google_container_cluster" "vpc_native_cluster" {
  name     = "vpc-native-cluster"
  location = "us-central1"
  network  = google_compute_network.gke_vpc_network.id
  subnetwork = google_compute_subnetwork.gke_subnet.name
  # Enable IP aliasing and configure cluster networking here
}

Hint

Use the ip_allocation_policy block inside the cluster resource to enable IP aliasing.

4

Enable the cluster's IP aliasing feature

Add the final configuration line enable_ip_alias = true inside the google_container_cluster resource vpc_native_cluster to explicitly enable IP aliasing.

GCP

resource "google_container_cluster" "vpc_native_cluster" {
  name       = "vpc-native-cluster"
  location   = "us-central1"
  network    = google_compute_network.gke_vpc_network.id
  subnetwork = google_compute_subnetwork.gke_subnet.name

  ip_allocation_policy {
    use_ip_aliases                = true
    cluster_secondary_range_name  = "pods"
    services_secondary_range_name = "services"
  }
  # Add enable_ip_alias = true here
}

Hint

Add enable_ip_alias = true inside the google_container_cluster resource.

Practice

1. What does enabling VPC-native mode in GKE do for your cluster's pods?

easy

A. Uses external IP addresses for pods by default

B. Assigns IP addresses to pods from the VPC network's secondary IP ranges

C. Disables network isolation between pods

D. Requires manual IP address assignment for each pod

Solution

1. Step 1: Understand VPC-native mode purpose

   VPC-native mode allows pods to get IPs from the VPC network's secondary IP ranges instead of using NAT or external IPs.

2. Step 2: Identify pod IP assignment behavior

   Pods receive IP addresses from the VPC's secondary IP ranges, enabling better network control and integration.

3. Final Answer:

   Assigns IP addresses to pods from the VPC network's secondary IP ranges -> Option B

4. Quick Check:

   VPC-native pods get IPs from VPC secondary ranges [OK]

Hint: Remember pods get IPs from VPC secondary ranges in VPC-native mode [OK]

Common Mistakes:

• Thinking pods use external IPs by default
• Assuming manual IP assignment is needed
• Believing network isolation is disabled

2. Which gcloud command flag enables VPC-native mode when creating a GKE cluster?

easy

A. --enable-network-alias

B. --enable-vpc-native

C. --enable-ip-alias

D. --use-secondary-ip

Solution

1. Step 1: Recall the flag for VPC-native mode

   The correct flag to enable VPC-native mode is --enable-ip-alias when creating the cluster.

2. Step 2: Verify other options

   Other options like --enable-vpc-native or --use-secondary-ip are incorrect or do not exist.

3. Final Answer:

   --enable-ip-alias -> Option C

4. Quick Check:

   Enable VPC-native with --enable-ip-alias [OK]

Hint: Use --enable-ip-alias to activate VPC-native mode [OK]

Common Mistakes:

• Using non-existent flags like --enable-vpc-native
• Confusing flag names with similar terms
• Omitting the flag entirely

3. Given this command snippet:

gcloud container clusters create my-cluster \
  --enable-ip-alias \
  --create-subnetwork name=my-subnet,range=10.0.0.0/24 \
  --cluster-secondary-range-name=pods-range \
  --services-secondary-range-name=services-range

What is the purpose of specifying --cluster-secondary-range-name?

medium

A. Defines the IP range for the cluster's nodes

B. Sets the IP range for external load balancers

C. Allocates IP range for Kubernetes services

D. Specifies the IP range for pods in the cluster

Solution

1. Step 1: Understand secondary IP ranges in VPC-native

   In VPC-native clusters, secondary IP ranges are used to assign IPs to pods and services separately.

2. Step 2: Identify the role of cluster-secondary-range-name

   The --cluster-secondary-range-name flag specifies the secondary IP range used for pods.

3. Final Answer:

   Specifies the IP range for pods in the cluster -> Option D

4. Quick Check:

   Cluster secondary range = pod IP range [OK]

Hint: Cluster secondary range is for pods, services range is for services [OK]

Common Mistakes:

• Confusing pod IP range with node IP range
• Mixing up services and pods secondary ranges
• Assuming it sets external IP ranges

4. You created a GKE cluster with --enable-ip-alias but pods cannot reach services in the same cluster. What is a likely cause?

medium

A. Secondary IP ranges for pods and services were not properly configured

B. The cluster was created without a node pool

C. The VPC network has no firewall rules allowing pod traffic

D. The cluster is missing a public IP address

Solution

1. Step 1: Check VPC-native setup requirements

   VPC-native clusters require properly configured secondary IP ranges for pods and services to communicate.

2. Step 2: Identify common misconfiguration

   If pods cannot reach services, it often means the secondary IP ranges were not set or assigned correctly.

3. Final Answer:

   Secondary IP ranges for pods and services were not properly configured -> Option A

4. Quick Check:

   Pod-service reachability needs correct secondary IP ranges [OK]

Hint: Check secondary IP ranges if pods can't reach services [OK]

Common Mistakes:

• Assuming missing node pool causes pod-service issues
• Thinking public IP is needed for internal pod communication
• Ignoring firewall rules impact on pod traffic

5. You want to create a GKE cluster with VPC-native networking that supports up to 1000 pods per node. Which configuration is necessary?

hard

A. Use --enable-ip-alias with a large enough secondary IP range for pods per node

B. Assign external IPs to pods and increase node IP range

C. Disable IP aliasing and use NAT for pod IPs

D. Create multiple clusters each with small pod IP ranges

Solution

1. Step 1: Understand pod IP allocation in VPC-native mode

   Pods get IPs from the secondary IP range assigned to the cluster. To support many pods per node, the secondary range must be large enough.

2. Step 2: Identify correct configuration for high pod density

   Using --enable-ip-alias with a sufficiently large secondary IP range allows scaling pods per node without IP conflicts.

3. Final Answer:

   Use --enable-ip-alias with a large enough secondary IP range for pods per node -> Option A

4. Quick Check:

   Large secondary IP range + --enable-ip-alias = high pod density [OK]

Hint: Large secondary IP range needed for many pods per node [OK]

Common Mistakes:

• Assigning external IPs to pods unnecessarily
• Disabling IP aliasing reduces pod IP control
• Splitting pods across clusters instead of scaling IP range