Alauda Container Platform
  • English

    • Overview

    Start here to choose whether to create a platform-managed cluster 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 Behavior

    Choose A Cluster Path

    If you need toStart withKey boundary
    Create a cluster whose nodes run Alauda OS, provisioned through a supported infrastructure provider.Create on Alauda OSPlatform-owned lifecycle applies only within the supported provider and workflow scope.
    Create a cluster on machines that you prepare and maintain, running a supported non-Alauda OS.Create on Non-Alauda OSThe platform manages Kubernetes after node preparation; node OS lifecycle remains user-owned.
    Onboard an existing Kubernetes environment.Managed ClustersThe 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 the operating system of the nodes.

    Node operating systemUse whenContinue with
    Alauda OSThe platform should manage node operating systems through Alauda OS, with nodes provisioned through a supported infrastructure provider.Create on Alauda OS
    Non-Alauda OSYou prepare physical or virtual machines that run a supported operating system, and the platform installs and manages Kubernetes on those nodes.Create on Non-Alauda OS

    The creation path follows the node operating system rather than the infrastructure responsibility model described below. For example, on Bare Metal you supply the physical servers, but the nodes run Alauda OS, so Bare Metal clusters use the Alauda OS path.

    Installer-Provisioned Infrastructure

    In Installer-Provisioned Infrastructure (IPI), the platform provisions machines and manages node operating systems through Alauda 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 Alauda OS cluster concepts and provider-specific workflows, see Create on Alauda OS.

    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 Create on Non-Alauda OS.

    To create and manage User-Provisioned Infrastructure clusters through APIs, see 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).

    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

    • Before you upgrade the global cluster, every workload cluster must run a Kubernetes version within the Compatible Versions of the target release.
    • The third-party onboarding range is independent from the Compatible Versions used for this upgrade prerequisite.