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 CompatibilityUpgrade Prerequisite Behavior4.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 Hosted Control Plane (HCP).About Hosted Control PlaneCheck the HCP documentation for current maturity, operating system, connectivity, and production-use boundaries.
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 Alauda OS 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). For current support scope and 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

Use the Kubernetes Support Matrix to choose platform-managed cluster creation targets, verify workload-cluster upgrade prerequisites, and validate third-party cluster onboarding versions. These are separate ranges for separate decisions.

Upgrade Prerequisite Behavior

  • For 4.3 and later, workload clusters only need to remain within the Compatible Versions before the global cluster upgrade.
  • The third-party onboarding range is independent from the Compatible Versions used for this upgrade prerequisite.

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 numerical authority for the documented version mapping.