GKE networking (VPC-native) in GCP - Step-by-Step Execution

Process Flow - GKE networking (VPC-native)

Create VPC Network

↓

Enable Alias IP Ranges

↓

Create Subnet with Secondary Ranges

↓

Create GKE Cluster with VPC-native Enabled

↓

Pods get IPs from Secondary Range

↓

Pods communicate using VPC routing

↓

Cluster nodes and Pods share VPC network

This flow shows how a VPC-native GKE cluster is set up to use VPC networking with alias IP ranges, allowing pods to get IPs from a subnet's secondary range and communicate within the VPC.

Execution Sample

GCP

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

This command creates a GKE cluster with VPC-native networking enabled, using a subnet with secondary IP ranges for pods and services.

Process Table

Step	Action	Resource Created/Modified	IP Range Assigned	Result
1	Create VPC network	VPC network 'my-vpc'	10.0.0.0/16	VPC network ready
2	Create subnet with secondary ranges	Subnet 'my-subnet'	Primary: 10.0.0.0/24 Pods: 10.0.1.0/24 Services: 10.0.2.0/24	Subnet with alias IP ranges ready
3	Create GKE cluster with --enable-ip-alias	GKE cluster 'my-cluster'	Pods use 10.0.1.0/24 Services use 10.0.2.0/24	Cluster nodes and pods get IPs from VPC ranges
4	Pods scheduled	Pods in cluster	IPs from 10.0.1.0/24	Pods communicate over VPC network
5	Services created	Kubernetes services	IPs from 10.0.2.0/24	Services reachable inside VPC
6	Cluster running	All resources	N/A	VPC-native networking active

💡 All resources created and pods/services assigned IPs from secondary ranges, enabling VPC-native networking.

Status Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	Final
VPC Network	None	my-vpc (10.0.0.0/16)	my-vpc (10.0.0.0/16)	my-vpc (10.0.0.0/16)	my-vpc (10.0.0.0/16)	my-vpc (10.0.0.0/16)
Subnet	None	None	my-subnet (10.0.0.0/24) with pods 10.0.1.0/24 and services 10.0.2.0/24	my-subnet (10.0.0.0/24) with alias ranges	my-subnet (10.0.0.0/24) with alias ranges	my-subnet (10.0.0.0/24) with alias ranges
Cluster	None	None	None	my-cluster with IP alias enabled	my-cluster running	my-cluster running
Pods IP Range	None	None	None	10.0.1.0/24	Pods assigned IPs in 10.0.1.0/24	Pods assigned IPs in 10.0.1.0/24
Services IP Range	None	None	None	10.0.2.0/24	Services assigned IPs in 10.0.2.0/24	Services assigned IPs in 10.0.2.0/24

Key Moments - 3 Insights

Why do pods get IPs from the secondary range and not the primary subnet range?

Pods get IPs from the secondary range because the cluster is created with --enable-ip-alias and the subnet has secondary IP ranges assigned for pods and services, as shown in execution_table step 3 and 4.

What happens if the subnet does not have secondary IP ranges configured?

Without secondary IP ranges, the cluster cannot assign IPs to pods from the VPC, so VPC-native networking cannot be enabled. This is clear from step 2 where secondary ranges are created before cluster creation.

How do pods communicate with other resources in the VPC?

Pods use IPs from the VPC subnet's secondary range, so they communicate over the VPC network like any other resource, as shown in step 5 and 6.

Visual Quiz - 3 Questions

Look at the execution_table, at which step are pods assigned their IPs from the secondary range?

A Step 2

B Step 3

C Step 4

D Step 5

💡 Hint

Check the 'IP Range Assigned' and 'Result' columns in execution_table rows for pod IP assignment.

According to variable_tracker, what is the state of the subnet after step 2?

A Subnet with secondary ranges for pods and services

B Subnet with primary range only

C Subnet with no secondary ranges

D Subnet deleted

💡 Hint

Look at the 'Subnet' row after 'After Step 2' column in variable_tracker.

If the cluster was created without --enable-ip-alias, how would the execution_table change?

A Pods would get IPs from primary subnet range

B Pods would not get IPs from VPC ranges, breaking VPC-native networking

C Pods would still get IPs from secondary range

D Services would get IPs from secondary range but pods would not

💡 Hint

Refer to the importance of --enable-ip-alias in step 3 of execution_table.

Concept Snapshot

GKE VPC-native networking uses alias IP ranges.
Create a VPC and subnet with secondary IP ranges.
Enable --enable-ip-alias when creating the cluster.
Pods get IPs from secondary ranges, communicating inside VPC.
This improves IP management and network performance.

Full Transcript

This visual execution trace shows how to set up Google Kubernetes Engine (GKE) networking using VPC-native mode. First, a VPC network is created. Then, a subnet is created with secondary IP ranges for pods and services. Next, a GKE cluster is created with the --enable-ip-alias flag, which enables pods to receive IP addresses from the subnet's secondary ranges. Pods and services get IPs from these ranges and communicate over the VPC network. The variable tracker shows how resources and IP ranges evolve step-by-step. Key moments clarify why secondary ranges are needed and how pods communicate. The quiz tests understanding of when pods get IPs, subnet state, and the role of --enable-ip-alias.

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