concept rollout process in category kubernetes

This is an excerpt from Manning's book Kubernetes in Action. Login to get full access to this book.

The undo command can also be used while the rollout process is still in progress to essentially abort the rollout. Pods already created during the rollout process are removed and replaced with the old ones again.

The extensions/v1beta1 version of Deployments uses different defaults—it sets both maxSurge and maxUnavailable to 1 instead of 25%. In the case of three replicas, maxSurge is the same as before, but maxUnavailable is different (1 instead of 0). This makes the rollout process unwind a bit differently, as shown in figure 9.13.

Figure 9.13. Rolling update of a Deployment with the maxSurge=1 and maxUnavailable=1

In this case, one replica can be unavailable, so if the desired replica count is three, only two of them need to be available. That’s why the rollout process immediately deletes one pod and creates two new ones. This ensures two pods are available and that the maximum number of pods isn’t exceeded (the maximum is four in this case—three plus one from maxSurge). As soon as the two new pods are available, the two remaining old pods are deleted.

You could achieve this by running an additional pod either directly or through an additional Deployment, ReplicationController, or ReplicaSet, but you do have another option available on the Deployment itself. A Deployment can also be paused during the rollout process. This allows you to verify that everything is fine with the new version before proceeding with the rest of the rollout.

In your case, by pausing the rollout process, only a small portion of client requests will hit your v4 pod, while most will still hit the v3 pods. Once you’re confident the new version works as it should, you can resume the deployment to replace all the old pods with new ones:

$ kubectl rollout resume deployment kubia
deployment "kubia" resumed


!@%STYLE%@!
{"css":"{\"css\": \"font-weight: bold;\"}","target":"[[{\"line\":0,\"ch\":0},{\"line\":0,\"ch\":41}]]"}
!@%STYLE%@!

copy

Obviously, having to pause the deployment at an exact point in the rollout process isn’t what you want to do. In the future, a new upgrade strategy may do that automatically, but currently, the proper way of performing a canary release is by using two different Deployments and scaling them appropriately.