Kubernetes Ingress Network Path

Kubernetes Ingress Network Path describes the complete traffic journey for HTTP and HTTPS requests routed through an Ingress resource, spanning the external entry point that receives client requests, the Ingress controller that interprets routing rules, and the final delivery to a Service and its backing pods.

Entry Point Layer

Fronting Load Balancer or NodePort

Traffic destined for an Ingress-managed application first arrives at whatever external entry point exposes the Ingress controller itself, most commonly a cloud LoadBalancer Service or, in bare-metal environments, a NodePort or host-networked deployment. This entry point delivers traffic to one of the Ingress controller's own pods, which is a distinct hop from the eventual application Service the request is routed to.

Controller as a Reverse Proxy

The Ingress controller pod, running software such as an NGINX, Envoy, or HAProxy-based proxy, terminates the incoming connection and acts as a genuine Layer 7 reverse proxy, inspecting the HTTP request's host header and path before making a routing decision, unlike the purely Layer 4 forwarding performed by the Service data plane.

Routing Decision Layer

Host and Path Matching

Once the Ingress controller has parsed the incoming request, it evaluates the collected set of Ingress resources' rules, matching the request's host header and URL path against the configured rules to determine which backend Service the request should be forwarded to, applying whatever rule specificity and precedence conventions the particular controller implementation follows.

Rule Aggregation Across Ingress Objects

Because multiple Ingress resources can exist across different namespaces, all targeting the same controller, the controller continuously aggregates their combined rule sets into a single internal routing table, which it reprograms whenever Ingress objects are created, updated, or deleted.

Backend Delivery Layer

Forwarding to a Service

Once a routing match is found, the Ingress controller forwards the request to the matched Service, most commonly by resolving the Service's ClusterIP through cluster DNS or the Kubernetes API directly, and from that point the request follows the same Service data path, DNAT to a selected endpoint, that any other ClusterIP-directed traffic would follow.

Endpoint-Aware Load Balancing

Some Ingress controllers bypass the standard Service data path entirely for the final hop, instead watching a Service's EndpointSlice objects directly and load balancing across backing pods themselves, which can offer more sophisticated load balancing algorithms or session affinity than the underlying kube-proxy data plane provides.

TLS Termination Point

Where Encryption Ends

TLS termination for Ingress-routed traffic typically occurs at the Ingress controller itself, using certificate and key material referenced by the Ingress resource, meaning traffic between the client and the Ingress controller is encrypted while traffic between the controller and the backend Service may be plaintext unless the controller is explicitly configured to re-encrypt for the final hop.

Path Traversal Failure Points

Controller Pod Placement Sensitivity

Because all Ingress-routed traffic passes through the Ingress controller's own pods, the network path's reliability depends heavily on how those pods are scheduled, replicated, and health-checked, since a single unhealthy or overloaded Ingress controller pod can become a bottleneck or single point of failure for every application routed through it.

Multi-Hop Latency Accumulation

The full Ingress network path involves more hops than a direct Service access, external load balancer to controller to Service to pod, each of which adds latency and a potential point of packet loss, which is a relevant consideration when comparing Ingress-routed traffic performance against directly exposed LoadBalancer or NodePort Services for latency-sensitive workloads.