A tax-payment API needs a canary so only a small fraction of users hit v2. Using Deployments and a Service (no service mesh), what approach fits?
Select an answer to reveal the explanation.
Short Explanation
Canary is a tiny tasting table next to the main buffet—few v2 replicas, lots of stable, same Service ticket. Replica weighting does the split without a mesh. Trashing most stable Pods first is chaos, not canary.
Full Explanation
A tax-payment API that needs a canary so only a small fraction of users hit v2—using Deployments and a Service without a service mesh—should run a small v2 Deployment alongside stable and let one Service select both sets of Pods. Replica weighting approximates traffic share: one canary Pod among nine stable Pods yields roughly ten percent of ClusterIP load balancing for municipal payments testing.
Replacing the Service with a NodePort per Pod and splitting DNS manually does not scale and bypasses Kubernetes Services. Setting maxUnavailable to 90% on the stable Deployment’s rollingUpdate is a risky rolling strategy, not a canary. Deleting 90% of stable Pods before creating v2 Pods causes outage rather than a controlled partial expose.
Exam caveat: Without a mesh, canary ≈ extra Deployment + shared Service selector + replica ratios. Header-based splits need Ingress/controller features beyond basic Endpoints.
Operational check: label both Deployments with a common app label; Service selects app=…; kubectl get endpoints -o yaml; scale canary replicas up only after health checks pass. 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.