A city website cutover must keep the old version live until operators point traffic at the new version. How should blue/green be designed with Kubernetes primitives?
Select an answer to reveal the explanation.
Short Explanation
Blue/green is two stages side by side—old show still playing while the new set finishes dress rehearsal. Keep both Deployments up, then flip the Service selector to green. One Deployment yo-yo isn’t blue/green.
Full Explanation
A city website cutover that must keep the old version live until operators point traffic at the new version is a blue/green design with Kubernetes primitives: run two Deployments in parallel (blue and green) and switch the Service selector to the green Pods when ready. Residents keep hitting blue until the selector change atomically moves Endpoints to green.
Scaling one Deployment to zero, changing its image, then scaling back up is closer to a recreate/outage window than true blue/green coexistence. Using a Job to rewrite kube-proxy rules during maintenance is unsupported and dangerous. Annotating Ingress with canary-weight 100 without a second Deployment depends on controller-specific features and still needs a green workload.
Exam caveat: Blue/green at CKAD depth is two Deployments plus a Service selector flip (and Ingress that targets that Service). Keep labels distinct for version while sharing an app label carefully.
Operational check: deploy blue and green; kubectl get endpoints before/after selector patch; curl the Service during cutover; keep blue scaled for fast rollback. 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.