Updating Deployments

Updating the db image#

Let’s see what happens when we set a new image to the db Pod.

It’ll take a while until the new image is pulled.

Describing the deployment#

Once it’s done, we can describe the Deployment by checking the events it created.

The last few lines of the output are as follows.

We can see that it created a new ReplicaSet and that it scaled the old ReplicaSet to 0. If, in your case, the last line did not appear, you’ll need to wait until the new version of the mongo image is pulled.

Instead of operating directly on the level of Pods, the Deployment created a new ReplicaSet which, in turn, produced Pods based on the new image. Once they became fully operational, it scaled the old ReplicaSet to 0.

Since we are running a ReplicaSet with only one replica, it might not be clear why it used that strategy. When we create a Deployment for the API, things will become more evident.

Looking into the cluster#

To be on the safe side, we might want to retrieve all the objects from the cluster.

The output is as follows.

As you can see, both ReplicaSets are there. However, one is inactive (scaled to 0).

You’ll notice that contained within the name of the Pod is a hash which matches the hash in the name of the new ReplicaSet, namely 6b48fcbfcf. Even though it might look like it is a random value, it is not.

If you destroy the Deployment and create it again, you’ll notice that the hash in the Pod name and ReplicaSet name remain consistent. This value is generated by hashing the PodTemplate of the ReplicaSet. As long as the PodTemplate is the same, the hash value will be the same as well. That way a Deployment can know whether anything related to the Pods has changed and, if it does, will create a new ReplicaSet.

Exploring ways to update deployment#

Updating using commands#

The kubectl set image command is not the only way to update a Deployment. We could also have used kubectl edit as well.

The command would be as follows.

⚠️ Please do NOT execute it. If you do, you’ll need to type :q followed by the enter key to exit.

The above edit command is not a good way to update the definition. It is unpractical and undocumented. The kubectl set image is more useful if we’d like to integrate Deployment updates with one of the CI/CD tools.

Since we’ll have a chapter dedicated to continuous deployment, we’ll continue using kubectl set image for now.

Updating the YAML file#

Another alternative would be to update the YAML file and execute the kubectl apply command. While that is a good idea for applications that do not update frequently, it does not fit well with those that change weekly, daily, or even hourly.

MongoDB is one of those that might get updated with a new release only a couple of times a year so having an always up-to-date YAML file in your source code repository is an excellent practice.

Finishing off by adding a service#

We used kubectl set image just as a way to introduce you to what’s coming next when we explore frequent deployments without downtime.

A simple update of Pod images is far from what Deployment offers. To see its real power, we should deploy the API. Since it can be scaled to multiple Pods, it’ll provide us with a much better playground.

Before we move on, let’s finish with the database by adding a Service and, therefore, enabling internal cluster communication to it.

Try it yourself#

The list of all the commands used in this lesson is as follows.