Product wants header-based canary routing for internal testers. At CKAD depth with basic Service weighting only, what should the candidate conclude?
Select an answer to reveal the explanation.
Short Explanation
Plain Services are coin-flip load balancers across endpoints—they don’t read HTTP headers. Replica-weighted canary is the CKAD bread-and-butter; fancy header splits need Ingress (or similar), not mesh trivia for the exam core.
Full Explanation
When product wants header-based canary routing for internal testers, but the environment is CKAD-depth with basic Service weighting only, conclude that you should stick to replica-weighted canary with Deployments and Services. Header splits need Ingress or service-mesh controller features beyond basic Service endpoints, which simply load-balance Ready Pods without inspecting HTTP headers.
Header routing is not built into every ClusterIP Service via sessionAffinity—sessionAffinity is client-IP stickiness, not header matching. Implementing header matching by setting hostname on the Pod spec does not parse requester headers. Using kubectl port-forward as the supported production canary mechanism is a troubleshooting tool, not a multi-user production splitter.
Exam caveat: Know the boundary of core Services versus Ingress annotations/rules. On CKAD, replica weighting is the honest answer when meshes are unavailable.
Operational check: implement replica-weighted canary; demonstrate approximate traffic share with kubectl get endpoints; if headers are mandatory, document the Ingress controller capability required beyond the exam’s basic Service model. In municipal environments, document the chosen pattern in the service runbook so on-call engineers apply the same kubectl checks during incidents, and keep the change tied to the application Deployment or Job rather than ad-hoc node mutation.