Updated on 2024-07-05 GMT+08:00

Before You Start

Before the upgrade, you can check whether your cluster can be upgraded and which versions are available on the CCE console. For details, see Upgrade Overview.

Precautions

Before upgrading a cluster, note the following:
  • Perform an upgrade during off-peak hours to minimize the impact on your services.
  • Before upgrading a cluster, learn about the features and differences of each cluster version in Kubernetes Version Release Notes to prevent exceptions due to the use of an incompatible cluster version. For example, check whether any APIs deprecated in the target version are used in the cluster. Otherwise, calling the APIs may fail after the upgrade.

During a cluster upgrade, pay attention to the following points that may affect your services:

  • Before upgrading a cluster, ensure no high-risk operations are performed in the cluster. If there are high-risk operations, the cluster upgrade may fail or the configuration may be lost after the upgrade. For example, modifying the configuration of a listener configured for CCE on the ELB console is a high-risk operation. It recommended that you modify configurations on the CCE console so that the modifications can be automatically inherited during the upgrade.

Constraints

If an error occurred during a cluster upgrade, the cluster can be rolled back using the backup data. If you perform other operations (for example, modifying cluster specifications) after a successful cluster upgrade, the cluster can be rolled back using the backup data.

Deprecated APIs

With the evolution of Kubernetes APIs, APIs are periodically reorganized or upgraded, and old APIs are deprecated and finally deleted. The following tables list the deprecated APIs in each Kubernetes community version. For details about more deprecated APIs, see Deprecated API Migration Guide.

When an API is deprecated, the existing resources are not affected. However, when you create or edit the resources, the API version will be intercepted.

Upgrade Backup

How to back up a node:

Backup Method

Backup Object

Backup Type

Backup Time

Rollback Time

Description

etcd data backup

etcd data

Automatic backup during the upgrade

1–5 minutes

2 hours

Mandatory. The backup is automatically performed during the upgrade.

EVS snapshot backup

Master node disks, including component images, configurations, logs, and etcd data

One-click backup on web pages (manually triggered)

1–5 minutes

20 minutes

-