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>
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
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
Now once I describe the deployment, we’ll observe the new image.
And I can check the history of this deployment with the following command:
kubectl rollout history deployment nginx
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
Now if we describe:
We will observe that the image is rolled back. And we can check the rollout history again:
Now we see that cause is none since I haven’t used –record flag on rollout.
- Episode 1: Introduction to Kubernetes
- Episode 2: How to Create a Kubernetes Cluster
- Episode 3: Kubectl
- Episode 4.1: Kubernetes Objects
- Episode 4.2: Kubernetes Workloads
- Episode 4.3: Kubernetes Services
- Episode 4.4: Kubernetes Storage
- Episode 4.5: Kubernetes Configuration Objects
- Episode 5: Scheduling in Kubernetes
- Episode 6: Kubernetes Upgrade and Deployment Strategies
- Episode 7: Kubernetes Security
- Episode 8: Deploy a Full Stack Application in Kubernetes
Thanks for reading,
Holding a BSc in Mechatronics, Ege loves to automate. He is now working as a Software Development Engineer In Test at XebiaLabs, Amsterdam. He is also passionate about Artificial Neural Networks.