Alauda Container Platform

Kubernetes Support Matrix

Use the Kubernetes support matrix to confirm Kubernetes version relationships for releases and to distinguish cluster creation, upgrade compatibility, and third-party cluster onboarding boundaries.

For the conceptual lifecycle guidance, see Version and Lifecycle.

TOC

How To Read This PageVersion Support Matrix4.3 NotesThird-Party Cluster Accepted Onboarding RangeExtend BaselineUpgrade Requirements

How To Read This Page

TermMeaning
Supported for cluster creationThe Kubernetes version that can be used when creates a new platform-managed cluster for that release.
Compatible VersionsThe Kubernetes versions that workload clusters can run before the global cluster is upgraded to that release.
Third-party cluster accepted onboarding rangeThe Kubernetes version range accepted for onboarding third-party clusters. This is an onboarding gate, not proof of complete validation for every version, provider, capability, operation, or Extension.

Version Support Matrix

The following table shows the Kubernetes version support for each release.

INFO

The table lists minor versions and does not distinguish between patch versions. Patch versions only include bug fixes and security updates, so the Kubernetes minor versions remain consistent across all patch versions within the same minor release.

Starting from 4.1, each release supports only one Kubernetes version for cluster creation. This keeps new cluster creation consistent and simplifies upgrade planning.

VersionSupported for cluster creationCompatible Versions
4.31.341.34, 1.33, 1.32, 1.31
4.21.331.33, 1.32, 1.31, 1.30
4.11.321.32, 1.31, 1.30, 1.29
4.01.31, 1.30, 1.29, 1.281.31, 1.30, 1.29, 1.28

4.3 Notes

  • 4.3 supports Kubernetes 1.34 for platform-managed cluster creation.
  • Before upgrading the global cluster to 4.3, workload clusters must remain within Kubernetes 1.34, 1.33, 1.32, and 1.31.
  • Environments upgrading from 4.0 to 4.3 can keep workload clusters on Kubernetes 1.31 through 1.34 while upgrading the global cluster, subject to the documented upgrade procedure.

For upgrade planning, see Upgrade Overview and Pre-Upgrade.

Third-Party Cluster Accepted Onboarding Range

For 4.3, third-party Kubernetes clusters are accepted for onboarding only in the range >=1.19.0 <1.35.0. Clusters outside that range are blocked from onboarding.

This range is separate from the Compatible Versions column. Compatible Versions determine whether workload clusters satisfy the prerequisite for upgrading the global cluster. The third-party onboarding range determines whether a third-party Kubernetes cluster can be onboarded.

This range also does not mean every Kubernetes version, provider, operation, capability, or Extension in the range has complete product validation.

When onboarding third-party clusters, also check:

  • Cluster family or provider prerequisites.
  • Connectivity between the global cluster and the target cluster.
  • Credentials and RBAC scope.
  • Required platform components.
  • Provider and workflow caveats.
  • Extension compatibility for each exact Operator or Cluster Plugin version.

For model boundaries, see Cluster Management Models.

Extend Baseline

For 4.3, 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 baseline does not mean every specific Operator or Cluster Plugin is validated for every cluster model or every third-party cluster scenario.

For a specific Operator or Cluster Plugin version, use the Customer Portal ACP compatible versions field and the corresponding Extension documentation. For more information, see Core and Extensions.

Upgrade Requirements

For 4.3 and later, workload clusters only need to remain within the documented compatible version range before upgrading the global cluster.

In 4.2 and earlier, all workload clusters must be upgraded to the latest Kubernetes version in the compatible versions list before upgrading the global cluster.

For upgrade procedures, see Upgrade.