#Platform Model

uses a hub-and-spoke model. The global cluster provides the central platform management plane, while workload clusters and third-party clusters run or expose Kubernetes workloads under platform governance.

Use the platform model to understand the main platform objects and how they relate to each other.

#The global Cluster

The global cluster is deployed during Core installation. It provides the central management plane for web console access, platform APIs, users and roles, project governance, cluster management, Extension management, and platform-wide coordination.

The global cluster is not just another workload cluster in the management model. In Multi-Cluster deployments, avoid running non-platform business workloads on the global cluster. In Single Cluster deployments, the global cluster also carries business workloads, so resource planning must include both platform components and application workloads.

For installation planning, see Install Overview and Plan.

#Workload Clusters

A workload cluster is a Kubernetes cluster that runs application workloads and is managed from the global cluster. Workload clusters can be created and lifecycle-managed by when the selected infrastructure model supports that lifecycle.

Workload clusters inherit platform governance and can be associated with projects and namespaces. They can also receive Extensions, observability components, networking components, storage integrations, and application workloads according to the selected cluster model and installed capabilities.

For cluster creation tasks, see Clusters Overview and Creating an On-Premise Cluster.

#Third-Party Clusters

A third-party cluster is a Kubernetes environment whose Kubernetes distribution and lifecycle are provided or managed outside . This includes existing Kubernetes environments, external Kubernetes distributions, and public cloud Kubernetes services.

can onboard third-party clusters for centralized governance, resource visibility, application operations, Extension installation, and observability integration when the required version range, connectivity, credentials, installed components, provider prerequisites, and Extension compatibility are satisfied.

For third-party clusters, does not own the complete Kubernetes lifecycle, node lifecycle, or provider infrastructure lifecycle unless a specific provider or plugin document states that capability. Kubernetes installation, Kubernetes upgrades, node scaling, and infrastructure operations usually remain the responsibility of the cluster owner, external distribution, or cloud provider.

Third-party cluster is the product-model term for these onboarded environments. Managed Cluster is the current UI and navigation label for the interface that manages them.

For onboarding workflows, see Managed Clusters Overview, Import Clusters, and Register Cluster.

#Hosted Control Plane

Hosted Control Plane (HCP) is a control-plane topology, not a cluster model parallel to Installer-Provisioned Infrastructure (IPI) or User-Provisioned Infrastructure (UPI). In HCP, each hosted cluster has its own hosted control plane, and multiple hosted control planes run as workloads on a management cluster. In , HCP is implemented through Kamaji (TenantControlPlane).

For 4.3, HCP is Technology Preview, is not production-supported, supports disconnected environments, and currently defaults to IPI only. Do not use HCP documentation as production topology, sizing, HA, or backup/restore guidance for 4.3.

For HCP scope and tasks, see About Hosted Control Plane.

#Projects And Namespaces

A project is a governance unit for tenants, teams, or business systems. It can span multiple associated clusters and provides a boundary for users, quotas, policies, and resource visibility.

A namespace is a Kubernetes resource isolation unit. In , a namespace can be created in or imported into a project so that project-level governance applies to the namespace and its workloads.

The relationship is:

For project and namespace concepts, see Project Introduction and Namespace Management.

#What Happens Where

For the high-level architecture, see Architecture. For model comparisons and responsibility boundaries, see Cluster Management Models.