When it comes to your cloud ecosystem and environments, proper planning and management are crucial to minimize production downtime and ensure uninterrupted workload performance. In this blog series “Managing your cloud ecosystems,” we will explore different strategies to help you achieve a smooth and seamless setup with minimal disruption.

Starting off, this blog post will delve into the topic of ensuring continuity of workload during worker node upgrades.

What Are Worker Node Upgrades?

Worker node upgrades involve applying important security updates and patches on a regular basis. To learn more about the different types of worker node upgrades, refer to the IBM Cloud Kubernetes Service documentation on Updating VPC worker nodes and Updating Classic worker nodes.

During an upgrade, some of your worker nodes may become temporarily unavailable. It is crucial to ensure that your cluster has enough capacity to continue running your workload throughout the upgrade process. Implementing a pipeline to update your worker nodes without causing application downtime will allow you to regularly apply worker node upgrades with ease.

Strategies for Classic Worker Nodes

To manage classic worker nodes, create a Kubernetes configmap that specifies the maximum number of worker nodes that can be offline at a time, including during upgrades. You can also use labels to apply different rules to different worker nodes. For detailed instructions, refer to the Kubernetes service documentation on Updating Classic worker nodes in the CLI with a configmap. If you choose not to create a configmap, the default maximum offline worker node limit is 20%.

If you need to keep the total number of worker nodes online, you can temporarily add extra worker nodes to your cluster using the ibmcloud ks worker-pool resize command during the upgrade. Once the upgrade is complete, you can use the same command to remove the additional worker nodes and return your worker pool to its original size.

Strategies for VPC Worker Nodes

Upgrading VPC worker nodes involves replacing the old nodes with new ones that run on the latest version. While you can upgrade multiple worker nodes simultaneously, they will be unavailable during the process. To ensure sufficient capacity for running your workload, you can either resize your worker pools by temporarily adding extra nodes (similar to the procedure for classic worker nodes) or upgrade your worker nodes one by one.

In Summary

Whether you choose to implement a configmap, resize your worker pool, or upgrade nodes individually, developing a workload continuity plan before performing worker node upgrades is essential in achieving a smoother and more efficient setup with minimal downtime.

With a plan in place to prevent disruptions during worker node upgrades, stay tuned for the next blog post in our series, where we will discuss the best practices for implementing major, minor, or patch upgrades for your clusters and worker nodes.

Learn more about IBM Cloud Kubernetes Service clusters