In this video, I will demonstrate upgrading a commonalties cluster deployed using Badme, so for this
as a prerequisite, you need a cabinet is deployed using the cube admin tool and it could be a local
set up on your laptop or one on the cloud, or you could be using our labs in this demo.
I happen to be using a cluster from the playground here.
So if you just go to Kalakuta Answers for Covenant's playground, you can instantly open up a lab session,
a playground which has a master and a worker node, and it's just very easy to practice cluster upgrades.
So on the right here, I have a cabinet cluster, um, terminal to accompany this cluster on Kalakuta
with a mass ranneberger node.
The master node, which is the control plane is at the top and the worker node is the terminal to the
worker.
Notice below and on the left here I have the component is documentation pages open.
Now, if you are not sure how to find this page, just search for Cube Ethereum upgrade in the search
bar.
And the first link is what you are looking for.
And by default, it opens the page with the latest instructions on upgrading, which as of now is from
one nine one point nineteen to one to 20.
And my cluster is that one of the 18.
So I will choose the instructions for upgrading from one of 18 to 19 by clicking this link.
So choose the relevant documentation page depending on your requirements.
Now, once the environment is loaded, I run the launch launch site script to wait for the cluster to
be ready.
But remember that this is only applicable to a Kitakata, so you might not need this in your if you're
using it in another environment.
So this particular step is only relevant to, uh, environments provisioned with Kalakuta.
And so it just waits.
It just creates like just a cluster and wait for it to come up.
So you make sure the cluster is ready and by running the queue to get nodes command, it shows the control
plane is not ready.
So let's just wait for it to be ready.
And it doesn't even show the node right now.
So we'll just wait for the the control plane and the node to be in real estate so we could use the watch
command with the cubicle, get node command to wait for both nodes to be ready.
So in this setup, I have a single control plane and a single worker node.
OK, so now what the notes are ready.
And you could run any cube Adam command to verify that curium is installed and that the cluster was
set up using BDM.
So I run the token list command and it shows a token, so that kind of shows that it used that token
to set up the cluster and you could also run the cubicle, get pods command with the Daschle option
to list all the parts, including those in the cube system namespace.
And we see that there is the core DNS, the Exelis control plane, and the networking solution is flannel.
In this demo, we're going to stick to just upgrading the capabilities components only and we will not
upgrade it.
Flannel networking solution.
So there are separate instructions for upgrading those.
We will just stick to upgrading the control plane as well as the worker notes.
So run the cubicle, get notes, command to verify the current version of the cluster, so it shows
as version one, dot 18, dot zero.
But remember that this is a version of the cube that running on the note.
The cube admin, too, will help us see the exact version of all the different components when we run
the the plan command.
So in the documentation page here on the left, the first step is to determine which version that is
it that you want to upgrade to.
We know that is one point nineteen, but we don't know exactly the exact version within one point nineteen.
So for this, we must run these commands.
And before you do that, if you are not sure which operating system you're on, you could run the cat
ATC slash star, release our command and it list the contents of the release file.
And you will see that in this case it is Ubuntu.
So we'll stick to the Ubuntu commands throughout this throughout this demo, we run the app commands
listed here to see the different versions available for upgrade.
So since we are upgrading to one point nineteen, we will choose one that 19 six version, which happens
to be the latest in one point nineteen.
So just note that down.
So the high level process is to upgrade the control plane load and then the upgrade CubeSat and you
cuddle on those notes and then upgrade worker notes.
So we will follow this procedure, but if you only want to upgrade certain parts, such as the work
of along, then you can skip this initial section where which is used for upgrading the control plane.
Or if you just want to upgrade the control plane and skip the working out section, you could do that
as well.
So just so feel free to choose the section that you want that you really want to do.
So let's first proceed with upgrading the control plane, so the first step is to upgrade Zubayda itself
on the control plane.
And for this, we run this set of commands to update and install new versions of QUIDAM for our target
version, which happens to be one, dot 19, dot six.
So I will copy to a notepad and I just change the version in the command and will execute the command
in the terminal.
We'll wait for that update to finish.
So the update is finished and now we verify the version of Ubaidi, I'm using the Canadian version command
and it seems to be upgraded successfully to one point nineteen dot six.
Next, we look at our upgrade plan, the man running the cube adiam upgrade plan command.
It lists the current version of components which are at one point eighteen dollars zero and the available
versions to upgrade to which is one point nineteen dollars six as desired.
The next step is to run the Cuba upgrade, appli command to upgrade to version one, not six.
So for this, we run the command and then confirm on the prompt.
Now this might take a few minutes, so let's just wait for it to complete, because this is when it's
actually performing the upgrade.
Once completed, we see the message that the cluster was upgraded to one that 19 dots successfully to
verify if you ran the cube.
If you run the cube idiom, upgrade plan, command a game that we see that there are no more upgrade
recommendations.
So that confirms that all the components have been upgraded successfully.
If you run the cubicle, get notes, command, now we will see the version to be one that it is not
zero.
Still, this is because what you see here is a version of Hublot and Aquarium Upgrade Command does not
upgrade to blit.
So that's the next step.
Now, since Kuebler is responsible for running pods, we must drain the node before upgrading CubeSat.
So we run the cubicle drain command to drain the control node, and once done, we proceed with the
upgrade commands to upgrade Kubelik and the cubicle utility itself.
So as before, I copy to a text, file the commands and we change the versions to one point ninety six
and then we execute the commands.
Once done, reload the Neeman and restart Hublot.
When we run the cubicle, get notes command, we see the control plane is now upgraded to understanding
that the status is schedule disabled.
Now, this is because we drained the node earlier, so we must now uncoordinated.
And that's what we will do now for this.
We run the cubicle, unquote, in command.
We verified the status again, and we see that the note is now ready.
So we have successfully upgraded the master node.
Now, the next step is to upgrade the worker notes.
Now, as before, the first step is to upgrade Zubayda M on the worker notes.
So we run the app, install commands to upgrade Kubi a.m. to the target version and note that this is
to be done on the worker node and that is to be updated.
So most of course, most of the commands.
To upgrade worker nodes are done on the worker nodes except the cube related command.
I'll I'll point that out when we reach to that point, but make sure that you are on the appropriate
node and when you're running the respective commands.
So now that is done, the next step is to upgrade Kubla configuration.
We run the command to upgrade that configuration, and once done, the next step is to drain the node
and this is where a lot of people make mistake.
The drain command is to be run on the control node because it's a cubicle command.
If you run it on a worker node, you will get an error like this.
So remember to run it on the control plane, not most of the commands, as I just said, for upgrade,
upgrading or working out a run on the work node, except for the shuttle commands to train and coordinate.
And those are done to be done on the controlled plane.
Not.
So once done, the next step is to upgrade.
And for this, we run the install commands with the target versions of these packages.
And once that is completed, we reload Biman and restart, uh, running the cubicle, get node's.
Command confirms the upgrade is successful on the worker node and scheduling is disabled as we haven't
and couldn't yet.
Uh, so let's do that.
And remember, this has to be done on the master node as well, and that's it.
We have now successfully completed the upgrade procedure.
Well, head over to the labs and try this for yourself.