Updated on 2024-06-26 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:

  • 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.
  • Experience the latest functions: During the iteration of Kubernetes versions, new functions and optimizations are continuously released.
  • 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.
  • 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 Path

CCE Autopilot clusters evolve iteratively based on the community Kubernetes version. A CCE cluster version consists of the community Kubernetes version and the CCE patch version. Therefore, two cluster upgrade paths are provided.

  • Kubernetes version

    Source Kubernetes Version

    Target Kubernetes Version

    v1.27

    v1.28

    v1.28

    /

    A Kubernetes version can be upgraded only after the patch is upgraded to the latest version. CCE will automatically generate an optimal upgrade path on the console based on the current cluster version.

  • Patch version

    Patch version management is available for CCE Autopilot clusters to provide new features and fix bugs and vulnerability for in-maintenance clusters without requiring a major version upgrade.

    After a new patch version is released, you can upgrade to the latest patch version at any time.

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 Troubleshooting for Pre-upgrade Check Exceptions. 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 your data before an upgrade. If unexpected cases occur during an upgrade, you can use the backup to quickly restore the cluster.

    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.

    CBR cloud server backup

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

    One-click backup on web pages (manually triggered)

    20 minutes to 2 hours (based on the cloud backup tasks in the current region)

    20 minutes

    This function is gradually replaced by EVS snapshot backup.

    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

    This function is coming soon.

    After this function is released, it will replace CBR cloud server backup.

  3. Configuration and upgrade

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

    • Add-on Upgrade Configuration: Add-ons that have been installed in your cluster are listed. During the cluster upgrade, CCE Autopilot automatically upgrades the selected add-ons to be compatible with the target cluster version. You can click Set to re-define the add-on parameters.

      If an add-on is marked with on its right side, the add-on cannot be compatible with both the source and target versions of the cluster upgrade. In this case, CCE will upgrade the add-on after the cluster upgrade. The add-on may be unavailable during the cluster upgrade.

  4. Post-upgrade verification

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