One HTTPS listener can route checkout and catalog by path

The platform Gateway accepts shopwave.example on 443. The application HTTPRoute sends /checkout and /catalog to separate Services.

Gateway listener

HTTPS on 443 with an allowed route namespace policy.

Certificate map

Certificate Manager supplies the frontend certificate through GKE policy integration.

HTTPRoute rules

PathPrefix matches keep application routing readable and versioned.

Backends

Services expose ports; NEGs keep only healthy Pods in rotation.

Keep the route portable and isolate certificate and security policy in provider-specific resources.

One HTTPS listener can route checkout and catalog by path

Worked HTTPS Gateway is easiest to understand by separating the Kubernetes contract from the Google Cloud implementation. A Gateway listener owns hostname, protocol and attachment policy. HTTPRoute rules can match path prefixes and reference Kubernetes Services by name and port. 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 describe gateway shopwave-web -n platform`. 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: Certificate readiness and Gateway programming are asynchronous; do not switch DNS until the address, certificate and backend health are all verified. The safe habit is to verify quotas, regional availability and feature support against current Google Cloud documentation before rollout. The request path adds edge security next.