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.