A release includes a breaking schema change that cannot safely mix v1 and v2 Pods behind the same Service. Which deployment approach is most appropriate?
Select an answer to reveal the explanation.
Short Explanation
If v1 and v2 speak different database dialects, don’t seat them at the same table mid-meal. Blue/green or recreate avoids the mixed-version window that rolling updates create. maxSurge just invites more mixing.
Full Explanation
When a release includes a breaking schema change that cannot safely mix v1 and v2 Pods behind the same Service, prefer blue/green or recreate so incompatible versions are not serving together. Mixed old/new Pods during a default rolling update can break municipal clients mid-request when schemas diverge.
Keeping the default rolling update so old and new overlap briefly is exactly the hazard. Raising maxSurge to run twice as many mixed-version Pods worsens coexistence. Pinning imagePullPolicy to Never does not prevent mixed versions already scheduled; it only affects pulls.
Exam caveat: Rolling updates assume backward-compatible coexistence. Breaking changes need non-overlapping strategies or carefully sequenced migrations (expand/contract) beyond a naive roll.
Operational check: choose recreate or a two-Deployment blue/green cutover; verify kubectl get pods shows only one version behind the Service; run integration checks before deleting blue. 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.