A municipal CMS must send /v2 traffic to a green Service and keep / on blue through one hostname. Which Ingress capability provides that split?
Select an answer to reveal the explanation.
Short Explanation
Same hostname, different hallways: path rules send /v2 to green and leave / on blue. Ingress path matching is how you split blue/green HTTP backends without two public hostnames.
Full Explanation
A municipal CMS that must send /v2 traffic to a green Service while keeping / on blue through one hostname relies on path-based Ingress rules. Those rules map URL path prefixes—or exact paths, depending on pathType and controller—to different backend Services behind the same citizen-facing host. Conceptually it is one front door with two hallways: versioned or blue/green HTTP backends share DNS and TLS while the path selects the Service. That L7 split is a core Ingress capability platforms use without publishing a second public hostname.
PodAntiAffinity rules named after path prefixes only influence where Pods are scheduled relative to one another; they never inspect URL paths or steer Ingress traffic. Automatic DNS search-path rewriting inside CoreDNS for /v2 is nonsensical—DNS resolves names, not HTTP paths. EndpointSlice topology hints may influence internal traffic locality but are not keyed by URL path for north-south Ingress routing.
Exam caveat: path precedence and trailing-slash behavior differ by controller; a broad Prefix / can overshadow /v2 if pathType or ordering is wrong. Always validate both paths after changes, and remember Gateway API HTTPRoutes offer an alternative portable expression of the same idea.
Operational check: configure separate path rules to the blue and green Services on the CMS host, curl the same Host with / and /v2, and confirm responses originate from the intended Services and ReplicaSets before cutting municipal traffic over.