Cluster Version Upgrading

This article mainly introduces how to use the version upgrade feature in the UK8S cluster.

Major version upgrading is temporarily only available to UK8S clusters with a version equal to or above 1.14; Docker-container runtime only supports up to version 1.22

Precautions

1. Please make sure to close the scaling group plugin in the cluster before upgrading!
2. The current version upgrade supports major and minor version upgrades.
3. Since the API and components vary significantly between major versions, the major version upgrade now supports clusters with versions greater than or equal to 1.14.
4. Minor version upgrades support upgrading to the latest minor version maintained by UK8S, which can be checked by clicking on version upgrade.
5. Version upgrading will cause the cluster container to restart. There are several scenarios because of the restart:
   1. A 1.14 version cluster is undergoing a major version upgrade, upgrading to 1.15, 1.16, 1.17, 1.18
   2. A 1.15 version cluster is undergoing a major version upgrade, upgrading to 1.16, 1.17, 1.18
   3. Single node upgrade time is too long (in kubernetes, if the node is NotReady for more than 5 minutes, the Pods will float to other Ready nodes)
6. Before upgrading, please check whether the parameters of the component provided by uk8s have been manually adjusted. If adjustment is made, upgrade failure or overwriting of component parameters after successful upgrade may occur.

Upgrade Operation

Please create an account with Root permissions on all nodes in the cluster before the cluster upgrade and ensure the password is the same, and close the cluster scaling plugin in the cluster.

We choose the cluster that needs to be upgraded on the cluster list page, and we can see the "Version Upgrading" after clicking the operation button "More".

After clicking "Version Upgrading", enter the "UK8S Version Upgrading" interface.

In this interface, you can set the target version for the upgrade, upgrade strategy, provide SSH account and password, and whether to force upgrade.

Forced upgrade will ignore the K8S cluster precheck and proceed directly with the upgrade, still requiring the correct Root account password input.

The optional upgrade strategies are:

• Exponential batch upgrade: using exponential batch upgrade will upgrade the nodes in each batch by 1, 2, 4, 8, 16, 32. As multiple replicas of the applications in the cluster are deployed on the same batch of nodes being upgraded, using this upgrade strategy carries the risk of service interruption at the minute level.

• Gradual upgrade: using gradual upgrade only one node is upgraded each time, the upgrade process is relatively long when the number of nodes is large, so please plan the upgrade window accordingly.

Set the above options, press the "Upgrade Now" button to enter the cluster upgrade operation progress interface. The cluster upgrade operation is time-consuming, please be patient. Do not operate on the cluster nodes during the upgrade to ensure a smooth upgrade.

Upgrade time for the cluster varies depending on the node, for example, a cluster with 10 nodes takes about 10 minutes. You can close this page during the upgrade process, and you can check the upgrade progress at any time by clicking on "Version Upgrade" in the cluster list.

Upgrade Pause

In order to support large-scale cluster upgrade operations that need to be temporarily stopped, the UK8S console provides a "Stop Upgrade" feature, providing users with more ways to control complex cluster upgrade operations. Press the "Stop Upgrade" button during the upgrade process, as shown in the figure below, to pause the UK8S cluster upgrade operation.

After clicking this button, the system will prompt the following:

If you really need to stop the upgrade operation, press the "Confirm" button. After the nodes in the current batch have completed the upgrade operation, the system will stop upgrading the other nodes that have not started. Below is a sample display of the interface after the cluster upgrade is stopped:

According to the above figure, you can observe that some of the master nodes in the cluster have been upgraded to the target version. The other master nodes are still the original version. If you need to resume the upgrade, you can enter the upgrade interface again by clicking "Version Upgrade" in the cluster list.

Upgrade Failure

In case of upgrade failure, you can click on the operation button "More" in the cluster list page to see "Version Upgrade" and download the upgrade log. If the failure is due to your operation to the cluster during the upgrade, you can modify it according to the log prompt and then proceed with the upgrade operation.

If you cannot judge based on the content of the log, please contact our technical support, diagnose the cluster and then proceed with the upgrade.

Common Upgrade Failure Reasons

• Cluster nodes are shut down or kubelet running status is abnormal
• SSH access to cluster nodes is not possible, password error, etc.
• Cluster nodes can SSH, but have no Root permissions
• The cluster scaling plug-in is not closed, leading to the lack of operation permissions for the nodes newly joined in the cluster.