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 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 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.