Kubernetes Series – 6: Kubernetes Upgrade and Deployment Strategies

In this tutorial, we will talk about upgrading nodes and deployment in Kubernetes. Let’s deep dive into Kubernetes upgrade and deployment strategies together!

Node Upgrade and Eviction

How you would upgrade your nodes generally depends on how you set up your cluster. If you set it with the kubeadm tool, then you need to manually upgrade your nodes. To do so you need to upgrade kubeadm and kubelet versions on each node. So basically you have to ssh to the node that you would like to upgrade and then, for kubeadm:

apt-get upgrade -y kubeadm=1.12.0-00

kubeadm upgrade apply v1.12.00

And for kubelet:

apt-get upgrade -y kubelet=1.12.0-00

systemctl restart kubelet

This should be repeated on each node including, of course, the master ( controlplane ) node. For more information please refer to the documentation: https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/

During the upgrade we don’t want any Pod to be scheduled on that specific node, therefore we need to mark it as unschedulable. To do so:

kubectl cordon < node name >

But what If we want to upgrade the nodes and there are pods running on them. Then we first need to drain the node(s).

To drain a node:

kubectl drain <node name>

This will move that Pod to another working node ( or to the master node if it is schedulable ) and mark it as unschedulable ( i.e cordon ).

After the upgrade we can mark it as schedulable again by:

kubectl uncordon <node name>

Deployment Upgrade

Imagine we have an application and we recently published a newer version of it. Or in our application, we are using a third-party application that the developers recently updated. In both ways, at some point, we would like to update our Kubernetes deployments as well.

Let’s discuss how we can do it with an example. First, let’s create our nginx deployment.

kubectl create deployment nginx --image=nginx:1.14.2

Kubernetes Upgrade and Deployment Strategies

Here I used a specific image of nginx 1.14.2. For some reason, I’d like to update this image. We can do it by editing the image parameter of the deployment.

kubectl set image deployment nginx nginx=nginx:1.16.1

In general this command is used with the “– record” flag, so that it will be displayed in the rollout history.

kubectl set image deployment nginx nginx=nginx:1.16.1 --record

Kubernetes Upgrade and Deployment Strategies

Now once I describe the deployment, we’ll observe the new image.

Kubernetes Upgrade and Deployment Strategies

And I can check the history of this deployment with the following command:

kubectl rollout history deployment nginx

Kubernetes Upgrade and Deployment Strategies

If the new image does not work with other products, or for some other reason if we want to roll back our upgrade:

kubectl rollout undo deployment nginx

kubectl rollout undo deployment

Now if we describe:

pod template in kubernetes

We will observe that the image is rolled back. And we can check the rollout history again:

kubectl rollout history deployment

Now we see that cause is none since I haven’t used –record flag on rollout.

Kubernetes Series

Thanks for reading,
Ege Aksoz

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.