Google PCNE: GKE, Containers and Application Networking — Study Guide

By Laurynas Brazys · 22 August 2026 · #google #PCNE #certification #exam-prep #study-guide

Part of the Google Professional Cloud Network Engineer — Study Guide. Practice with verified answers in the Google exam hub, or take timed practice tests on ExamRoll.io.

Overview

Google Kubernetes Engine (GKE) integrates tightly with Google Cloud networking. Designing for reliability and security requires understanding VPC-native IP addressing, private control planes, egress, north–south and east–west traffic, policy enforcement, and multi-cluster constructs. This section provides design guidance, operational reasoning, and common failure modes for containers and application networking on Google Cloud.

GKE IP architecture and private clusters

VPC-native clusters

• Use alias IPs with two secondary ranges in a VPC subnet: one for Pods (PodCIDR) and one for Services (ServiceCIDR). This avoids iptables-based SNAT on nodes, enables container-native load balancing with NEGs, and scales better than routes-based clusters.
• Sizing guidelines:
  • Pods: allocate PodsPerNode × MaxNodes, plus headroom (20–30%). For example, current 10 nodes × 20 Pods + growth to 100 × 200 suggests a /17 Pod range; Services often fit in a /21 for 2K+ services.
  • Services: each ClusterIP consumes one IP; factor in headroom for headless-to-ClusterIP migrations and add-ons.
• Failure modes:
  • Pod IP exhaustion: Pods remain Pending or CNI/IPAM errors appear; scale the secondary Pod range or reduce max pods per node, then recreate nodes.
  • Service IP exhaustion: new Services fail to allocate ClusterIP; expand the Service secondary range.
  • Overlapping alias ranges: cluster creation fails or routing blackholes occur; validate no overlap with other subnets or peered VPCs.

Private clusters, control plane access, and node egress

• Private clusters restrict the control plane endpoint to a private RFC1918 address reachable only from your VPC via producer peering. Nodes do not require external IPs.
• For operators, choose:
  • Private endpoint only: control plane reachable from VPC subnets and connected networks. Use bastion or Cloud Shell with Private Service Connect to reach it.
  • Public endpoint with Authorized Networks: expose the control plane on a public IP gated by specific source CIDRs. This is convenient but increases exposure; use only with tight CIDR scoping and strong admin identity controls.
• Node egress:
  • For nodes without external IPs, provide internet-bound egress via Cloud NAT. This allows OS updates, container image pulls from external registries, and partner API access while keeping nodes private.
  • For access to Google APIs and Artifact/Container Registry without external IPs, enable Private Google Access (PGA) on node subnets. PGA resolves and routes Google APIs/registry traffic to Google’s edge without public source IPs. PGA is preferred for image pulls; combine with Cloud NAT if non-Google egress is also required.
  • If sending 0.0.0.0/0 through a third-party firewall, still enable PGA and add static routes for Google APIs VIP ranges to the default internet gateway to bypass the firewall for Google services.

Scaling and IP troubleshooting

• Monitor alias IP consumption at the subnet secondary range level. If IP pressure rises:
  • Increase the secondary range sizes (add larger ranges, recreate cluster or migrate workloads where required).
  • Tune max-pods-per-node to balance IP use per node versus scheduling fragmentation.
  • Prune abandoned Services; headless Services do not allocate ClusterIPs, but converting to ClusterIP will consume IPs.
• Plan for multi-region growth with non-overlapping secondary ranges to avoid re-IP when using Shared VPCs, VPC Peering, or multi-cluster services.

Ingress, Gateway API, Services, and policies

Services and load balancers

• Service types:
  • ClusterIP: in-cluster access only; east–west traffic uses kube-proxy or dataplane v2.
  • NodePort: allocates a port on each node; used by many LBs as a backend but avoid exposing directly on the internet.
  • LoadBalancer: provisions a cloud load balancer. External or internal L4 load balancers support TCP/UDP; session affinity ClientIP provides stickiness across multiple protocols when required.
• Container-native load balancing uses Network Endpoint Groups (NEGs) so the load balancer targets Pod IP:ports directly, improving health signaling and reducing node hops. For GKE, use GKE Pod NEGs (GCE_POD). Other NEG types include VM_IP_PORT, Internet FQDN, and PSC.
• GKE Ingress and Gateway API:
  • Ingress is stable for HTTP(S) north–south with Google’s global external HTTP(S) load balancer or regional internal HTTP(S) load balancer. The controller programs health checks and firewall rules automatically for standard patterns.
  • Gateway API provides a more expressive model with Gateways and HTTPRoutes/TCPRoutes. It supports multi-tenant configs, advanced routing, and a consistent spec across environments. Choose Gateway API for future-proofing; use Ingress where simplicity and compatibility matter.

Client restriction and health checks

• Restricting clients to specific source ranges can be done at L4 with VPC firewall rules targeting backend instances or at L7 with Cloud Armor policies on HTTP(S) load balancers.
• Always allow Google health checker source ranges to backend targets or Pods so health checks pass. In some deployments, GKE auto-creates k8s-fw rules; if you add restrictive rules, keep explicit allows for the health checker ranges.
• Example approach for L4 backends: tag nodes with “application” and create an allow firewall rule for tcp:NodePort from allowed client CIDRs and Google health check ranges, and a higher-priority deny for all other sources with logging to observe drops.

Network policies and dataplane v2

• Enable Kubernetes NetworkPolicy and use GKE Dataplane V2 for eBPF-based enforcement, improving performance and fidelity versus iptables-based engines.
• Baseline posture:
  • Default deny egress and ingress for namespaces; explicitly allow Pod-to-Pod and Pod-to-Service flows.
  • Use namespace and podSelectors to create service tiers (frontend, backend, data) and only permit the minimum necessary directions and ports.
• Secure service communication:
  • For in-cluster zero trust, mTLS is best delivered by a service mesh; NetworkPolicy handles L3/L4 and cannot authenticate identities.
  • For north–south, attach Cloud Armor to HTTP(S) LBs for WAF, rate limiting, and preview mode to test a deny on suspected attackers without disrupting users.

Failure modes and trade-offs

• Too many or overly broad NetworkPolicies can cause unexpected drops; validate with staged rollouts, logging, and policy explain tools.
• Relying on NodePort plus external firewall rules is brittle; prefer managed load balancers and Pod NEGs.
• Gateway API brings richer features but requires controller maturity and team familiarity; validate features like header-based routing or mTLS passthrough per release channel.

Multi-cluster, service mesh, and identity

Multi-cluster services and fleet networking

• Register clusters in a fleet to use Multi-Cluster Services (MCS) for cross-cluster service discovery and load balancing. Export services from each cluster; clients resolve a single DNS name backed by endpoints across clusters.
• Cross-cluster traffic patterns:
  • Same VPC, different subnets: traffic flows over private RFC1918 with optimal cost and latency.
  • Different VPCs: connect with VPC Peering for private, simple connectivity without transitivity, or use Cloud VPN/Cloud Router if organizations differ or encryption is required over the internet. For centralized administration, Shared VPC exposes only needed subnets to service projects.
• Failure modes:
  • Overlapping CIDRs block routing; ensure non-overlap across PodCIDR and ServiceCIDR before peering or VPN.
  • DNS split-horizon issues can break cross-cluster resolution; validate search paths and stub domains.

Service mesh, east–west, and observability

• Deploy a service mesh such as Anthos Service Mesh for:
  • mTLS with strong workload identity, traffic policy (retries, timeouts, outlier detection), and traffic splitting.
  • Consistent east–west policy across clusters with mesh federation or multi-primary topologies.
  • Rich telemetry: golden signals per workload, request traces, and policy audits.
• Trade-offs:
  • Sidecars increase resource overhead; ambient or sidecarless modes can reduce cost but validate feature parity.
  • Mesh adds control plane dependencies; design for HA control planes and graceful degradation.

Workload identity, secrets, and least privilege

• Use Workload Identity to map Kubernetes Service Accounts (KSAs) to Google service accounts (GSAs), eliminating long-lived keys. Annotate the KSA with the GSA email and grant minimal IAM roles to the GSA.
• Secrets management:
  • Prefer Secret Manager with the CSI driver to mount secrets at runtime; remove plain Kubernetes Secrets for sensitive data or encrypt them at rest with CMEK if retained.
  • Grant least-privilege access to secrets and buckets at the GSA. Avoid project-wide roles; scope to resource-level roles like storage.objectViewer when applicable.

Resilience and secure platform design considerations

• Regional clusters for high availability; spread nodes across zones. For north–south, use global HTTP(S) load balancing for lowest latency to global users.
• Control plane connectivity: choose private control planes; avoid public exposure unless strictly necessary with Authorized Networks.
• Egress: nodes without external IPs plus Cloud NAT and PGA balance security and functionality.
• Observability: enable firewall logging, VPC Flow Logs, and mesh telemetry to quickly diagnose policy drops or latency spikes.

Practical Problem Scenario

Contoso Retail operates two private GKE regional clusters in us-east1 and europe-west1. Requirements: no external IPs on nodes, secure ingress limited to corporate CIDRs, global availability for a storefront service, image pulls without internet exposure, and cross-cluster failover for the API tier. They previously hit Pod IP exhaustion during a surge.

Approach

1. Design VPC-native subnets with generous secondary ranges.

   • Rationale: Allocate a /17 Pod range and /21 Service range per region to cover 100 nodes × 200 Pods/node and 1,500 services with 20–30% headroom. This prevents recurrence of Pod IP exhaustion and avoids re-IP during growth.

2. Create private clusters with private control plane endpoints.

   • Rationale: Limits control plane exposure to the VPC. Operators connect via a bastion on a management subnet. This reduces the attack surface compared to public endpoints with Authorized Networks.

3. Enable Cloud NAT and Private Google Access on node subnets.

   • Rationale: Nodes have no external IPs but still need to pull images from Artifact Registry and reach OS/package mirrors. PGA ensures Google API access without public source IPs; Cloud NAT handles non-Google egress as needed.

4. Implement global HTTP(S) ingress using Gateway API with Pod NEGs.

   • Rationale: A single global anycast VIP reduces latency for worldwide users. GKE Pod NEGs send health checks directly to Pods and improve failure detection. Gateway API provides a clean separation between infra Gateways and app-owned Routes.

5. Restrict client access and permit health checks.

   • Rationale: Attach a Cloud Armor policy to allow only corporate CIDRs, with a default deny and preview mode to evaluate new blocks safely. Additionally, ensure VPC firewall rules permit Google health check source ranges to backend NEGs so health checks remain green.

6. Apply NetworkPolicy with GKE Dataplane V2.

   • Rationale: Default-deny ingress and egress per namespace; allow only frontend-to-backend and backend-to-database ports. Dataplane V2 enforces policies efficiently with eBPF, shrinking blast radius for compromised Pods.

7. Enable Multi-Cluster Services across the fleet.

   • Rationale: Export the API service in both regions and publish a single DNS. Clients automatically fail over to healthy endpoints across clusters. Because both clusters are in the same VPC with regional subnets, cross-region traffic stays private and incurs minimal overhead.

8. Adopt a service mesh for east–west security and observability.

   • Rationale: Enforce mTLS between services, add retry/timeout budgets, and get per-route metrics and traces. Mesh-level policy complements NetworkPolicy: NetworkPolicy gates L3/L4 reachability; mesh authenticates and authorizes service identities at L7.

9. Harden workload identities and secrets.

   • Rationale: Map KSAs to narrowly scoped GSAs via Workload Identity; grant only necessary roles such as storage.objectViewer for report fetchers. Deliver credentials through Secret Manager CSI to avoid static secrets in manifests.

10. Implement capacity and logging guardrails.

    • Rationale: Set max-pods-per-node thoughtfully to balance IP usage. Monitor secondary range utilization and VPC Flow Logs. Create an explicit high-priority deny-all firewall rule with logging on the application tag to surface unintended client traffic while preserving allowed paths.

This design yields private-by-default clusters with controlled north–south access, resilient multi-cluster failover, principled least-privilege identity, and a dataplane that scales without recurring IP exhaustion.

← Routing · All domains · Network Observability →

Practice these questions → · Timed practice on ExamRoll.io →

Browse Google →