ExamFinch.com My Study

Study guide

13.3 GKE Workload Controllers and Gateway Routing

Practice this exam

Google Cloud Professional Cloud Developer Exam

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: Exam and Compute Platform Decisions

1.1 Current Exam, Sources, and Scenario Method 1.2 Cloud Run Execution and Platform Selection 1.3 GKE Modes and Compute Engine Trade-offs

2 Chapter 2: Container Engineering and API Contracts

2.1 Stateless Microservices and Multi-stage Builds 2.2 Container Hardening, Signals, and Layer Caching 2.3 REST, gRPC, and Protobuf Contracts

3 Chapter 3: gRPC Compatibility and Geographic Routing

3.1 Schema Evolution and gRPC Routing 3.2 Geography, Network Tiers, and Load Balancers 3.3 Serverless NEGs, Sessions, and Edge Controls

4 Chapter 4: API Management and Caching

4.1 API Management & Rate Limiting with Apigee and API Gateway 4.2 Memorystore and Cache Access Patterns 4.3 Cache Invalidation, Capacity, and Failover

5 Chapter 5: Messaging, Task Dispatch, and Orchestration

5.1 Event-Driven Messaging with Cloud Pub/Sub 5.2 Task Queues & Rate Throttling with Cloud Tasks 5.3 Event Routing and Service Orchestration: Eventarc & Cloud Workflows

6 Chapter 6: Resilience and Relational Availability

6.1 Designing Resilient Systems: Circuit Breaking, Retries & Failover 6.2 Cloud SQL Availability and Recovery 6.3 Connection Budgets and Spanner Consistency

7 Chapter 7: Distributed Schemas and NoSQL Data Models

7.1 Spanner Keys, Indexes, and Transactions 7.2 Firestore Data, Indexes, and Transactions 7.3 Bigtable Row Keys and Replication

8 Chapter 8: Object Storage and Application Identity

8.1 Cloud Storage Lifecycle and Signed Access 8.2 Workload Identity and Service Authentication 8.3 Secret Delivery, Rotation, and IAP

9 Chapter 9: Security, Data Integration, and Developer Credentials

9.1 Private Communication, Key Rotation, and Vulnerability Response 9.2 AlloyDB Schemas and BigQuery Ingestion 9.3 CLI Configurations, Local ADC, and Cloud Shell

10 Chapter 10: Managed Development and Automated Tests

10.1 Cloud Workstations and the Container Inner Loop 10.2 Emulating Google Cloud Services & Database Auth Proxies 10.3 Automated Testing Strategies: Unit, Integration, and Mocking

11 Chapter 11: AI Development Tools and Build Pipelines

11.1 AI Coding Assistants, Context, MCP, and Test Review 11.2 Cloud Build Workers and Step Dependencies 11.3 Builders, Substitutions, Triggers, and IAM

12 Chapter 12: Artifact Security and Admission Policies

12.1 Artifact Management and Vulnerability Scanning with Artifact Registry 12.2 Build Provenance and Admission Concepts 12.3 Attestors, Policy Enforcement, and Break-glass

13 Chapter 13: Cloud Run and GKE Deployment Configuration

13.1 Cloud Run Deployment and Scaling Configuration 13.2 Cloud Run CPU, Private Egress, and Secrets 13.3 GKE Workload Controllers and Gateway Routing

14 Chapter 14: Kubernetes Resources, Health, and Progressive Releases

14.1 GKE Resources, OOM Diagnosis, and Autoscaling 14.2 Container Health Probes, Lifecycle Hooks & Graceful Shutdown 14.3 Progressive Delivery: Traffic Splitting, Canary, and Blue/Green Rollouts

15 Chapter 15: Source/Event Deployment and Cloud API Integration

15.1 Source Deployment, Event Receivers, and API Versions 15.2 Client Libraries, Service Enablement, and ADC 15.3 API Responses, Pagination, Caches, and Retries

16 Chapter 16: Tracing, Sampling, and Monitoring

16.1 Trace Context and OpenTelemetry Export 16.2 Custom Spans, Trace Analysis, and Sampling 16.3 Application Metrics, Health Checks & Alerting with Cloud Monitoring

17 Chapter 17: Structured Logs, Routing, and Error Management

17.1 Structured Logs, Trace Correlation, and Queries 17.2 Log Routing, Export Destinations, and Exclusions 17.3 Error Reporting Formats and Regression Handling

18 Chapter 18: Profiling, Generative AI, and Assisted Troubleshooting

18.1 Cloud Profiler Types and Flame Graph Analysis 18.2 Generative AI Integration with the Google Gen AI SDK 18.3 Evidence-Based Troubleshooting with AI Assistance

13.3 GKE Workload Controllers and Gateway Routing

Key Takeaways Explain This Topic AI

Deployments manage replaceable replicas; StatefulSets preserve ordinal identity and volume bindings.

Gateway and HTTPRoute separate infrastructure ownership from application routing.

Cross-namespace route attachment and backend access need the appropriate allowedRoutes and ReferenceGrant controls.

Last updated: October 2026

Kubernetes Workload Configuration on GKE

Google Kubernetes Engine (GKE) is Google Cloud's enterprise-grade, managed Kubernetes service. GKE automates cluster provisioning, control plane upgrades, node auto-repair, and autoscaling while exposing the full power of the open-source Kubernetes API. In cloud-native microservices architectures, developers must properly declare workload controllers, configure network connectivity, enforce compute resource boundaries, and implement dynamic autoscaling policies.

For the Google Cloud Professional Cloud Developer exam, you must understand the operational distinctions between Kubernetes workload controllers, how resource requests and limits dictate Quality of Service (QoS), how to diagnose container eviction failures such as OOMKilled , and how GKE autoscalers interact.

Kubernetes Workload Primitives: Deployments, StatefulSets & DaemonSets

Kubernetes organizes container workloads into distinct controller types based on statefulness and scheduling requirements:

Controller Type Identity & Storage Characteristics Scaling & Rollout Semantics Primary Production Use Cases

Deployment Ephemeral pod names (e.g., web-574f8-x9k2p ); pods share storage or operate statelessly Replicas scale arbitrarily; rolling updates replace pods concurrently Stateless HTTP REST microservices, web frontends, event consumers

StatefulSet Stable ordinal hostnames ( db-0 , db-1 ); dedicated PersistentVolume per pod ordinal Ordered creation/scaling by default; rolling updates and scale-down normally proceed from the highest ordinal. Policies can alter behavior Distributed databases (Cassandra, MongoDB, CockroachDB), Kafka, ZooKeeper

DaemonSet Exactly one pod scheduled per eligible node; auto-scales with node pool size Replaced node-by-node during upgrades Host logging agents (Fluentbit), monitoring collectors (Prometheus Node Exporter), CNI network daemons

StatefulSets in Production

A StatefulSet guarantees identity persistence across pod restarts and rescheduling. Even if db-1 is evicted and rescheduled onto a completely different node, it retains its hostname ( db-1.cassandra.prod.svc.cluster.local ) and automatically rebinds to its specific PersistentVolume provisioned via volumeClaimTemplates : apiVersion: apps/v1

kind: StatefulSet

metadata:

name: cassandra-node

spec:

  • serviceName: cassandra-headless
  • replicas: 3

selector:

matchLabels:

app: cassandra

template:

metadata:

labels:

app: cassandra

spec:

containers:

  • name: cassandra
  • image: cassandra:5.0

ports:

  • containerPort: 9042
  • name: cql

volumeMounts:

  • name: cassandra-data
  • mountPath: /var/lib/cassandra

volumeClaimTemplates:

- metadata:

name: cassandra-data

spec:

  • accessModes: [ "ReadWriteOnce" ]
  • storageClassName: premium-rwo

resources:

requests:

  • storage: 200Gi
  • Kubernetes Networking: Services, Ingress & Gateway API

Pods are ephemeral with dynamic private IP addresses that change across recreations. Kubernetes provides abstraction layers for service discovery and external ingress.

Service Types

ClusterIP (Default): Exposes the Service on a cluster-internal virtual IP. Reachable only within the cluster or via internal mesh proxies.

NodePort: Exposes the Service on a static high-range port ( 30000-32767 ) across every node IP in the cluster. Traffic sent to <NodeIP>:<NodePort> is forwarded to matching pods.

LoadBalancer: Automatically provisions a Google Cloud Passthrough Network Load Balancer (Layer 4) with an external or internal static IP address, forwarding raw TCP/UDP traffic directly to backend pods.

GKE Ingress vs. Gateway API

While Kubernetes Ingress has historically configured Google Cloud External Application Load Balancers (Layer 7 HTTP/HTTPS) via the GKE Ingress Controller, modern cloud-native architectures on GKE leverage the Gateway API ( gateway.networking.k8s.io/v1 ). ## Gateway: Managed by Platform / Infrastructure Administrators

  • apiVersion: gateway.networking.k8s.io/v1
  • kind: Gateway

metadata:

  • name: prod-external-gateway
  • namespace: gateway-infra

spec:

gatewayClassName: gke-l7-global-external-managed

listeners:

  • name: https
  • protocol: HTTPS
  • port: 443

allowedRoutes:

namespaces:

from: All

tls:

mode: Terminate

certificateRefs:

  • name: wild-corp-cert
  • --
  • ## HTTPRoute: Managed by Application Developers
  • apiVersion: gateway.networking.k8s.io/v1
  • kind: HTTPRoute

metadata:

  • name: payment-route
  • namespace: payments

spec:

parentRefs:

  • name: prod-external-gateway
  • namespace: gateway-infra

hostnames:

- "api.company.com"

rules:

- matches:

- path:

  • type: PathPrefix
  • value: /v2/payments

backendRefs:

  • name: payment-service-v2
  • port: 8080
  • weight: 90
  • name: payment-service-v2-canary
  • port: 8080
  • weight: 10

Architectural Advantages of Gateway API over Ingress:

Role-Oriented Separation: Infrastructure engineers provision the Gateway (listeners, TLS certificates, IP allocations), while application developers define HTTPRoute rules independently without needing cluster admin rights.

Native Traffic Splitting: Supports percentage-based canary weighting directly in backendRefs without custom vendor annotations.

Cross-Namespace Routing: Allows routes in different application namespaces to bind cleanly to a central shared gateway.

Routing Ownership and Trust

The Gateway example permits routes from all namespaces for illustration. In production, use a narrower namespace selector and RBAC so only authorized application teams can attach routes. A cross-namespace backend reference also needs the appropriate ReferenceGrant; allowing a route to attach to a Gateway does not grant unrestricted access to every backend Service.

The TLS certificate reference must exist in the supported location, the hostname must match, and the route must report accepted/resolved status. Investigate those status conditions before changing Pod CPU limits when a new route returns errors. Readiness, backend health checks and route acceptance are separate observations. For gRPC, configure the controller's supported backend protocol explicitly rather than assuming an HTTP route automatically enables every form of streaming or cleartext HTTP/2.