One hostname parks.city.example should send path /ui to Service parks-ui and path /api to Service parks-api. How should the Ingress express that split?
Select an answer to reveal the explanation.
Short Explanation
One front door, two hallways: /ui and /api. A single Ingress host with two path backends is the portable pattern. Smushing both apps into one Service throws away path-based routing.
Full Explanation
When one hostname parks.city.example should send path /ui to Service parks-ui and path /api to Service parks-api, express that split with one Ingress host rule containing multiple paths, each backing to the appropriate Service and port. Name-based hosting plus path routing is a primary Ingress feature for municipal sites that share a hostname across UI and API tiers without exposing separate NodePorts.
Hardcoding two separate ClusterIP values into each Pod’s HTML bypasses Ingress and becomes brittle as ClusterIPs change. A single Service that merges both Deployments under one selector ignores URL paths and mixes UI and API backends incorrectly. A NetworkPolicy that supposedly rewrites URL paths based on namespace labels does not perform HTTP path routing—NetworkPolicy filters L3/L4 packets only.
Exam caveat: set distinct pathTypes appropriately (often Prefix for /ui and /api) and ensure both Services exist in the same namespace as the Ingress. Watch Prefix / matching if you also define broader paths. Operational check: curl parks.city.example/ui and /api through the controller and confirm different backends respond; kubectl describe ingress shows both paths and services. Keep UI/API Service names stable in the city’s parks service catalog so Ingress backends do not drift.