#Cluster Management Models

Use the cluster management model to separate three planning decisions:

1. Infrastructure responsibility.
2. Control-plane topology.
3. 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.

#Infrastructure Responsibility

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

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 .

#Control-Plane Topology

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

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.

For more information, see About Hosted Control Plane.

#Kubernetes Ownership And Onboarding

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

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:

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.

For 4.3, third-party Kubernetes clusters are accepted for onboarding only in the range >=1.19.0 <1.35.0. Clusters outside that range are blocked from onboarding. Treat this range as an onboarding gate, not as a complete product validation matrix for every Kubernetes version, provider, operation, or Extension.

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.

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