For a simple canary, host app.city.example should send path / to Service app-stable and path /beta to Service app-canary. Which Ingress design achieves that split?

For a simple canary where host app.city.example should send path / to Service app-stable and path /beta to Service app-canary, configure Ingress paths / and /beta on the same host backing to app-stable and app-canary respectively. Path-based splitting is a straightforward CKAD-friendly canary approach for municipal apps when fine-grained weighted traffic splitting is not required. Product owners can send testers to /beta while citizens remain on / until green promotion.

One Service with sessionAffinity None does not automatically half traffic by URL path—affinity is about sticky clients, not path routing. A Job that rewrites client URLs every minute based on labels is not an Ingress canary mechanism and creates chaotic client behavior. A single headless Service listing both Deployments without path rules does not provide / versus /beta HTTP routing for browsers.

Exam caveat: Prefix path / can also match /beta depending on rule ordering and controller behavior—use Exact where needed or structure more specific paths carefully so canary and stable rules do not collide unexpectedly. Operational check: curl / and /beta with Host app.city.example; confirm stable versus canary responses; document the canary path for city product owners. Prefer controller-native weighted canary annotations only when the exam or platform explicitly requires them beyond basic path rules.