Okay, so in this video,
we're going to go through the lab on cluster upgrade process.
This lab tests your skills on upgrading a Kubernetes cluster,
and we have a production cluster with applications running on it.
Let's explore the setup first.
The first question is, what is the current version of the cluster?
We're going to do kubectl get nodes.
It's not set up, so let me do that, kubectl get nodes.
We see that there are two nodes.
The version that we're currently at is 1.19.0, so 1.19.0.
How many nodes are part of this cluster?
There are two nodes, including the master and worker nodes.
How many nodes can host workloads in this cluster?
Inspect the applications and taints set on the nodes.
Let's do a kubectl describe node command
and look for taints.
Let's see if there are any taints set up on them.
There are no taints.
That means both the nodes can host applications.
That's two.
We can have other nodes running, hosting applications.
How many applications are hosted on the cluster?
Let's do a get deploy.
We see that there's just one application and that's the blue application.
Let's go to the next one.
Now, what nodes are the pods hosted on?
Let's do a get pods with the wide option.
We see that the pods are hosted on control plane as well as node01.
Both control plane and node01.
You are tasked to upgrade the cluster.
Users accessing the applications must not be impacted
and you cannot provision new VMs.
Currently, there are two VMs,
the control plane and node01.
You cannot provision new VMs and the users accessing
the applications must not be impacted,
so we cannot fully take the applications down.
What strategy would you use to upgrade the cluster?
Upgrade one node at a time while moving the workloads to the other,
so that looks like the best option.
We'll also see why the others are not.
Users will be impacted since there's only one worker node.
That's incorrect because we have seen that the workload
can be scheduled on both the control plane and the worker node,
even though there's only one worker node.
In this case, even if we take down the worker node, the deployments,
the applications are going to be recreated on the control
plane node so users will not be impacted just in this case,
because we've seen that that's the way it is set up,
this particular cluster.
Upgrade all nodes at once.
If we do that, of course the applications will be down for the time,
during which the nodes are being upgraded.
The users are going to be impacted so that's not the correct option.
Add new nodes with newer versions while taking down existing nodes.
That's incorrect because it is said here
that you cannot provision new VMs.
We cannot add new nodes.
The option here is to upgrade one node at a time
while moving the workloads to the other.
What is the latest stable version available
for upgrade using the kubeadm tool?
Let's do the kubeadm tool
and we know that we have the upgrade plan option.
This question is not to find out the latest stable version of Kubernetes
but what the latest stable version
that this particular kubeadm tool knows as of now.
Running the upgrade plan command let's -.
The options that we have.
Currently, the kubeadm tool itself is on version 1.19.
As you can see here, the kubeadm version is 1.19.
This particular kubeadm version,
this tool can upgrade this cluster to 1.19.16.
If we need to upgrade to a higher version, if you look at this,
the remote version as of this recording is 1.23.5,
so if you want to upgrade to any version other than 1.19, so like 1.20, 1.21
then we will need to upgrade the kubeadm tool itself.
To answer this question, the available stable version
as of this recording is 1.19.16.
Now we will be upgrading the master node first.
Let's drain the master node of workloads
and mark it unschedulable, so let's do that.
Let's do a kubectl drain
and controlplane with the ignore daemon set option.
The auto-complete didn't configure for this lab so I just have to--
We're just waiting for the pods to be evicted.
Let's check the status.
We see that controlplane shielding is disabled
and if you look at the pods,
just to be sure we see that they're all on node01 now.
Now next, we upgrade the controlplane components
to the exact version 1.20.0.
That's what we need to upgrade into.
For that, we have to upgrade the kubeadm tool first
and then the master components.
First, we have to upgrade the kubeadm tool
and then the master control components, and then the kubelet.
That's kind of the high-level steps.
We will refer to the Kubernetes documentation pages for this.
Let's open up the Kubernetes documentation page and it's for upgrade,
and here we have upgrading kubeadm clusters.
That's what we want to do.
The goal here is that we know that we're currently on 1.19
and we want to upgrade it to 1.20.
As of this recording,
this lab is asking to upgrade from 1.19 to 1.20,
but depending on when you're working on this lab,
depending on what the question is here,
you must select the right one from here.
I'm going to select this one right here, which is 1.19 to 20,
and here are the steps.
When going through this,
remember that first we determine which version to upgrade to,
then here we have upgrading control plane nodes,
and then below we have upgrading worker nodes.
Remember to follow the right one.
The first step, and also there are two versions.
This is for Ubuntu and Debian and this is for CentOS
and we're not sure which one you're on.
You could do a cat /etc/-release,
and this will tell you the current operating system version.
You're on Ubuntu right now.
That's what we are going to go with.
Let's run this first to identify the exact
version that we want to upgrade to,
but we already have it here but let's just do this to find out for sure.
The version that we want to upgrade to is 1.20.0,
but then there's also this.
The last digit,
this is what we're going to upgrade to, 1.20.0-00.
Now, the first step is to upgrade the control plane nodes.
That's what we're going to do, and this is the command.
The first step is to upgrade kubeadm itself, so the kubeadm tool itself.
There are two ways to do it.
You can either run these three commands or you can just run
these two commands that are together,
but for this the apt-get version should be greater than 1.1.
You can actually verify that
by running apt-get --version.
We're on 1.6. That means we can just run this command.
We're going to copy this and that should be 00.
We're going to change this to 0, that's what we want to upgrade to.
Let's run that.
Kubeadm is now upgraded.
Next, let's verify using the kubeadm command,
and we see that it's now at 1.20.0.
Next, we are on the upgrade plan again and we can get the new plan.
Here we see the details.
You have the current version of the API server and everything here
and you have the available version here.
What we want to do is to upgrade this to this specifically.
That's what we're going to do.
We're going to do the kubeadm upgrade apply command
and specify the version as zero.
Are you sure you want to proceed with the upgrade?
Yes.
Okay, that's done.
It says, "Your cluster was upgraded to version 1.20.0."
The next step is to upgrade your CNI providers.
We're going to skip that.
For now, we don't want to do that.
For other control panels,
we do not have any other control plane nodes as of now.
Finally, the node is already drained.
We don't have to do that either.
The final step is to upgrade kubelet and kubectl utility, right?
Here again, we're going to follow this second command
and we'll change it to version 00.
Okay.
Then the final step is to restart kubelet.
Let's do that.
Okay.
Then it's to uncordon the node.
Let's just check status now.
We see that here on get nodes,
you see that the control plane is now at 1.20.
Let's check the work.
Okay.
Now we've got to mark the control plane node as schedulable again.
That's basically this step.
We can do that now.
That's uncordon controlplane.
Let's verify it's done.
Yes.
Okay, next is the worker node.
Drain the worker node of the workloads and mark it unschedulable.
We see that it's in a ready state, and we're going to drain node 01.
Then we pass the ignore-daemonsets option.
We'll just wait for the pods to be evicted.
Okay, now let's check the status of the node.
Also, let's check the status of pod.
Now you can see that node01 is uncordoned
and then all the pods are now on controlplane.
The workload has now moved to controlplane.
Now we can safely upgrade node01.
Now we're going to upgrade the worker node to the exact version, 1.20.0.
Let's go here,
the upgrade procedure on worker nodes should be executed one node at a time
or few nodes at a time
without compromising the minimum required capacity.
We have taken care of that.
The first step is to upgrade kubeadm.
This needs to be on the worker node.
Remember that.
You could ssh to the worker node by just typing
the name of the node if that's set up properly.
Or another way to do that is to find the IP address
of the nodes by running a get nodes wide command
and then ssh to this internal IP of node01.
Yes, okay.
We're now on node01.
The first step is to upgrade the kubeadm tool.
Let's copy this and set it to 0.
Okay, that's complete.
The next step is to call the kubeadm upgrade node command.
What this is going to do
is it's going to upgrade the kubelet configuration.
This should be pretty quick.
That's done.
The next step is to drain the node.
The node is already drained, so we don't have to do that.
The next step is to upgrade the kubelet and kubectl utility.
Lets copy these and
lets change this to 0.
Then you have the restart kubelet option.
Restart kubelet.
Finally, uncordon.
We'll do that.
Lets first check the status.
Lets go back to the controlplane node
and lets check the status of the node.
We see that it is now on 1.20.
Lets check the status.
That's successful.
Now we have to remove the restriction
and mark the worker node as schedulable again.
That's the uncordon.
We're going to uncordon node01.
Lets check the nodes and we see that both of them are in a ready stage.
We have successfully moved the workload between the nodes
and managed to upgrade both the nodes in the cluster.
Well, that's the end of this lab.