GatewayClass chooses infrastructure; HTTPRoute chooses application behavior

The resource chain deliberately divides cluster-wide infrastructure decisions from namespace-scoped routing changes.

1GatewayClassGoogle-provided class maps to a Cloud Load Balancer type.

2GatewayPlatform team declares listeners, addresses and accepted routes.

3HTTPRouteApplication team declares hosts, paths, filters and backends.

4ServiceStable Kubernetes backend selected by the route.

5NEG PodsHealthy Pod endpoints receive the request directly.

Portability is strongest in HTTPRoute; certificates and provider policy remain cloud-specific edges.

GatewayClass chooses infrastructure; HTTPRoute chooses application behavior

Gateway resource model is easiest to understand by separating the Kubernetes contract from the Google Cloud implementation. GatewayClass is cluster-scoped, Gateway represents an actual traffic-handling instance, and HTTPRoute attaches application routing to a listener. The Kubernetes objects stay familiar, but GKE supplies controllers, infrastructure and safe defaults around them. This is why a team can move from an on-premises cluster without rewriting every workload, while still needing to redesign networking, identity and operational ownership for the cloud environment.

A useful inspection step is `kubectl get gatewayclass,gateway,httproute -A`. Read the output as evidence, not as a ritual: first confirm the desired object exists, then look at status conditions, events and the Google Cloud resource it represents. In production, capture the expected result in a runbook or automated check so an operator can distinguish slow reconciliation from a configuration error.

Production gotcha: Accepted and Programmed conditions show controller progress, but you must still validate the created load balancer and an end-to-end request. The safe habit is to verify quotas, regional availability and feature support against current Google Cloud documentation before rollout. The next slide selects the correct GKE class.