#Clusters Overview

The platform supports multiple Kubernetes cluster management models depending on how the underlying infrastructure is provisioned and how the control plane is deployed.

#Platform-Provisioned Infrastructure

Description:

In this model, the platform provisions both the machines and the node operating systems. All nodes use an Immutable OS, which ensures a consistent, declarative, and easily recoverable infrastructure state. This model provides full automation across the entire cluster lifecycle — from provisioning to scaling and upgrades.

Examples of Immutable OS:

Common Immutable OS examples include Fedora CoreOS, Flatcar Linux, and openSUSE MicroOS. Currently, the platform supports MicroOS for immutable node management.

Responsibilities:

#User-Provisioned Infrastructure

Description:

In this model, the user provides pre-provisioned physical or virtual machines. The platform installs and manages Kubernetes on these nodes, while node OS management — including provisioning, patching, or replacement — remains under the user's control.

This model is designed for organizations that already have established procedures or automation tools for managing their infrastructure or operating systems.

Responsibilities:

#Hosted Control Plane (HCP)

Description:

Hosted Control Plane (HCP) is a deployment model in which multiple clusters share a single control plane hosted in a dedicated management cluster. Only the control plane components are shared — the worker nodes are still provisioned following one of the two infrastructure models above (either platform-provisioned or user-provisioned).

Characteristics:

• Reduces control plane resource consumption.
• Supports mixed models: worker nodes can be immutable or user-provisioned.
• Ideal for large bare-metal or resource-constrained environments.

#Connected Clusters

The platform also supports connecting and managing existing Kubernetes clusters, whether they are public cloud clusters or CNCF-compliant Kubernetes distributions.

#Public Cloud Kubernetes

• Connects to managed Kubernetes services such as EKS, AKS, and GKE through cloud-specific providers (e.g., Alauda Container Platform EKS Provider).
• Cloud credentials can be securely stored in the platform.
• Enables creation and management of public cloud clusters directly from the platform.

#CNCF-Compliant Kubernetes

• Connects any existing Kubernetes cluster conforming to CNCF standards.
• Supports unified visibility, policy control, and monitoring across environments.
• Refer to the Kubernetes Support Matrix.

#Tunnel-Based Connectivity

• When the Global cluster cannot directly access a Workload cluster, a Tunnel Server (global side) and Tunnel Agent (workload side) establish secure communication.
• Suitable for disconnected or restricted network environments.

#Choosing the Right Model

#Version Compatibility

When importing or connecting existing clusters, validate the Kubernetes version against the current ACP compatibility policy.

#ACP 4.3 and Later

• ACP 4.3 adds support for Kubernetes 1.34 for platform-managed cluster scenarios.
• For upgrades to ACP 4.3, workload clusters must remain within the compatible version range 1.34, 1.33, 1.32, and 1.31 before the global cluster upgrade.
• For third-party clusters, ACP 4.3 accepts Kubernetes versions in the range >=1.19.0 <1.35.0 for management.
• Product documentation continues to list only the Kubernetes versions that have passed product validation for third-party cluster support and the default Extend baseline.
• Product validation for the Extend baseline covers the following 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 specific Operators or Cluster Plugins outside this baseline, refer to the relevant product documentation or contact technical support.
• For ACP 4.3 and later, workload clusters no longer need to be on the single latest compatible Kubernetes minor release before the global cluster upgrade.

#ACP 4.2 and Earlier

• Upgrade workload clusters to the latest documented compatible Kubernetes version before upgrading the global cluster.
• Use the Kubernetes Support Matrix as the main reference for the documented version mapping.