When is a Deployment recreate strategy acceptable despite briefly taking the app offline?
Select an answer to reveal the explanation.
Short Explanation
Recreate is the “close the shop, remodel, reopen” move—old Pods out before new Pods in. Fine when a brief blackout is okay and you refuse version mixing. Don’t pick it for a zero-downtime public storefront.
Full Explanation
A Deployment recreate strategy is acceptable despite briefly taking the app offline when a short availability gap is acceptable and mixed old/new Pods must be avoided. Recreate terminates the old ReplicaSet before bringing up the new one, which helps municipal batch UIs or internal tools that cannot tolerate dual-version protocol skew.
Choosing recreate whenever maxSurge would exceed CPU quotas is a capacity workaround, not the conceptual reason. Recreate is not only for DaemonSets—Deployments support it. When zero-downtime is mandatory for public APIs, prefer rolling or blue/green instead of recreate.
Exam caveat: strategy.type Recreate versus RollingUpdate is a direct CKAD knob. Combine with understanding of breaking changes from related questions.
Operational check: set strategy.type=Recreate; kubectl rollout status and observe downtime window; compare Endpoints emptiness mid-roll; switch public APIs back to RollingUpdate or blue/green. 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.