Managing your cloud ecosystems: Migrating to a new Ubuntu operating system version – IBM Blog

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 third blog of the series, we’re discussing migrating your worker nodes to a new Ubuntu operating system. If you haven’t already, make sure you also check out our previous entries on ensuring workload continuity during worker node upgrades and upgrading your cluster to a new version.

OS support on IBM Cloud Kubernetes Service

IBM Cloud Kubernetes Service supports the Ubuntu OS and regularly moves to newer Ubuntu versions. Currently, the default OS for cluster worker nodes is Ubuntu20.

To avoid disruptions to your workload, you are responsible for migrating your worker nodes to new OS versions as they become available. IBM Cloud notifies users of upcoming OS releases and deprecations several months in advance to give users time to make any necessary preparations.

Best practices for migrating

The steps to migrate to a new OS are found in the IBM Cloud Kubernetes Service documentation. However, before you begin, you should consider the order in which you migrate your components. Just as we described for upgrading cluster versions, always start the migration process in your development environment, followed by any other pre-production environments. Test your services along the way and address any issues that arise before making any changes in production. Then, if there are no issues, continue the migration in your production environment.

Testing services during OS migrations

Testing your services throughout the process is important for minimizing downtime from any issues that may arise. Keep in mind that the steps for migrating to a new OS involve creating new worker pools that populate with worker nodes at the latest version and then deleting the original worker pools. Before deleting the original worker pools, consider scaling them down and keeping them for several days before you remove them. This way, you can scale the original worker pool back up if your workload experiences disruptions or if you encounter any issues during testing. When you determine that your workload is stable and functions normally, you can remove the original worker pools.

Wrap up

Keeping your worker node OS up to date is important for keeping your Kubernetes setup running smoothly. When migrating your worker nodes, it’s important to work in one environment at a time and to leave plenty of opportunity for testing at each step.

In our next and final blog entry for this series, we’ll discuss how you can maintain optimal consistency across your setup.

Learn more about IBM Cloud Kubernetes Service clusters