After a blue/green cutover attempt, clients still reach old blue Pods. Investigation shows the Service selector was never updated. What went wrong?
Select an answer to reveal the explanation.
Short Explanation
You built the green stage but left the ushers’ map pointing at blue. If the Service selector still says blue, traffic never moves. Fix the labels/selector—don’t blame TLS or demand blue’s deletion first.
Full Explanation
After a blue/green cutover attempt, if clients still reach old blue Pods and investigation shows the Service selector was never updated, the failure mode is straightforward: the Service still matches blue labels, so Endpoints never moved to green. Blue/green traffic movement is the selector (or Ingress backend) change—not merely creating a green Deployment.
Blue/green does not require deleting Endpoints objects before any selector change; the controller reconciles Endpoints from the selector. Ingress TLS rotation is unrelated to selector matching. Green can receive traffic while blue’s ReplicaSet still exists; coexistence is intentional until teardown.
Exam caveat: Always verify Service selector and Endpoints as part of cutover checklists for city launches.
Operational check: kubectl get svc -o yaml | grep selector; kubectl get endpoints -o wide; patch selector to green labels; re-curl the Service; confirm blue no longer appears. 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.