Alauda Container Platform

Overview

ACP 4.3 uses a Cluster Version Operator (CVO)-based workflow for cluster upgrades.

In the Web Console, the upgrade request now follows a two-step flow: review RPCH items first, and then submit the upgrade request in a separate confirmation step.

When moving the platform to a new ACP Distribution Version, the upgrade normally proceeds in two stages:

  1. Upgrade the global tier to the target Distribution Version by following the validated global-cluster procedure, including artifact preparation and preflight checks.
  2. After the global tier reaches the target Distribution Version, upgrade workload clusters from the supported workload-cluster entry point and observe cluster status until each target cluster reaches the same Distribution Version.

A workload cluster can be upgraded only to a Distribution Version that the global tier has already reached. In environments with global disaster recovery (DR), this means both the standby and primary global clusters must reach the target Distribution Version before workload clusters are upgraded to that Distribution Version. This sequencing rule does not replace the Compatible Versions prerequisite: before the global tier is upgraded to ACP 4.3, workload clusters must remain within the ACP 4.3 compatible Kubernetes version range.

TOC

Key ConceptsUpgrade Scope and SequencingCVO Management ScopeUpgrade Entry PointsRelated Documentation

Key Concepts

  • ClusterVersionShadow (cvsh): The upgrade resource used to track current version, desired version, preflight results, execution stages, and history.
  • Distribution Version: The ACP version currently reached by a cluster. A workload cluster can be upgraded only to a Distribution Version that the global tier has already reached.
  • Preflight: Validation checks that run before the upgrade starts applying the target version. For workload clusters, review preflight results from the upgrade status output after the upgrade request is submitted.
  • Available upgrade targets: The upgrade versions that are currently offered for a cluster. In the Web Console, the target version for the current upgrade flow is determined by the platform.
  • upgrade.sh: The preparation script that uploads artifacts and deploys or updates the cluster version operator before the upgrade proceeds.
  • Global DR environment: An environment with both a primary global cluster and a standby global cluster.
  • Primary global cluster: The global cluster that the platform access domain currently resolves to.
  • Standby global cluster: The other global cluster in the DR pair. After a failover, the roles of the two clusters are swapped.

Upgrade Scope and Sequencing

A complete ACP upgrade is staged. Each cluster is upgraded in a single maintenance window, but the platform is moved cluster by cluster, with global first and workload clusters second.

A single cluster upgrade window covers four kinds of work:

Work itemRequired?How it is upgradedIf you run immutable OS
Core (the platform itself)RequiredCVO, driven by upgrade.sh-prepared artifactsSame control flow; the Kubernetes step is handled separately, see below
Aligned plugins (cluster plugins and operators released together with the matching ACP version)Required in the same windowCVO by default; can also be upgraded individually through the cluster plugin or operator workflow when an out-of-band fix is neededSame
KubernetesRequired in the same windowReplace VMs from a new MicroOS-based DCSMachineTemplate (or equivalent immutable template) through Cluster API rolling updatesThe Kubernetes upgrade procedure lives in the immutable infrastructure documentation; see Upgrading Clusters on Huawei DCS, Upgrading Clusters on VMware vSphere, or Upgrading Clusters on Huawei Cloud Stack
Agnostic plugins (independently released cluster plugins and operators)Optional, per pluginUpgrade each cluster plugin or operator from Marketplace > Cluster Plugins or the operator's own workflow after the cluster reaches the target Distribution VersionSame

A few rules govern when each piece moves:

  • The platform requires that a cluster's Kubernetes version is upgraded together with its Core and Aligned versions; mixing a new Core release with an old Kubernetes minor version is not validated.
  • Cluster plugins are global resources. Pushing a cluster plugin to the global tier makes it installable and upgradable on every cluster in the platform; you do not push the same cluster plugin again per workload cluster.
  • Operators are scoped to each cluster. Pushing operators to the global tier is recommended but not sufficient on its own; the same operator must be available on each workload cluster before the workload upgrade. If you forgot to push an operator during the global window, you can push it again before the workload upgrade as a fallback.
  • Workload-cluster upgrades are only required when a workload cluster falls outside the target ACP release's Kubernetes Support Matrix. Workload clusters that stay within the supported range can keep their existing Kubernetes version after the global tier moves; the platform will continue to manage them.

CVO Management Scope

The Cluster Version Operator (CVO) decides which kinds of upgrades it drives end to end:

Lifecycle typeDriven by CVO?Notes
CoreYes, CVO is the only supported pathCore upgrades require the artifacts that upgrade.sh prepares; CVO consumes those artifacts.
Aligned pluginsYes by defaultThe cluster plugin or operator workflow can also upgrade an individual Aligned plugin out of band — for example, to apply a critical security fix without moving the cluster to a new Distribution Version.
Agnostic pluginsNoCVO does not manage these. Upgrade each cluster plugin from Marketplace > Cluster Plugins and each operator from its own workflow after the cluster reaches the target Distribution Version.

Customers running real production maintenance windows usually move Core, Aligned, and the in-use Agnostic plugins together. The upgrade pages below document that path: prepare every needed artifact during pre-upgrade, drive Core and Aligned through CVO, and finish the in-use Agnostic plugins from Marketplace.

Upgrade Entry Points

  • Global clusters: Follow the validated upgrade.sh-based procedure. After the preparation phase completes, request the upgrade from the Web Console through the two-step RPCH review flow, use ACP CLI, or update ClusterVersionShadow.spec.desiredUpdate directly.
  • Workload clusters: Use the Web Console through the two-step RPCH review flow or use ACP CLI after the target Distribution Version becomes available for the workload cluster.