Boosting Cloud Performance during Node Upgrades

It is essential to plan and manage your cloud ecosystem and environments in order to minimize production downtime and keep a functional workload. In the blog series titled “Managing your cloud ecosystems,” we examine a variety of tactics that may be utilized to ensure that your infrastructure runs smoothly and with a minimum of interruptions.

This blog series will begin with the first issue, which is the process of ensuring that workload continuity is maintained throughout upgrades to worker nodes.

What are upgrades for worker nodes?

Upgrades to worker nodes install critical updates and patches to the system’s security, and they should be done on a regular basis. Updating VPC worker nodes and Updating Classic worker nodes are two different forms of worker node upgrades. The documentation for IBM Cloud Kubernetes Service contains more information on these types of worker node upgrades.

While you are doing an upgrade, it is possible that some of your worker nodes will become inaccessible. During the course of the upgrade process, it is essential to check that your cluster has adequate capacity to continue processing the workload it is now handling. You will be able to quickly apply worker node updates on a regular basis if you construct a pipeline that allows you to update your worker nodes without causing the application to go down.

In the case of traditional worker nodes

You will need to create a Kubernetes configmap that specifies the maximum number of worker nodes that can be offline at any given moment, even while an upgrade is being performed. The maximum value is expressed as a percentage in the specification. Labels can also be used to apply separate sets of rules to various worker nodes in the system. For comprehensive procedures, refer to the section of the Kubernetes service documentation titled “Updating Classic worker nodes in the CLI with a configmap.” If you decide not to construct a configmap, the default maximum amount of worker nodes that can become unavailable is 20%. This number can be increased by using the –max-worker-nodes flag.

If you want to make sure that your total number of worker nodes continues to function normally throughout the upgrading process, you may use the ibmcloud ks worker-pool enlarge command to make your cluster temporarily take on additional worker nodes so that it can handle the increased workload. After the upgrade has been completed, you can use the same command to get rid of the new worker nodes and restore the size of your worker pool to how it was before the upgrade.

When replacing VPC worker nodes, the previous worker node will need to be deleted, and its place will be taken by a new worker node that is provisioned to run the latest version of the software. You are able to simultaneously upgrade a single worker node or several worker nodes; but, if you upgrade multiple worker nodes at once, all of those nodes will become unavailable simultaneously. You have the option of planning to either enlarge your worker pools to temporarily add extra worker nodes (in a manner that is analogous to the procedure described for classic worker nodes) or you may plan to upgrade each of your worker nodes individually in order to guarantee that you will have sufficient capacity to execute your workload during the upgrade.

Finish up

Whether you decide to apply a configmap, resize your worker pool, or upgrade components one-by-one, developing a workload continuity plan before upgrading your worker nodes will assist you in building a more streamlined, efficient setup with less downtime. This is because the plan will help you plan for how you will handle the workload during the upgrade process.