Building-permits needs many HTTP apps reachable on one shared external entrypoint and IP-friendly hostname routing. Why choose Ingress (or Gateway API) over one LoadBalancer Service per app?
Select an answer to reveal the explanation.
Short Explanation
One shared front desk beats renting a separate revolving door (cloud LB) for every tiny app. Ingress or Gateway API multiplex HTTP hosts and paths on a common entrypoint.
Full Explanation
Building-permits should choose Ingress or Gateway API instead of one LoadBalancer Service per app when many HTTP applications need a shared external entrypoint with IP-friendly hostname routing. A LoadBalancer Service typically provisions a separate cloud load balancer per Service for L4-style exposure and does not by itself offer rich shared HTTP host and path multiplexing. Ingress and Gateway API put many departmental apps behind one lobby—fewer public IPs, centralized TLS, clearer DNS—while still sending traffic to backend ClusterIP Services.
LoadBalancer Services can target Pods via selectors; they are not forbidden from selecting Pods, so that myth is not the reason to use Ingress. Ingress does not disable kube-proxy and is not a prerequisite for ClusterIP to work. Each LoadBalancer Service does not automatically provide host-based HTTP routing without an Ingress or Gateway controller.
Exam caveat: cloud providers sometimes add L7 features via annotations on LoadBalancer Services, but the portable Kubernetes answer for shared HTTP entry remains Ingress or Gateway API. East-west traffic continues to use ClusterIP without either.
Operational check: consolidate several HTTP apps onto one Ingress or Gateway address with host rules, retire extra cloud LBs where appropriate, and verify each backend Service still has ready endpoints and correct DNS records.