TLS and Cloud Armor protect the request before it reaches a Pod

The managed frontend terminates TLS, evaluates edge security, chooses a route and forwards only to a healthy NEG endpoint.

1TLS handshakeCertificate Manager proves the Shopwave hostname.

2Cloud ArmorWeb application firewall and rate rules evaluate the request.

3URL mapGateway and HTTPRoute configuration choose the backend.

4Health-aware backendThe load balancer chooses a healthy zonal NEG.

5Podcheckout receives the request on its declared target port.

Edge policy reduces malicious traffic; workload authorization still decides what the caller may do.

TLS and Cloud Armor protect the request before it reaches a Pod

Secured request path is easiest to understand by separating the Kubernetes contract from the Google Cloud implementation. GKE Gateway is a control-plane API. The actual traffic path is the Cloud Load Balancer frontend, certificate, security policy, URL map, backend service and NEG endpoint. 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 `gcloud compute backend-services get-health BACKEND --global`. 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: A WAF is not application authorization and a valid certificate is not proof that the backend is healthy. The safe habit is to verify quotas, regional availability and feature support against current Google Cloud documentation before rollout. Multi-cluster Gateways expand the backend set.