Updated on 2024-01-29 GMT+08:00

Upgrade Overview

CCE strictly complies with community consistency authentication. It releases three cluster versions each year and offers a maintenance period of at least 24 months after each version is released. CCE ensures the stable running of cluster versions during the maintenance period.

To ensure your service rights and benefits, upgrade your Kubernetes clusters before a maintenance period ends. Proactive cluster upgrades help you:

  1. Reduce security and stability risks: During the iteration of Kubernetes versions, known security and stability vulnerabilities are continuously fixed. Long-term use of EOS clusters will result in security and stability risks to services.
  2. Experience the latest functions: During the iteration of Kubernetes versions, new functions and optimizations are continuously released. For details about the features of the latest version, see Release Notes for CCE Cluster Versions.
  3. Minimize compatibility risks: During the iteration of Kubernetes versions, APIs are continuously modified and functions are deprecated. If a cluster has not been upgraded for a long time, more O&M assurance investment will be required when the cluster is upgraded. Periodic upgrades can effectively mitigate compatibility risks caused by accumulated version differences. It is a good practice to upgrade a patch version every quarter and upgrade a major version to the latest version every year.
  4. Obtain more effective technical support: CCE does not provide security patches or issue fixing for EOS Kubernetes cluster versions, and does not ensure technical support for the EOS versions.

You can check Kubernetes cluster versions on the cluster list page and view if there is a new version for a cluster to upgrade. If necessary, obtain the expert consultation service.

Cluster Upgrade Process

The cluster upgrade process involves pre-upgrade check, backup, upgrade, and post-upgrade verification.

Figure 1 Process of upgrading a cluster

After determining the target version of the cluster, read the precautions carefully and prevent function incompatibility during the upgrade.

  1. Pre-upgrade check

    Before a cluster upgrade, CCE checks mandatory items such as the cluster status, add-ons, and nodes to ensure that the cluster meets the upgrade requirements. For more details, see Pre-upgrade Check. If any check item is abnormal, rectify the fault as prompted on the console.

  2. Backup

    You can use disk snapshots to back up master node data, including CCE component images, component configurations, and etcd data. Back up data before an upgrade. If unexpected cases occur during an upgrade, you can use the backup to quickly restore the cluster.

  3. Configuration and upgrade

    Configure parameters before an upgrade. CCE has provided default settings, which can be modified as needed. After the configuration, upgrade add-ons, master nodes, and worker nodes in sequence.

    • Add-ons

      Patch upgrades are minor version upgrades. Add-ons are compatible with the target version and do not need to be upgraded separately.

      During a major cluster version upgrade, incompatible add-ons will be automatically upgraded.

    • Nodes
      • You can configure the number of nodes that can be concurrently upgraded. A larger number indicates a faster upgrade.
      • You can configure upgrade priorities, including the priority for upgrading node pools and that for upgrading nodes in a node pool. If you skip this setting, CCE will upgrade nodes using the default policy.
  4. Post-upgrade verification

    After an upgrade, CCE will automatically check items including the cluster status and node status. You need to manually check services, new nodes, and new pods to ensure that the cluster functions properly after the upgrade.

Cluster Upgrade

The following table describes the target version to which each cluster version can be upgraded and the supported upgrade modes.

Table 1 Cluster upgrade

Source Version

Target Version

Upgrade Mode

1.25

v1.27

In-place upgrade

v1.23

v1.27

v1.25

In-place upgrade

v1.21

v1.25

v1.23

In-place upgrade

v1.19

v1.23

v1.21

In-place upgrade

v1.17

v1.19

In-place upgrade

v1.15

v1.19

In-place upgrade

v1.13

v1.11

v1.9

v1.7

Latest version that can be created on the console

Migration

Upgrade Modes

Table 2 Upgrade modes

Upgrade Mode

Description

Upgrade Scope

Advantage

Constraint

In-place upgrade

Kubernetes components, network components, and CCE management components are upgraded on nodes. During an upgrade, service pods and networks are not affected.

Nodes are upgraded in batches. Only the nodes that have been upgraded can be used to schedule services.

  • Node OSs are not upgraded.
  • The add-ons that are incompatible with the target cluster version will be automatically upgraded.
  • Kubernetes components will be automatically upgraded.

The one-click upgrade does not need to migrate services, which ensures service continuity.

In-place upgrade is supported only in clusters of v1.15 or later.

Migration

The services running in a cluster of an earlier version are migrated to a cluster of a later version. This mode is suitable for cross-version cluster upgrades.

All resources in the cluster must be redeployed.

This mode prevents version incompatibility caused by consecutive upgrades of earlier versions.

None