A developer tries to implement a web API canary by creating a Job that runs the v2 image once. Why is that the wrong workload?
Select an answer to reveal the explanation.
Short Explanation
A Job is a one-and-done chore—great for batch, terrible as a standing canary waiter. Web canaries need long-running Deployment replicas sitting behind a Service. Don’t cast a Job in that role.
Full Explanation
A developer who tries to implement a web API canary by creating a Job that runs the v2 image once is using the wrong workload. Canary patterns target long-running replicated Deployments behind Services, not one-shot Jobs. Jobs complete and exit; they are not the vehicle for sustained percentage traffic to a municipal API.
Jobs do not automatically register with Services in a canary sense merely because restartPolicy is Never. Jobs are not required for canary because Deployments cannot share Services—Deployments commonly share Services via labels. Jobs do not provide built-in traffic splitting percentages via completions.
Exam caveat: Workload fit matters as much as release vocabulary—Deployments/Services for canary traffic; Jobs for batch.
Operational check: replace the Job with a small canary Deployment selected by the Service; kubectl get endpoints shows lasting canary Pods; delete the Job template from the release checklist. 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. 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.