A city exposes permits.example.gov and inspections.example.gov with different URL paths and does not want a separate LoadBalancer Service for each hostname. Which Kubernetes object declares host and path HTTP routing typically in front of ClusterIP Services?
Select an answer to reveal the explanation.
Short Explanation
Ingress is the HTTP map: hosts and paths share front-door capacity instead of one LoadBalancer Service each. Controllers implement those rules, usually toward ClusterIP Services. That is L7 routing inside Kubernetes—not API Gateway’s Domain 3 story.
Full Explanation
Exposing permits.example.gov and inspections.example.gov with different URL paths without a separate LoadBalancer Service per hostname is the Ingress pattern: declare host and path HTTP routing in an Ingress object, implemented by an ingress controller, typically in front of ClusterIP Services. One front door multiplexes many hosts and paths to the correct backends and conserves load-balancer sprawl. A queue message carrying HTTP host headers is messaging infrastructure, not cluster HTTP routing configuration. Treating OCI API Gateway as the in-cluster kube-proxy replacement for this Domain 2 item confuses an edge API management product with Kubernetes Ingress resources and controllers inside the cluster. A NodePort on port 80 for every Pod name individually does not provide host and path routing and does not scale as a multi-site HTTP front door. Exam caveat: Ingress resources do nothing until a compatible ingress controller is installed and watching your ingress class or annotations; the YAML alone is not a data plane. Operational check: apply Ingress rules for both hostnames and paths, confirm the controller programs routes, and curl each host and path to the correct ClusterIP Service backends.