#Release Notes

Review release notes with the Kubernetes Support Matrix, Version and Lifecycle, and feature-specific documentation to understand release changes and exact support boundaries.

#4.5.0

#Deprecations and Removals

• Alauda Build of Prometheus Operator removed — The Alauda Build of Prometheus Operator is no longer shipped in OperatorHub starting in 4.5. On a cluster upgraded from 4.4, an existing installation keeps running but receives no further upgrades. Use the Prometheus Operator provided by ACP Basic Monitoring instead.

#Plugin Name Changes

The following plugins have new names in 4.5. The Customer Portal shows the new name for every version of a plugin, including versions published before 4.5. A plugin package built before the rename still carries its former name, so after you upload such a package to , the platform shows the former name. Search for the new name when you download a plugin. Package names, such as etcd-sync, do not change.

#4.3.0

#Release Baseline

4.3 adds Kubernetes 1.34 support for platform-managed cluster creation and changes the upgrade prerequisite model so workload clusters can remain within the documented compatible-version range before the global cluster upgrade.

For 4.3, the compatible workload-cluster versions are 1.34, 1.33, 1.32, and 1.31. This compatible-version requirement determines whether the global cluster can be upgraded and is separate from the third-party cluster accepted onboarding range.

For more information, see Kubernetes Support Matrix.

#Features And Enhancements

#Kubernetes 1.34 Support

4.3 supports Kubernetes 1.34 for platform-managed cluster creation.

For upgrades to 4.3, workload clusters must remain within the compatible versions 1.34, 1.33, 1.32, and 1.31.

#CVO-Based Cluster Upgrade Workflow

4.3 introduces a Cluster Version Operator (CVO)-based upgrade workflow for both global and workload clusters.

Key capabilities include:

• Preparing upgrade artifacts and the upgrade controller with bash upgrade.sh.
• Running preflight checks before execution.
• Requesting upgrades from the Web Console or by updating ClusterVersionShadow.spec.desiredUpdate.
• Inspecting conditions, preflight results, stages, and history from cvsh.status.

The CLI also introduces upgrade-oriented administrator commands such as ac adm upgrade, ac adm upgrade status, --to-latest, --to, and --allow-explicit-upgrade for requesting and troubleshooting workload cluster upgrades from the current context.

For operational guidance, see Upgrade.

#Standalone Cluster Plugin Upgrade

4.3 adds standalone upgrade support for Cluster Plugins that use the Aligned or Agnostic lifecycle.

The Cluster Plugins page shows the plugin lifecycle, and eligible plugins can be upgraded independently from the list page or details page. Core plugins continue to follow cluster upgrades.

For lifecycle details, see Core and Extensions and Cluster Plugin.

#Alauda OS-Based Global Clusters

4.3 allows administrators to create the global cluster with Alauda OS-based immutable infrastructure in supported provider scenarios. This extends the immutable operating model from workload clusters to platform installation scenarios.

For more information, see Create a Cluster on Alauda OS.

#Immutable Infrastructure Provider Updates

4.3 expands Immutable Infrastructure coverage during the 4.3 cycle. Provider-specific Immutable Infrastructure guidance covers provider overview, installation, cluster creation, node management, cluster upgrades, and provider APIs.

For more information, see Create a Cluster on Alauda OS.

#New Web Console Preview Entry

Core provides the top-navigation anchor required by the next-generation Web Console experience. When the Web Console Base plugin is installed on the global cluster, users in the Container Platform and Administrator views can open the new console through a Preview Next-Gen Console entry in a separate browser tab.

The experience is designed for gradual migration and works with the Web Console Base plugin on the global cluster and the Web Console Collector plugin on workload clusters.

#Containerd 2.0 Baseline

4.3 upgrades the platform runtime baseline to containerd 2.0. Review runtime-dependent operational procedures before upgrading environments that rely on customized containerd configuration.

For runtime and architecture boundaries, see Version and Lifecycle.

#Expanded Third-Party Cluster Accepted Onboarding Range

For third-party clusters, 4.3 accepts Kubernetes versions in the range >=1.19.0 <1.35.0.

This range is separate from the compatible Kubernetes versions used to determine whether the global cluster can be upgraded. It is an onboarding gate and does not mean every Kubernetes version, provider, operation, capability, or Extension in the range has complete product validation.

Product validation for the default Extend baseline covers these capability areas:

• Installing and using Operators.
• Installing and using Cluster Plugins.
• ClickHouse-based logging.
• VictoriaMetrics-based monitoring.

This does not mean that all specific Operators or Cluster Plugins are covered by product validation.

For more information, see Kubernetes Support Matrix, Cluster Management Models, and Import Clusters.

#Fixed Issues

No fixed issues are currently published for this release.

#Known Issues

No known issues are currently published for this release.