Sanitation must publish several citizen HTTP apps with host- and path-based routing on a shared entrypoint. When is Gateway API a better fit than exposing each app with only a raw NodePort?
Select an answer to reveal the explanation.
Short Explanation
NodePort is a plain numbered side door on every node. Gateway API is the shared lobby with host and path signs—use it when citizens need proper HTTP routing, not just a raw high port.
Full Explanation
Sanitation should prefer Gateway API over raw NodePort when citizen apps need L7 HTTP host- and path-based routing plus shared edge features on one entrypoint. NodePort publishes a Service on a high port across nodes at Layer 4; it does not by itself multiplex many hostnames and URL paths with centralized TLS and route objects. Gateway API (like Ingress) targets that shared lobby model—host and path signs, listeners, and portable routes—while Services still front Pods behind the edge.
Choosing Gateway API so Pods can avoid Services and bind host ports on every worker inverts best practice; Gateway backends typically remain Services, and hostPort sprawl is fragile. Pure east-west ClusterIP traffic inside one namespace does not need a north-south Gateway—ClusterIP and DNS already suffice. Using NodePort numbers to replace DNS because CoreDNS is down treats an outage workaround as an architecture choice and still lacks L7 host/path multiplexing.
Exam caveat: NodePort (and LoadBalancer) remain valid for simple L4 exposure. Gateway API shines when HTTP routing and shared edge policy matter. You still need a Gateway controller and working Services.
Operational check: for a multi-host citizen portal, deploy Gateway+HTTPRoutes targeting ClusterIP Services, compare with a NodePort-only publish, and verify host/path differentiation and TLS at the shared address—not on raw :3xxxx node ports.