Alauda Container Platform

Overview

Start here to choose whether to create a platform-managed cluster, evaluate Hosted Control Plane, or onboard an existing Kubernetes environment. For the platform-level relationship between cluster responsibility, control-plane topology, and onboarding boundaries, see Cluster Management Models.

TOC

Choose A Cluster PathPlatform-Managed Cluster CreationInstaller-Provisioned InfrastructureUser-Provisioned InfrastructureHosted Control PlaneThird-Party Cluster OnboardingVersion Compatibility4.3 And Later4.2 And Earlier

Choose A Cluster Path

If you need toStart withKey boundary
Let the platform provision machines and manage Immutable OS for supported providers.About Immutable InfrastructurePlatform-owned lifecycle applies only within the supported provider and workflow scope.
Create a cluster on machines that you prepare and maintain.Creating an On-Premise ClusterThe platform manages Kubernetes after node preparation; node OS lifecycle remains user-owned.
Evaluate HCP for a non-production 4.3 scenario.About Hosted Control PlaneHCP is Technology Preview in 4.3 and is not production-supported.
Onboard an existing Kubernetes environment.Third-Party Cluster OnboardingThe external owner, distribution, or provider usually owns Kubernetes, node, and infrastructure lifecycle.
Choose between direct platform access and reverse-connect onboarding.Import Third-Party Clusters and Register ClusterImport and register are onboarding methods, not separate day-2 capability models.

Platform-Managed Cluster Creation

For clusters that creates and lifecycle-manages, choose the creation path by infrastructure responsibility.

Infrastructure responsibilityUse whenContinue with
Installer-Provisioned Infrastructure (IPI)The platform should provision machines and manage node operating systems through Immutable OS for a supported provider integration.About Immutable Infrastructure
User-Provisioned Infrastructure (UPI)You prepare physical or virtual machines, and the platform installs and manages Kubernetes on those nodes.Creating an On-Premise Cluster

Installer-Provisioned Infrastructure

In Installer-Provisioned Infrastructure (IPI), the platform provisions machines and manages node operating systems through Immutable OS. This model is used when the platform owns the supported cluster provisioning, scaling, and upgrade lifecycle for the selected provider integration.

Currently, the platform supports MicroOS for immutable node management. For immutable infrastructure concepts and provider-specific workflows, see About Immutable Infrastructure.

User-Provisioned Infrastructure

In User-Provisioned Infrastructure, users prepare physical or virtual machines before cluster creation. The platform installs and manages Kubernetes on those nodes, while node operating system management, including provisioning, patching, and replacement, remains under the user's control.

This model is suitable when organizations already have established infrastructure or operating system management procedures. For the cluster creation workflow, see Creating an On-Premise Cluster.

To create and manage User-Provisioned Infrastructure clusters through APIs, see Immutable Infrastructure API Reference and go to Provider APIs > User-Provisioned Infrastructure Provider APIs.

Hosted Control Plane

Hosted Control Plane is a control-plane topology. Each hosted cluster has its own control plane, and multiple hosted control planes run as workloads on a management cluster.

In , HCP is implemented through Kamaji (TenantControlPlane). In 4.3, HCP is Technology Preview, is not production-supported, supports disconnected environments, and defaults to IPI only. For evaluation details, see About Hosted Control Plane.

Third-Party Cluster Onboarding

Third-party clusters are existing Kubernetes environments provided outside . They can include standard Kubernetes environments, external Kubernetes distributions, or public cloud Kubernetes services. can provide centralized governance and operations within documented prerequisites and caveats, but onboarding does not make the owner of the external cluster's Kubernetes lifecycle, node lifecycle, or provider infrastructure lifecycle.

Third-party clusters are onboarded through import or register workflows:

Onboarding methodConnection modelUse when
Import clusterThe global cluster connects to the target cluster API server with supplied address, CA, and credentials.The platform can reach the target cluster API server and the operator can provide the required cluster information.
Register clusterA reverse proxy service in the target cluster initiates registration and establishes a tunnel to the platform.The target cluster should initiate the connection, or direct platform access to the target API server is restricted.

Provider-specific caveats can apply to certificates, audit data, control-plane metrics, ingress, storage, node operations, connectivity, and Extension compatibility. Use the import and register workflow pages for detailed prerequisites.

For onboarding workflows, see Third-Party Cluster Onboarding, Import Third-Party Clusters, and Register Cluster.

Version Compatibility

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

4.3 And Later

  • 4.3 adds support for Kubernetes 1.34 for platform-managed cluster scenarios.
  • For upgrades to 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, 4.3 accepts Kubernetes versions in the range >=1.19.0 <1.35.0 for onboarding. Clusters outside that range are blocked from onboarding.
  • The accepted onboarding range is separate from the compatible Kubernetes versions used to determine whether the global cluster can be upgraded.
  • The accepted onboarding range does not mean that every Kubernetes version, provider, operation, capability, or Extension in the range has complete product validation.
  • Product validation for the default Extend baseline covers installing and using Operators, installing and using Cluster Plugins, ClickHouse-based logging, and VictoriaMetrics-based monitoring. This does not mean that all specific Operators or Cluster Plugins are covered by product validation.
  • For 4.3 and later, workload clusters no longer need to be on the single latest compatible Kubernetes minor release before the global cluster upgrade.

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.