13.3 GKE Workload Controllers and Gateway Routing

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:

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:

1. 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.
2. Native Traffic Splitting: Supports percentage-based canary weighting directly in backendRefs without custom vendor annotations.
3. 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.