Cilium Gateway API: Bridging Networks Beyond Envoy Proxies

With Cilium Gateway API, the GatewayClass and the Cilium agent dataplane have to agree on which listeners and address types are actually programmed before application routes matter. Attach routes with parentRefs that match a Ready Gateway listener, keep TLS on the listener (or the upstream LB) consistent across Hosts, and avoid publishing admin or metrics Hosts on the same public listener as app traffic. If you still have classic Ingress objects in the cluster, pin distinct classes so an orphaned Ingress cannot be claimed by the wrong controller while you dual-run.

Ops prove-out after apply: confirm the Gateway shows programmed addresses and Accepted routes, then hit the public Host and expect the upstream status rather than a controller default. If only one Gateway route fails, check Service Endpoints readiness and that the listener port matches what clients dial. When routes flap after a Cilium upgrade, verify the GatewayClass still points at the expected controller name and that NetworkPolicies did not start dropping the node-to-pod path the Gateway uses — most “Gateway stopped working” tickets are parentRef mismatch or empty Endpoints, not the route object shape itself.