Alauda Container Platform

Version and Lifecycle

Use this guidance to plan version compatibility, Kubernetes support, third-party cluster onboarding, runtime and OS boundaries, and Extension lifecycle checks.

Use Kubernetes Support Matrix for the exact Kubernetes version table.

TOC

Product And Kubernetes VersionsThird-Party Cluster Onboarding RangeRuntime, OS, And CPU ArchitectureExtension LifecycleFeature MaturityUpgrade Reading Path

Product And Kubernetes Versions

The Kubernetes support matrix separates three decisions: which Kubernetes targets can be used for platform-managed cluster creation, which workload-cluster versions satisfy the global cluster upgrade prerequisite, and which Kubernetes minors are product-supported for third-party cluster onboarding. Do not infer one range from another.

For 4.3 and later, workload clusters only need to remain within the documented Compatible Versions before a global cluster upgrade. In 4.2 and earlier, workload clusters must be upgraded to the latest Kubernetes version in the compatible list before upgrading the global cluster.

Exact Kubernetes builds and creation targets come from versions offered by the installed platform patch and release-specific artifacts, not from this lifecycle overview.

For the exact table, see Kubernetes Support Matrix.

Third-Party Cluster Onboarding Range

Use Product-Tested Scope for Third-Party Clusters for the current product-supported Kubernetes range, the ongoing validation policy, and the default validation scope.

The product-tested onboarding range is shared by 4.3 and later releases that provide third-party cluster onboarding. It is maintained independently from the release-specific creation and Compatible Versions rows, and the shared range is updated when product validation expands.

This range is separate from:

  • The Kubernetes version supported for platform-managed cluster creation.
  • The workload-cluster compatible versions used before upgrading the global cluster.
  • Support for every provider, capability, operation, or Extension.

The published Kubernetes range establishes version eligibility. Follow Third-Party Cluster Onboarding and the selected Import, Register, or provider-specific procedure for connectivity, credentials, and environment-specific preparation.

For cluster model boundaries, see Cluster Management Models.

Runtime, OS, And CPU Architecture

Read runtime, OS, CRI, and CPU architecture information by responsibility boundary.

EnvironmentHow to read support information
lifecycle-managed environmentsThe platform installs and manages containerd. The exact runtime build follows the installed patch and is not a stable minor-release documentation value. For immutable nodes, use the patch-specific OS Support Matrix.
HCP environmentsUse About Hosted Control Plane for the current maturity, runtime, operating system, connectivity, and production-use boundaries.
Third-party clustersNode OS, container runtime, CRI, and CPU architecture usually remain the responsibility of the external cluster owner, external distribution, or cloud provider.
Immutable InfrastructureUse the Immutable Infrastructure documentation for Alauda OS images provided by and provider-specific requirements.
ExtensionsUse the exact Extension documentation and Customer Portal compatibility metadata. Package availability for x86, ARM, or hybrid architectures is not a universal guarantee for every Extension image or provider scenario.

Do not infer complete Docker, CRI-O, Alauda OS, mixed-architecture workload cluster, provider architecture, or universal Extension image support unless an explicit support matrix, Extension document, provider document, or release guidance states that support.

For node prerequisites, see Node Preprocessing. For package architecture, see Download. For Immutable Infrastructure, see About Immutable Infrastructure.

Extension Lifecycle

Operators and Cluster Plugins use the Core, Aligned, and Agnostic lifecycle model.

LifecycleCompatibility and upgrade meaning
CoreFollows the Core release and cluster Distribution Version. Updated through cluster upgrade.
AlignedFollows the release stream but can be upgraded independently when a compatible version is published.
AgnosticReleased independently from and upgraded independently when a compatible version is published.

For a specific Operator or Cluster Plugin version, use the Customer Portal ACP compatible versions field as the compatibility authority. Release notes are useful for version changes. The Kubernetes support matrix is not the authority for one exact Extension version.

For details, see Core and Extensions.

Feature Maturity

When reading Overview, release notes, or component documentation, treat maturity labels as support boundaries:

LabelMeaning for readers
GAThe feature is generally available within the documented scope and prerequisites.
Technology PreviewThe feature is available for evaluation within the documented limits and should not be treated as production-supported unless product documentation explicitly says so.
DeprecatedThe feature remains available but is planned for removal or replacement. Plan migration according to release guidance.
RemovedThe feature is no longer available in the documented release.

For current HCP maturity and evaluation boundaries, see About Hosted Control Plane. Global Cluster Disaster Recovery is generally available only within the documented global control-plane DR scope in Availability and Recovery.

Upgrade Reading Path

Before upgrading:

  1. Read Kubernetes Support Matrix to confirm compatible workload-cluster versions.
  2. Read Upgrade Overview to understand the CVO-based upgrade model.
  3. Read Pre-Upgrade before upgrading the global cluster.
  4. Check Extension compatibility in the Customer Portal and the Extension documentation.
  5. Review Release Notes for version changes, behavior changes, technical preview status, deprecated features, and known issues.