Hello and welcome to this lecture, in this lecture, we discuss about Closter upgrade process and Coronets.
In the previous lecture we saw how Copernicus manages its software releases and how different components
have their versions.
We will keep dependency on external components like SCD and courteousness aside for now and focus on
the core control plane components.
Is it mandatory for all of these to have the same version?
No, the components can be at different release versions since the Cube API server is the primary component
in the control plane and that is the component that all other components talk to.
None of the other components should ever be at a version higher than the Cube API server.
The controller manager and scheduler can be at one version lower, so Ifukube API server was at X controller
managers and Kube schedulers can be at X minus one and the Kubelik and Q proxy components can be at
two versions, lower X minus two.
So if Cube API server was at one point, then the controller manager and scheduler could be at one or
10 or one point nine and the cube lid and Q proxy could be at one point eight.
None of them could be at a worse and higher than the Cube API server 1.0 11.
Now this is not the case with cube control.
The cube control utility could be at one or 11 percent higher than the API server 1.0 10, the same
version as the API server or at one point nine version lower than the API server.
Now, this permissable skew in versions allows us to carry out live upgrades.
We can upgrade component by component if required.
So when should you upgrade?
So you were at one point ten and coordinators releases versions one 11 and 12 at any time Cuban and
his support only up to the recent three minor versions.
So with one or 12 being the latest release, coroneted supports versions one, not 12, one not eleven
and one, not 10.
So when one or 13 is released, only versions one 13, one 12 and 11 are supported before the release
of one 13 would be a good time to upgrade your cluster to the next release.
So how do we upgrade?
Do we upgrade directly from 10 to 13?
Know the recommended approach is to upgrade one minor version at a time version 1.0 10 to one at then
one 11 to 12 and then load 12 to 13.
The upgrade process depends on how your cluster is set up.
For example, if your cluster is a managed carbonaceous cluster deployed on cloud service providers
like Google, for instance, Google coordinates engine lets you upgrade your cluster easily with just
a few clicks.
If you deployed your cluster using tools like Badme, then the tool can help you plan and upgrade the
cluster.
If you deployed your cluster from scratch, then you manually upgrade the different components of the
cluster yourself.
In this lecture, we will look at the options by Cube SDM.
So you have a cluster with master and worker nodes running in production, hosting pods, serving users.
The nodes and components are worse than one that ten.
Upgrading a cluster involves two major steps.
First, you upgrade your master nodes and then upgrade the worker nodes while the master is being upgraded.
The control plane components such as the API server.
Scheduler and controller managers go down briefly, the master going down does not mean work or nodes
and applications on the cluster are impacted.
All workloads hosted on the worker nodes continue to serve users as normal.
Since the master is done, all management functions are done.
You cannot access the cluster using control or other components API.
You cannot deploy new applications or delete or modify existing ones.
The controller managers don't function either.
If a power was to fail, a new pod won't be automatically created.
But as long as the nodes and the pods are up, your applications should be up and users will not be
impacted.
Once the upgrade is complete and the cluster is back up, it should function normally.
We now have the master and the master components at more than one large 11 and the worker nodes at version
1.0 10.
As we saw earlier, this is a supported configuration.
Is now time to upgrade the worker nodes?
There are different strategies available to upgrade the worker nodes.
One is to upgrade all of them at once, but then your pods are down and users are no longer able to
access the applications.
Once the upgrade is complete, the notes are back up, new pods are scheduled and users can resume access.
That's one strategy that requires downtime.
The second strategy is to upgrade one node at a time.
So going back to the state where we have our master upgraded and node waiting to be upgraded, we first
upgrade the first node where the workloads move to the second and third node and users are so far from
there.
Once the first note is upgraded and back up with an update, the second node where the workloads move
to the first and third node.
And finally, the third node where the workloads are shared between the first two, until we have all
nodes upgraded to a newer version, we then follow the same procedure to upgrade the nodes from one
not 11 to 12 and then one to 13.
A third strategy would be to add new nodes to the cluster nodes with newer software version.
This is especially convenient if you're on a cloud environment where you can easily provision new nodes
and decommission old ones, nodes with the newer, softer version can be added to the cluster, move
the workload over to the new.
And remove the old not.
Until you finally have all new notes with the new software version.
Let us now see how it is done, so we were to upgrade this cluster from one, not 11 to 13, Curium
has an upgrade command that helps in upgrading clusters with curium run the security upgrade plan command,
and it will give you a lot of good information.
The current cluster version, the be tooele version, the latest table version of commonalties.
Then it lists all the control plane components and their versions and what version these can be upgraded
to.
It also tells you that after we upgrade the control plane components, you must manually upgrade the
CubeSat versions on each node.
Remember to EDM does not install or upgrade.
Finally, it gives you the command to upgrade the cluster.
Also note that you must upgrade the aquarium tool itself before you can upgrade the cluster.
The aquarium to also follows the same software version as commonalties.
So we are at one dot 11 and we want to go to one dot 13.
But remember, we can only go one minor version at a time.
So we first go to one or 12, first upgrade the aquarium tool itself to version 1.0 12, then upgrade
the cluster using the command from the upgrade plan output, herbarium upgrade, apply it, post the
necessary images and upgrade the cluster components once complete your control plane components are
now at one dot twelve.
If you run the cube control get nodes command, you will still see the master node at one point eleven.
This is because in the output of this command, it is showing the versions of Kubilius on each of these
nodes registered with the API server and not the version of the API server itself.
So the next step is to upgrade the cube.
Let's remember, depending on your setup, you may or may not have Kuebler running on your master node.
In this case, the cluster deployed with curium has Kubla on the master node, which are used to run
the control plane components as part of the master note.
When we set up a component as cluster from scratch later during this course, we do not install it on
the master node.
You will not see the master node in the output of this command in that case.
So the next step is to upgrade Kubelik on the master node.
If you have Kubla on them, run the Apte get upgrade Kubla to command for this.
Once the package is upgraded, restart the cube.
Let's service.
Running the cube control get no comment now shows that the master has been upgraded to one, not 12.
The worker notes are still at one dot 11.
So next, the worker notes, let us start one at a time, we need to first move the workload from the
first worker node to the other nodes.
The control drain command lets you safely terminate all the pods from a node and reschedules them on
the other nodes.
It also corden's the node and marks it unredeemable.
That way, no new ports are scheduled on it, then upgrade the curium and Kubelik packages on the worker
nodes as we did on the master node.
Then using the cube adiam to upgrade command update the node configuration for the new Kubelik version,
then restart the Kubla to service.
The node should now be up with the new software version.
However, when we drain the node, we actually marked it on schedule, so we need to unmask it by running
the command control.
Uncoordinated node one.
The node is now scheduled, but remember that it is not necessary that the pods come right back to this
node.
It is only marked as dealable only when the parts are deleted from the other node or when new parts
are scheduled to really come back to this first note.
Well, it will soon come when we take down the second node to perform the same steps to upgrade it.
And finally, the third node.
We now have all nodes upgraded.
Well, that's it for this lecture.
Head over to the practice test where you will practice upgrading and live cluster with applications
running on it without taking the applications down.
Good luck.