Creating a Zero-Downtime Deployment

Creating deployment#

Before we explore rolling updates, we should create the Deployment and, with it, the first release of our application.

We created the Deployment and retrieved the object from the Kubernetes API server.

The output of the latter command is as follows.

Please make sure that the number of available Pods is 3. Wait for a few moments, if that’s not the case. Once all the Pods are up-and-running, we’ll have a Deployment that created a new ReplicaSet which, in turn, created three Pods based on the latest release of the vfarcic/go-demo-2 image.

Let’s see what happens when we set a new image.

There are a few ways we can observe what is happening during the update. One of those is through the kubectl rollout status command.

The output is as follows.

From the last entry, we can see that the rollout of the new deployment was successful. Depending on the time that passed between setting the new image and displaying the rollout status, you might have seen other entries marking the progress. However, I think that the events from the kubectl describe command are painting a better picture of the process that was executed.

The last lines of the output are as follows.

We can see that the number of desired replicas is 3. The same number was updated and all are available.

At the bottom of the output are events associated with the Deployment. The process started by increasing the number of replicas of the new ReplicaSet (go-demo-2-api-559d6888df) to 1. Next, it decreased the number of replicas of the old ReplicaSet (go-demo-2-api-566c5b97f5) to 2. The same process of increasing replicas of the new, and decreasing replicas of the old ReplicaSet continued until the new one got the desired number (3), and the old one dropped to zero.

There was no downtime throughout the process. Users would receive a response from the application no matter whether they sent it before, during, or after the update. The only important thing is that, during the update, a response might have come from the old or the new release. During the update process, both releases were running in parallel.

Let’s take a look at the rollout history.

The output is as follows.

We can see that, so far, there were two revisions of the software. The change cause shows which command created each of those revisions.

How about ReplicaSets?

The output, limited to go-demo-2-api, is as follows.

We can see that the Deployment did not modify the ReplicaSet, but that it created a new one and, at the end of the process, the old one was scaled to zero replicas.

The above diagram illustrates the workflow of the Deployment controller rolling update.

Try it yourself#

The list of all the commands used in this lesson is given below.