#Architecture

uses a hub-and-spoke architecture. The global cluster provides the central management plane, and workload clusters or third-party clusters provide Kubernetes environments where applications and cluster-local components run.

Use the diagram as a high-level view of this model. The architecture details below clarify 4.3 boundaries that are not visible in the diagram.

For platform-wide terms, see Glossary. For the conceptual platform model, see Platform Model.

#Hub-And-Spoke Model

The hub-and-spoke model describes the relationship between the global cluster and the Kubernetes environments that it manages. For control-plane topology, including Hosted Control Plane, see Cluster Management Models.

The global cluster is the platform hub. Workload clusters and third-party clusters are spokes. A project can span associated clusters, and namespaces provide Kubernetes resource isolation inside those clusters.

#Access And Request Path

Users and automation usually access the platform through the Platform Access Address, web console, platform APIs, Kubernetes APIs, or CLI tools.

At a high level:

1. A user, CLI, automation tool, or browser connects to the Platform Access Address.
2. A load balancer, VIP, DNS record, or ingress path routes traffic to platform entry components.
3. Platform API services evaluate authentication and authorization.
4. Requests are handled by the global cluster or forwarded to target clusters through the documented cluster access path.
5. Kubernetes API requests to target clusters are evaluated against the user's effective RBAC permissions.

For API usage, see API Introduction. For CLI tools, see CLI Tools. For cluster KubeConfig access, see Access a Cluster with KubeConfig.

#Management Path

The global cluster coordinates platform management operations:

• Cluster creation and lifecycle operations for supported lifecycle-managed cluster models.
• Third-party cluster onboarding through import or register workflows.
• Project, namespace, user, role, and quota governance.
• Operator and Cluster Plugin discovery, package upload, installation, and upgrade entry points.
• Central views for observability, audit, inventory, and operations when the required components are installed.

For third-party clusters, the management path depends on version range, connectivity, credentials, provider prerequisites, installed components, and Extension compatibility. Onboarding a third-party cluster does not make the owner of that cluster's Kubernetes lifecycle, node lifecycle, or provider infrastructure lifecycle.

For model boundaries, see Cluster Management Models.

#State And Data Domains

Different data domains have different protection and recovery paths:

Global Cluster Disaster Recovery protects only the global control-plane DR scenario documented in Availability and Recovery. It is not full platform data DR and is not application data DR.

#Core And Extension Boundary

Core provides the platform management plane and the frameworks used to manage clusters, projects, users, APIs, and Extensions.

Additional capabilities can require separately installed Extensions, such as Operators and Cluster Plugins, or separate products. Examples include specific observability backends, registry plugins, API filtering, compliance features, container security, data services, GitOps, logging, Immutable Infrastructure, and Hosted Control Plane.

Before planning those capabilities as part of an architecture, check the corresponding documentation for installation, upgrade, compatibility, and limitations.

For details, see Core and Extensions.

#Availability And Recovery Model

Availability is planned by topology:

• Single Node is for testing or proof-of-concept only.
• Single Cluster can support production use when it fits the business scenario and resources are planned for both platform components and workloads.
• Multi-Cluster separates the global cluster management plane from workload clusters and should avoid non-platform business workloads on the global cluster.
• Three control plane nodes are the HA baseline. Five control plane nodes are scale and reliability guidance, not a universal production gate.

For detailed planning, sizing, Global DR, and backup/restore entry points, see Availability and Recovery.

#Continue Reading

• Introduction
• Platform Model
• Cluster Management Models
• Core and Extensions
• Learn More