GKE networking (VPC-native) in GCP - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding VPC-native Clusters in GKE

What is the main advantage of using a VPC-native (alias IP) cluster in Google Kubernetes Engine (GKE)?

A Pods share the node IP addresses, reducing IP address usage.

B Pods get IP addresses from the VPC subnet, enabling direct communication with other VPC resources without NAT.

C Pods are isolated in a separate network and cannot communicate with VPC resources.

D Pods use external IP addresses to communicate with the internet directly.

💡 Hint

Think about how pods communicate with other resources inside the same network.

VPC-native clusters assign pods IP addresses from the VPC subnet using alias IPs. This allows pods to communicate directly with other VPC resources without needing network address translation (NAT), improving network efficiency and security.

❓ Architecture

intermediate

Configuring Subnets for VPC-native GKE Clusters

You want to create a VPC-native GKE cluster. Which subnet configuration is required for the cluster's pod IP range?

A Create a secondary IP range in the VPC subnet dedicated for pods, separate from the primary IP range used by nodes.

B Use the primary IP range of the subnet for both nodes and pods without any secondary ranges.

C Use a separate VPC network exclusively for pods.

D Assign pod IPs from an external IP range outside the VPC subnet.

💡 Hint

Consider how GKE manages IP address allocation for pods and nodes within the same subnet.

VPC-native clusters require a secondary IP range in the subnet to allocate IPs to pods. The primary IP range is reserved for nodes, and the secondary range is dedicated to pods to avoid IP conflicts.

❓ security

advanced

Securing Pod Communication in VPC-native GKE Clusters

In a VPC-native GKE cluster, which method best restricts pod-to-pod communication across namespaces for security purposes?

A Use Kubernetes Network Policies to define allowed traffic between pods in different namespaces.

B Disable VPC-native mode to isolate pods by default.

C Assign unique external IPs to pods and use firewall rules to restrict traffic.

D Use node-level firewall rules to block pod communication.

💡 Hint

Think about Kubernetes-native ways to control pod traffic.

Kubernetes Network Policies allow fine-grained control over pod communication, including restricting traffic between pods in different namespaces. This is the recommended way to secure pod traffic in VPC-native clusters.

❓ service_behavior

advanced

Behavior of Services with VPC-native Clusters

What happens when you create a LoadBalancer type Service in a VPC-native GKE cluster?

A The Service cannot be created because LoadBalancer type is unsupported in VPC-native clusters.

B The Service uses node IPs only, ignoring pod IPs for backend endpoints.

C GKE provisions a cloud load balancer with backend endpoints using pod IPs from the VPC subnet.

D The Service automatically assigns external IPs to pods.

💡 Hint

Consider how pod IPs are used in load balancing within VPC-native clusters.

In VPC-native clusters, LoadBalancer Services create cloud load balancers that use pod IPs from the VPC subnet as backend endpoints, enabling direct routing to pods.

✅ Best Practice

expert

Optimizing IP Address Usage in Large VPC-native GKE Clusters

You manage a large VPC-native GKE cluster with many nodes and pods. What is the best practice to optimize IP address usage and avoid exhaustion?

A Assign a large secondary IP range to the subnet and disable autoscaling to keep pod count stable.

B Create multiple VPC networks and split the cluster across them to increase IP availability.

C Use the primary IP range for pods to maximize available IPs and avoid secondary ranges.

D Configure smaller secondary IP ranges per subnet and enable cluster autoscaling to manage pod density per node.

💡 Hint

Think about balancing IP allocation and cluster scaling.

Using smaller secondary IP ranges helps control IP allocation per subnet. Combined with cluster autoscaling, this approach manages pod density efficiently and prevents IP exhaustion.

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