Green Deployment Pods are Ready, but users still hit blue because Ingress still references the blue Service name. What lesson applies?
Select an answer to reveal the explanation.
Short Explanation
Green lights on the stage don’t help if the theater marquee still lists the blue show. Check Service and Ingress—not just Deployment readiness—so the whole path aims at green.
Full Explanation
If green Deployment Pods are Ready but users still hit blue because Ingress still references the blue Service name, the lesson is to validate the full exposure path—Service and Ingress must target the intended green traffic. Ready Pods alone do not move north-south traffic when Ingress points elsewhere.
Ready Pods do not automatically rewrite Ingress backends after sixty seconds. Blue/green is not limited to NodePort; Ingress is commonly used, but must be updated or already front a Service you switch. Deleting all Ingress resources during cutover and relying on Pod IPs breaks external access and DNS assumptions.
Exam caveat: Draw the path Client → Ingress → Service → Endpoints → Pods and verify each hop during municipal cutovers.
Operational check: kubectl describe ingress; curl the external hostname; patch Ingress backend or flip the shared Service selector; re-test; watch access logs for green Pod names. 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.