Ingress for host and path routing

WHAT THIS TESTS Knowing that exposing many HTTP services efficiently is a layer-7 routing problem solved by Ingress, not by stacking layer-4 load balancers.

A GOOD ANSWER COVERS The object is an Ingress resource. It specifies rules that match on host (for example api.example.com versus app.example.com) and on URL path (such as /api routed to one Service and /shop to another). All these rules are served behind a single external IP fronted by one load balancer. An Ingress is inert on its own; it requires an Ingress controller (NGINX, Traefik, or a cloud controller) running in the cluster to read the rules and actually proxy traffic. The advantage over multiple LoadBalancer Services is significant: each LoadBalancer Service provisions a separate cloud load balancer with its own IP and cost, and they cannot share host or path routing. Ingress consolidates all HTTP routing, TLS termination, and a single entry point.

COMMON WRONG ANSWERS Creating one LoadBalancer per service, which is expensive and offers no shared layer-7 routing. Assuming an Ingress resource works without a controller. Confusing Ingress with a Service type.

LIKELY FOLLOW-UPS How is TLS handled? The Ingress references a TLS secret and the controller terminates HTTPS. What is the modern successor? The Gateway API. How does the request flow? External LB to controller to backend Service to Pod.

ONE CONCRETE EXAMPLE Three services, web, api, and admin, must share one public IP. You deploy an NGINX Ingress controller, then create an Ingress mapping app.example.com to the web Service, api.example.com to the api Service, and /admin to the admin Service. One load balancer and one IP serve all three, instead of three separate cloud load balancers.