Safely Upgrading Kubernetes Clusters Across Multiple Cloud Providers

Upgrading your Kubernetes clusters can be a delicate process, but with Avisi Cloud, you can easily manage it without affecting your overall cluster or application availability, at scale, across multiple clouds.

Upgrading your infrastructure to a newer version is an essential task to keep everything secure and performant. Performing this task often helps with being agile and allows you to quickly respond to changes within your business. Kubernetes clusters are no different - but this process is not always easy!

With the Avisi Cloud console, updating your Avisi Cloud Kubernetes cluster is a straightforward process. However, before you start upgrading, it’s essential to review the Release notes and understand the impact the upgrade may have on your cluster. The release notes for the latest Avisi Cloud Kubernetes versions are available on our documentation website.

In this blog post, we’ll guide you through the upgrade process and discuss the impact of upgrading between different versions. We’ll also cover the lifecycle and version policy of Avisi Cloud Kubernetes to help you plan your cluster updates effectively.

Table of Contents

Concepts

Before upgrading your Avisi Cloud Kubernetes cluster, it’s important to understand some basic concepts. First, there are different update channels available.

• The Stable update channels are recommended for production clusters, as it includes versions that have been battle-tested on various production clusters.
• The Beta update channels are more suitable for non-production clusters like staging or development environments, but using a Stable branch is often recommended for all clusters.
• Finally, the Alpha update channels are designed for users who want to use the latest Kubernetes release available. This can be useful for testing custom Kubernetes controllers before deploying them to production clusters.

In addition to update channels, you can also manually select an available Avisi Cloud Kubernetes version. Older versions will remain available until they reach their end-of-life or contain a security issue.

It’s important to note that when upgrading, different upgrade impacts may occur, depending on whether you’re upgrading between different Kubernetes patch versions or between different minor versions. You can find more information about the upgrade impact and our version policy in our lifecycle policy documentation, and we will talk some more about this later in this post.

Impact of Upgrading Your Avisi Cloud Kubernetes Cluster

Each Avisi Cloud Kubernetes release provides details about the impact of upgrading from the previous version. Some rules always apply and are not explicitly mentioned in each release’s impact section:

When upgrading, there will be a node recycle, unless otherwise specified in the release’s impact section. A node recycle means that any Virtual Machine joined to the cluster will be replaced by a new machine with up-to-date software.

When upgrading between Kubernetes minor versions (e.g., v1.20.x to v1.21.x), there may be a brief period of API downtime due to an etcd upgrade.

Lifecycle

We follow the Kubernetes version policy, as documented in the Kubernetes version skew policy. This means that Avisi Cloud supports the three latest minor versions of Kubernetes.

Upgrading your Avisi Cloud cluster

How to start an upgrade

To upgrade your Avisi Cloud Kubernetes cluster to a new version, start by navigating to the cluster detail page. You can find the detail page for your cluster by first navigating to the environments view at console.avisi.cloud/environments and selecting the environment in which your cluster is provisioned. Once you have selected your environment, you will see a table with all clusters available in that environment. Click on the name of the cluster you wish to upgrade to open its detail page.

On the cluster detail page, you will see information such as the version your cluster is currently running, the region it is provisioned in, the size of the cluster, and any cluster-specific settings, such as whether or not auto upgrades are enabled.

During the process of upgrading your Avisi Cloud Kubernetes cluster, there are a few things to keep in mind. Upgrading the control plane typically takes an average of 2 minutes, while upgrading the nodes in your cluster can take anywhere from 1 to 5 minutes, depending on the cloud provider you are using. In the event of a failed upgrade, Avisi Cloud will automatically retry the process.

Upgrade your cluster

In order to upgrade, click on the “update available” link to open the upgrade cluster modal. After opening the modal, you will see the different upgrade options available to you. Select the version you want to upgrade to and confirm the upgrade. The upgrade process will start automatically, and you will be able to monitor the progress of the upgrade from the cluster detail page.

When you are using an update channel, you will not be able to select a specific version and instead are only able to start the upgrade process.

In the cluster

During the upgrade process, nodes in the cluster will be replaced. The upgrade is complete once all nodes show the new Kubernetes version. You can validate this by using the following command:

kubectl get nodes -o wide

To validate the version of your control plane, use the following command:

kubectl version

Avisi Cloud uses a surge style upgrade strategy. Surge style upgrades are an upgrade strategy that ensures that a new node is provisioned before the old node is replaced. This helps to ensure that the cluster remains highly available during the upgrade process. In this way, a new node is added to the cluster and becomes ready to receive traffic before an old node is removed from the cluster, allowing the workload to be evenly distributed across both the old and new nodes.

Troubleshooting

In some cases, you may experience issues when upgrading your cluster, which can cause delays in completion time. One such case is when running a workload, such as Postgres, that uses a graceful shutdown method. This method waits until all client connections have disconnected before exiting, which can add to the upgrade time.

Another issue that can cause delays is when you have standalone pods deployed without making use of either a StatefulSet, Deployment, or DaemonSet. During node replacement, these pods will be removed and will not be recreated, leading to delays in the upgrade process.

In such cases, it may be necessary to manually shut down some applications to speed up the upgrade process. If you experience any other issues during the upgrade process, please contact Avisi Cloud support for assistance.

Conclusion

In conclusion, upgrading your Avisi Cloud Kubernetes cluster is a straightforward process that can be done with just a few clicks.

With the release notes and upgrade impact information provided, you can make an informed decision about which upgrade path to take. And with Avisi Cloud’s surge-style upgrade strategy, the process is optimized for speed and reliability.

Best of all, the upgrade process is uniform across all public cloud providers, so you can easily keep your clusters up-to-date regardless of where they are hosted. If you have any issues during the upgrade process, Avisi Cloud’s support team is always available to help you troubleshoot and resolve any problems.