RollingUpdate or Recreate
Should a Deployment replace its Pods alongside the old ones or after them? The field .spec.strategy.type takes two values, and RollingUpdate, the default, surges to create the replacement and wait for it to report Ready before the old Pod is removed, so the two are briefly alive together. Recreate inverts that order, terminating every old Pod before the replacement is created, which buys one version running at a time and pays with a window where nothing serves.
Play the animation 6 steps, animated, best on a wide screen
RollingUpdate or Recreate, step by step
-
A Deployment replaces its Pods, and .spec.strategy.type decides in which order. The field takes two values and no third, RollingUpdate and Recreate, and a Deployment with no strategy set gets RollingUpdate. Both tracks start from the same place: Pod web-7f9c8-tp8vd on app v1.0 is Ready, and .spec.template has just been changed to v2.0. Each track will issue the same two orders, one create and one terminate, and only their sequence differs.
Play from step 1 -
RollingUpdate starts by creating. At .spec.replicas 1 the 25% defaults resolve to maxSurge 1 and maxUnavailable 0, so the controller may run one Pod above the count and may not lose the one it has. Its first order is therefore Create web-6b8d5-r7hjn: the Pod appears on app v2.0 and starts, and web-7f9c8-tp8vd keeps serving beside it. Nothing is removed until the newcomer reports Ready.
Play from step 2 -
Pod web-6b8d5-r7hjn reports Ready, and at the default minReadySeconds 0 that readiness alone releases the second order, Terminate web-7f9c8-tp8vd. Across the handover window both Pods were up, which is what buys the update its uptime and is also its bill: for that span two versions answered at the same moment. Pod web-7f9c8-tp8vd finishes terminating and the track ends where it started, one Pod serving, now on v2.0.
Play from step 3 -
Recreate inverts the sequence. Its first order on an upgrade is Terminate, aimed at every existing Pod, which at .spec.replicas 1 means web-7f9c8-tp8vd alone and at any larger count means all of them. Pod web-7f9c8-tp8vd leaves, and the controller now waits: it creates nothing until the removal has succeeded, so the same handover window holds nobody, and that is real downtime.
Play from step 4 -
Only once web-7f9c8-tp8vd is gone does the second order go out, Create web-6b8d5-r7hjn. The Pod appears on app v2.0 and starts, and the outage lasts until it reports Ready: the removal plus a cold start. What that buys is a clean cut, no moment at which two versions answer together, and the track ends as the other did, one Pod serving on v2.0.
Play from step 5 -
Both tracks end in the same state, one Pod web-6b8d5-r7hjn Ready on app v2.0: on an update that completes the field changes the path and not the result. RollingUpdate spent the window with two Pods up and two versions live, Recreate spent it with nobody serving. Pick Recreate when the two versions must never run at once, which is what lets a ReadWriteOnce volume change Nodes, since it attaches to one Node at a time, and keep the default otherwise.
Play from step 6