Planning and managing your cloud ecosystem and environments is critical for reducing production downtime and maintaining a functioning workload. In the “Managing your cloud ecosystems” blog series, we cover different strategies for ensuring that your setup functions smoothly with minimal downtime.

In the second blog of the series, we’re discussing best practices for upgrading your clusters to newer versions. If you haven’t already, make sure you also check out our previous entry on ensuring workload continuity during worker node upgrades.

Major, minor and patch upgrades

The Kubernetes community releases new Kubernetes major/minor versions every three to four months. The IBM Cloud Kubernetes Service release cycle closely mimics this schedule, with new releases based on the most recent community version. These major or minor upgrades introduce new features and operation changes and deprecate or stabilize existing features. You are responsible for applying these updates to the cluster master and worker nodes.

Patch updates are released by IBM Cloud on a bi-weekly basis and include community patches, security patches and component updates. Patch updates are automatically applied to cluster masters, but you are responsible for updating your cluster’s worker nodes. Changes included in patch updates are documented in the version change logs.

For more information about each upgrade type, see the IBM Cloud Kubernetes Service version information or the Kubernetes community release history.

Before you upgrade

Before you begin the upgrade process, it is important to fully analyze and understand the changes included in the release to determine if you must adjust your setup. For instance, you may need to change any scripts that rely on features that are deprecated or unsupported in the new version. You can find details on what is included in new version releases in the IBM Cloud Kubernetes service documentation.

Applying upgrades

When you apply version upgrades, it’s important to take a step-by-step approach that prevents downtime for your services. Begin in your development environment, followed by your QA clusters. Then, if there are no issues, upgrade your production environment.

1. Upgrade the cluster master in your development environment by running the following command. For more detailed steps, see Steps to update the cluster master in the IBM Cloud Kubernetes Service docs. (Note: This step is for major or minor upgrades. For patch updates, skip to step 2).

ibmcloud ks cluster master update --cluster <cluster_name> --version <new_version>

This process might take some time, but you can track its progress with the ibmcloud ks cluster get --cluster <cluster_name> command. In the output, look for the Master → Version field. When the new version is listed, the master upgrade is complete.

2. Next, upgrade the worker nodes in your development environment. Be aware that worker nodes temporarily become unavailable when upgrading. Review our previous blog post on worker node upgrades to determine the best way to complete this step, based on your setup, to ensure that your workload continues to run while the worker nodes upgrade.

3. When the cluster master and worker nodes in your development cluster are all upgraded, take time to test your services. Any issues you encounter should be addressed at this point before you upgrade your production-level clusters.

4. After completing the first round of testing, repeat steps 1 through 3 for your QA cluster or any other pre-production clusters.

5. When all of your pre-production clusters have been upgraded and tested, and there are no issues that need to be addressed, repeat steps 1 through 3 for your production clusters.

Wrap up

Keeping your clusters up to date with the latest Kubernetes version is essential for a healthy workload. By beginning the upgrade process in your pre-production environment and testing your services at each step, you can prevent issues and downtime when you upgrade your production-level clusters.

Be sure to look out for the next blog in our series, which will cover migrating workers to a new OS version.