Alauda Container Platform
  • English

    • Cluster Management Models

    Use the cluster management model to separate four planning decisions:

    1. Infrastructure responsibility.
    2. Node operating system.
    3. Control-plane topology.
    4. Kubernetes ownership and onboarding.

    Each cluster path combines choices from these axes. Installer-Provisioned Infrastructure (IPI), User-Provisioned Infrastructure (UPI), Hosted Control Plane (HCP), and the current UI label Managed Cluster are not one flat list of mutually exclusive cluster types.

    TOC

    Infrastructure ResponsibilityNode Operating SystemControl-Plane TopologyKubernetes Ownership And OnboardingThird-Party Cluster Capability BoundariesProvider And Workflow Caveats

    Infrastructure Responsibility

    Infrastructure responsibility explains who provides and manages machines, node operating systems, and Kubernetes lifecycle.

    ModelMachines and nodesNode operating systemKubernetes lifecycleMain docs
    Installer-Provisioned Infrastructure (IPI)Provisioned through the platform and its infrastructure provider integration.Managed by the platform with Alauda OS.Managed by the platform, including supported provisioning, scaling, and upgrade flows.Create on Alauda OS
    User-Provisioned Infrastructure (UPI)Prepared by the user as physical or virtual machines.Managed by the user.Installed and managed by the platform after the user prepares nodes.Create on Non-Alauda OS

    IPI and UPI describe responsibility boundaries. They do not by themselves describe whether the control plane is hosted or dedicated, and they do not describe whether a third-party cluster has been imported or registered.

    Existing third-party Kubernetes environments are covered under Kubernetes Ownership And Onboarding, because their Kubernetes distribution and lifecycle usually exist outside .

    Node Operating System

    The node operating system of a lifecycle-managed cluster is either Alauda OS or a non-Alauda OS:

    Node operating systemWhat it isHow nodes are preparedHow Kubernetes is upgraded
    Alauda OSAn immutable, image-based node operating system provided by .Provisioned through an infrastructure provider for Huawei DCS, Huawei Cloud Stack, VMware vSphere, or Bare Metal. On Bare Metal, the user provides the hosts, and the nodes run Alauda OS.By replacing nodes from a new Alauda OS image.
    Non-Alauda OSAn operating system from the supported OS list, installed on machines that the user prepares.Prepared by the user. The platform installs Kubernetes on the prepared nodes.In place on the existing nodes.

    Install, Workload Clusters, Upgrade, and Configure > Nodes are organized by node operating system. Choose the node operating system first, then follow the matching path:

    AreaAlauda OSNon-Alauda OS
    Install the global clusterInstall on Alauda OSInstall on Non-Alauda OS
    Create workload clustersCreate on Alauda OSCreate on Non-Alauda OS
    UpgradeUpgrade the Distribution Version, then upgrade Kubernetes by replacing nodes. See Upgrade Overview.Upgrade the Distribution Version, which also upgrades Kubernetes. See Upgrade Overview.
    Manage nodesConfigure > Nodes > Alauda OSConfigure > Nodes > Non-Alauda OS

    Control-Plane Topology

    Control-plane topology explains where Kubernetes control plane components run.

    TopologyMeaningSupport boundary
    Control plane nodes of its ownControl plane components run on control plane nodes of the cluster itself.This is the normal topology for current production guidance.
    Hosted Control PlaneEach hosted cluster has its own control plane, but the control plane runs as workloads on a management cluster. In , HCP is implemented through Kamaji (TenantControlPlane).Not a Core default capability.

    HCP is an architecture for the control plane. It is not a Core default capability and is not a peer concept to IPI or UPI.

    Kubernetes Ownership And Onboarding

    Kubernetes ownership explains whether owns the Kubernetes lifecycle or whether the Kubernetes environment already exists outside .

    ModelHow it enters the platformLifecycle boundary
    lifecycle-managed workload clusterCreated through supported cluster workflows. manages the supported Kubernetes lifecycle for the selected model.
    Third-party clusterOnboarded through import or register workflows. provides central governance and operations within documented prerequisites and caveats. The external cluster owner, distribution, or provider usually owns Kubernetes lifecycle, node lifecycle, and provider infrastructure lifecycle.

    Managed Cluster is the current UI and navigation label for third-party cluster onboarding and management areas. For product-model planning, use Third-party cluster.

    Import cluster and Register cluster are onboarding methods for third-party clusters:

    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.

    After onboarding, expected day-2 management is treated as the same at the Overview level. Provider and workflow-specific caveats still apply.

    Third-Party Cluster Capability Boundaries

    can provide these entry capabilities for third-party clusters when prerequisites are met:

    • Resource visibility and centralized governance.
    • Project and namespace association.
    • Application operations.
    • Operator and Cluster Plugin installation, subject to Extension compatibility.
    • Observability integration, subject to installed components, network paths, credentials, and provider caveats.

    Third-party cluster onboarding does not mean that manages every Kubernetes version, provider operation, node operation, certificate, control-plane metric, audit source, ingress path, storage class, or Extension image on every third-party cluster.

    Use the product-supported onboarding range in the Kubernetes Support Matrix to confirm Kubernetes-version eligibility. Check provider prerequisites and exact Extension compatibility separately.

    For the exact matrix and upgrade relationship, see Kubernetes Support Matrix and Version and Lifecycle.

    Provider And Workflow Caveats

    Use the following caveat categories to decide which provider or workflow documentation to check for provider-specific details.

    Caveat categoryWhat to checkContinue with
    Kubernetes lifecycleWhether Kubernetes installation or upgrade is managed by or by the external owner.Clusters Overview
    Node lifecycleWhether adding, deleting, or scaling nodes is supported from the platform UI for the selected model.Node Management
    ConnectivityWhether the global cluster and target cluster can reach the required endpoints and whether a platform URL annotation is needed.Network Configuration for Imported Clusters
    CertificatesWhich certificates are visible or rotated by the platform for the selected workflow.Provider or onboarding workflow docs under Import Third-Party Clusters
    Audit and metricsWhether audit data and control-plane metrics are available from the target environment.Audit and provider workflow docs
    Ingress and storageWhether post-import initialization is required for ingress, load balancing, or storage classes.Public Cloud Cluster Initialization
    Extension compatibilityWhether the exact Operator or Cluster Plugin version supports the target version and cluster model.Core and Extensions

    If you need to choose what to read next, see Learn More.