The RollingUpdate deployment strategy ensures upgraded pods successfully come up before terminating older versions.
The following demonstrates an example of the RollingUpdate strategy. When using RollingUpdate, you can specify maxUnavailable
to specify how many pods can go down as an update takes place. You can also specify maxSurge
to specify how many pods can be created in addition to the desired replica count.
apiVersion: apps/v1
kind: Deployment
spec:
replicas: 2
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 0
minReadySeconds: 10
In the above sample Deployment yaml, two replicas are specified as desired number of pods.
The V1 replica pods remain up while an upgraded pod attempts to come up, moving through the pending and container creating states. This meets the maxUnavailable: 0
abd maxSurge: 1
specifications.
Once the upgraded V2 pod comes up, one of the old V1 pods can be terminated.
The upgrade continues to replace all the old pods. The second V2 pod attempts coming up.
The remaining old V1 pod is then terminated.
Desired replica count is achieved with the upgraded pods.