GKE networking (VPC-native) in GCP - Commands & Configuration

Introduction

When you create a Kubernetes cluster on Google Cloud, you need to connect it to a network. VPC-native networking lets your cluster use the Google Cloud Virtual Private Cloud (VPC) network directly. This makes communication between your cluster and other resources safer and simpler.

When you want your Kubernetes pods to have IP addresses from your VPC network.

When you need your cluster to communicate securely with other Google Cloud services in the same VPC.

When you want to avoid IP conflicts by using alias IP ranges for pods.

When you want to manage network policies and firewall rules at the VPC level.

When you want better scalability and easier network management for your cluster.

Config File - cluster-config.yaml

cluster-config.yaml

apiVersion: container.cnrm.cloud.google.com/v1beta1
kind: ContainerCluster
metadata:
  name: example-gke-cluster
spec:
  location: us-central1
  initialNodeCount: 3
  networking:
    networkRef:
      name: default
    ipAllocationPolicy:
      useIpAliases: true
      clusterSecondaryRangeName: pods-secondary-range
      servicesSecondaryRangeName: services-secondary-range
  nodeConfig:
    machineType: e2-medium

This file defines a GKE cluster configuration using VPC-native networking.

• networkRef.name: Uses the default VPC network.
• ipAllocationPolicy.useIpAliases: Enables VPC-native alias IPs for pods.
• clusterSecondaryRangeName: The secondary IP range for pod IPs.
• servicesSecondaryRangeName: The secondary IP range for service IPs.
• nodeConfig.machineType: Sets the machine type for cluster nodes.

Commands

This command creates a new GKE cluster named 'example-gke-cluster' in the 'us-central1-a' zone. It enables VPC-native networking with alias IPs using the specified secondary IP ranges for pods and services. It uses the default VPC network and creates 3 nodes with the machine type e2-medium.

Terminal

gcloud container clusters create example-gke-cluster --zone us-central1-a --enable-ip-alias --cluster-secondary-range-name=pods-secondary-range --services-secondary-range-name=services-secondary-range --network default --num-nodes 3 --machine-type e2-medium

Expected Output

Creating cluster example-gke-cluster in us-central1-a...



Creating node pool default-pool...



Created [https://container.googleapis.com/v1/projects/my-project/zones/us-central1-a/clusters/example-gke-cluster].



To inspect the contents of your cluster, go to: https://console.cloud.google.com/kubernetes/workload_/gcloud/us-central1-a/example-gke-cluster?project=my-project



kubeconfig entry generated for example-gke-cluster.



NAME                  LOCATION       MASTER_VERSION  MASTER_IP       MACHINE_TYPE  NODE_VERSION  NUM_NODES  STATUS

example-gke-cluster    us-central1-a  1.26.8-gke.100  35.233.123.45  e2-medium     1.26.8-gke.100 3          RUNNING

→

--enable-ip-alias - Enables VPC-native alias IPs for pods and services.

→

--cluster-secondary-range-name - Specifies the secondary IP range for pod IPs.

→

--services-secondary-range-name - Specifies the secondary IP range for service IPs.

This command lists the nodes in your GKE cluster to verify that the cluster is running and nodes are ready.

Terminal

kubectl get nodes

Expected Output

NAME                                       STATUS   ROLES    AGE   VERSION

example-gke-cluster-default-pool-1a2b3c   Ready    <none>   2m    v1.26.8-gke.100

This command shows all pods running in the cluster with their IP addresses to confirm pods have IPs from the VPC secondary range.

Terminal

kubectl get pods --all-namespaces -o wide

Expected Output

NAMESPACE     NAME                                    READY   STATUS    RESTARTS   AGE   IP             NODE                                       NOMINATED NODE   READINESS GATES

kube-system   coredns-558bd4d5db-abcde                1/1     Running   0          3m    10.4.0.2       example-gke-cluster-default-pool-1a2b3c   <none>           <none>

→

--all-namespaces - Shows pods in all namespaces.

→

-o wide - Shows extra details including pod IP addresses.

Key Concept

If you remember nothing else from this pattern, remember: VPC-native (alias IP) networking lets your GKE pods get IP addresses directly from your VPC network, making networking simpler and more secure.

Common Mistakes

Not enabling --enable-ip-alias when creating the cluster.

Without this flag, the cluster uses routes-based networking, which is less scalable and can cause IP conflicts.

Always include --enable-ip-alias and specify secondary IP ranges for pods and services.

Using overlapping IP ranges for pod secondary range and existing VPC subnets.

IP conflicts cause pods to fail to get IPs or communicate properly.

Choose unique, non-overlapping secondary IP ranges for pods and services.

Not verifying pod IPs after cluster creation.

You might miss that pods are not using VPC-native IPs, causing network issues.

Run 'kubectl get pods --all-namespaces -o wide' to check pod IP addresses.

Summary

Create a GKE cluster with --enable-ip-alias to use VPC-native networking.

Specify secondary IP ranges for pods and services to avoid IP conflicts.

Verify cluster nodes and pod IPs to confirm VPC-native networking is active.

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