Ingress Controller Routing
An Ingress on its own does nothing, so what actually serves the traffic? A controller Pod watches the Ingresses of its IngressClass, compiles their rules into proxy config and is usually reached through a Service of its own. It terminates TLS, matches Host and path, longest path wins, and commonly proxies straight to a Ready Pod IP from the EndpointSlice. The Ingress API stays GA but is frozen, and the Kubernetes project recommends Gateway instead.
Play the animation 5 steps, animated, best on a wide screen
Ingress Controller Routing, step by step
-
The controller watches the Ingress objects whose ingressClassName names its IngressClass. Ingress shop holds a TLS entry for shop.io and two rules, both with pathType Prefix: / goes to Service web and /api to Service api. The controller compiles them into its proxy config.
Play from step 1 -
External traffic reaches the controller through a Service of its own, usually a LoadBalancer or NodePort. An HTTPS request for shop.io/ lands on the controller Pod, which serves the certificate from Secret shop-tls, the one its TLS entry names for that host, and terminates TLS.
Play from step 2 -
Now it reads the Host header, shop.io, and the path, /. Only the / rule matches. The controller does not hand the request to the Service ClusterIP: it reads the Ready endpoints of Service web from its EndpointSlice and proxies straight to Pod IP 10.244.1.5.
Play from step 3 -
A second HTTPS request asks for shop.io/api. Both rules match it, because Prefix / matches every path, and the Ingress spec gives precedence to the longest matching path, so /api wins. The controller reads the endpoints of Service api and proxies straight to Pod IP 10.244.2.7.
Play from step 4 -
A plain HTTP request for other.io/ arrives. No Ingress of this class names that host and Ingress shop sets no defaultBackend, so the Ingress API leaves the answer to the controller. This one hands it to its own default backend, which answers 404, and neither Service is looked up.
Play from step 5