Kubernetes Gateway Network Path

Kubernetes Gateway Network Path is the sequence of network hops, proxies, and routing decisions that a request traverses when the Gateway API is used to expose services inside a cluster to clients outside of it. It describes how a packet moves from an external client, through a Gateway resource bound to a load balancer or ingress controller, into the data plane proxy instances that implement listeners and routes, and finally to the backend Pod selected by a Kubernetes Service. Unlike the legacy Ingress object, the Gateway API separates infrastructure provisioning (GatewayClass, Gateway) from routing intent (HTTPRoute, TCPRoute, GRPCRoute, TLSRoute), and the network path reflects that separation at every hop.

Gateway API Object Model and the Path

GatewayClass and Gateway

A GatewayClass is a cluster-scoped resource that names a controller implementation (such as Envoy Gateway, Istio, Contour, or a cloud provider's managed gateway controller). A Gateway resource references a GatewayClass and declares one or more listeners, each binding a protocol (HTTP, HTTPS, TLS, TCP, UDP) and port to a hostname pattern. The controller watching that GatewayClass reconciles the Gateway object into concrete infrastructure — typically a LoadBalancer Service, a set of proxy Pods, and firewall or security group rules.

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: public-gateway
  namespace: gateway-infra
spec:
  gatewayClassName: envoy-gateway
  listeners:
    - name: https
      protocol: HTTPS
      port: 443
      hostname: "*.example.com"
      tls:
        mode: Terminate
        certificateRefs:
          - name: example-com-tls

Route Objects and Backend Selection

Route resources such as HTTPRoute attach to a Gateway via a parentRefs field and describe matching rules (path, header, method) plus a backendRefs list pointing at one or more Kubernetes Services. This is the point in the path where routing intent is translated into a concrete Service ClusterIP or set of Endpoints.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: checkout-route
  namespace: shop
spec:
  parentRefs:
    - name: public-gateway
      namespace: gateway-infra
  hostnames:
    - "shop.example.com"
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /checkout
      backendRefs:
        - name: checkout-svc
          port: 8080

Namespace Boundaries and ReferenceGrant

Because a Gateway typically lives in an infrastructure namespace while HTTPRoute objects live alongside application workloads, the path crosses a namespace trust boundary. A ReferenceGrant in the target namespace is required whenever a route or backend reference points across namespaces, otherwise the controller refuses to wire that hop.

Ingress Traffic Path: External Client to Pod

Entry at the Load Balancer

An external request first reaches a cloud load balancer (or a bare-metal equivalent such as MetalLB) that was provisioned by the Gateway controller to satisfy a listener. The load balancer's frontend IP and port map directly to the Gateway listener configuration, and TLS termination — if configured with mode: Terminate — happens either at the load balancer or at the first proxy hop, depending on the implementation.

Proxy Data Plane Hop

Traffic then lands on the data plane proxy (often Envoy) running as a Deployment of Pods dedicated to that Gateway. This proxy evaluates the compiled routing table built from all attached HTTPRoute objects, matches the request against path, header, and hostname rules, and selects a backend cluster corresponding to a Service.

kube-proxy or CNI Dataplane Hop

Once the proxy decides on a backend Service, the request is forwarded to one of the Service's Endpoints. Depending on the CNI and kube-proxy mode in use (iptables, IPVS, or an eBPF dataplane such as Cilium), this hop performs destination NAT to rewrite the packet's destination address from the Service's ClusterIP to a specific Pod IP, then routes the packet across the Pod network to the node hosting that Pod.

Sidecar or Pod-Network Delivery

If a service mesh sidecar (such as an Istio Envoy sidecar) is present on the destination Pod, the packet passes through an additional local proxy hop that may apply mTLS, retries, or additional L7 policy before delivery to the application container. In sidecar-less mesh deployments (ambient mode), this hop is instead handled by a per-node ztunnel process.

East-West Paths and Internal Gateways

Gateway as Internal API Boundary

The Gateway API is not limited to north-south ingress traffic. An internal Gateway with a listener bound to a ClusterIP-only address can front east-west traffic between services within the cluster, giving platform teams a single routing and policy enforcement point for internal APIs without exposing them externally.

Cross-Namespace Service Composition

HTTPRoute objects from many application teams can attach to a single shared internal Gateway, each contributing routes for its own namespace. The network path in this model still transits the shared proxy Pods, meaning capacity planning and observability for the internal Gateway deployment must account for aggregate east-west volume, not just north-south ingress.

TCPRoute and TLSRoute for Non-HTTP Protocols

For protocols that are not HTTP-aware, TCPRoute and TLSRoute provide L4 routing based purely on listener port and, for TLSRoute, SNI hostname. The network path for these route types skips L7 header inspection entirely, forwarding raw TCP streams (or TLS-encrypted streams with passthrough) directly to the backend Service.

Observability and Failure Points Along the Path

Where Latency Is Introduced

Each hop in the path — load balancer, gateway proxy, kube-proxy/CNI dataplane, and sidecar — adds measurable latency. Gateway controllers typically expose per-listener and per-route metrics (request count, latency histograms, upstream error rates) that let operators attribute latency to a specific hop rather than treating the path as a black box.

Common Break Points

A request can fail to reach its destination for several path-specific reasons: a missing ReferenceGrant blocking a cross-namespace route, a Gateway listener stuck in a non-Programmed condition because of a certificate reference error, an HTTPRoute with no matching backend Endpoints, or a NetworkPolicy blocking traffic between the gateway proxy Pods and the destination namespace.

Tracing the Path with kubectl

Operators typically inspect the path by checking Gateway and HTTPRoute status conditions, then confirming Endpoint readiness for the target Service.

kubectl get gateway public-gateway -n gateway-infra -o wide
kubectl describe httproute checkout-route -n shop
kubectl get endpoints checkout-svc -n shop

Security Considerations Along the Path

TLS Termination Placement

Deciding where TLS terminates — at the load balancer, at the gateway proxy, or passed through to the backend via TLSRoute — determines which hops see plaintext traffic and therefore which components must be trusted and audited.

NetworkPolicy Enforcement Between Hops

Because the gateway proxy Pods act as an intermediary, NetworkPolicies must explicitly allow traffic from the gateway proxy's Pod selector to backend namespaces; default-deny NetworkPolicy configurations otherwise silently break the path even when Gateway API objects are correctly configured.

mTLS in the Mesh Segment

When the final hop traverses a service mesh, mutual TLS between sidecars (or ztunnel proxies) provides encryption and identity verification for the segment of the path between the gateway's egress and the destination Pod, complementing the external TLS terminated earlier in the path.