You can deploy OKD clusters by using two different control plane configurations: standalone or hosted control planes. The standalone configuration uses dedicated virtual machines or physical machines to host the control plane. With hosted control planes for OKD, you create control planes as pods on a management cluster without the need for dedicated virtual or physical machines for each control plane.
Hosted control planes is available by using a supported version of multicluster engine for Kubernetes Operator on the following platforms:
Bare metal by using the Agent provider
Non-bare-metal Agent machines, as a Technology Preview feature
OKD Virtualization
Amazon Web Services (AWS)
IBM Z
IBM Power
The hosted control planes feature is enabled by default.
OKD is often deployed in a coupled, or standalone, model, where a cluster consists of a control plane and a data plane. The control plane includes an API endpoint, a storage endpoint, a workload scheduler, and an actuator that ensures state. The data plane includes compute, storage, and networking where workloads and applications run.
The standalone control plane is hosted by a dedicated group of nodes, which can be physical or virtual, with a minimum number to ensure quorum. The network stack is shared. Administrator access to a cluster offers visibility into the cluster’s control plane, machine management APIs, and other components that contribute to the state of a cluster.
Although the standalone model works well, some situations require an architecture where the control plane and data plane are decoupled. In those cases, the data plane is on a separate network domain with a dedicated physical hosting environment. The control plane is hosted by using high-level primitives such as deployments and stateful sets that are native to Kubernetes. The control plane is treated as any other workload.
With hosted control planes, you can pave the way for a true hybrid-cloud approach and enjoy several other benefits.
The security boundaries between management and workloads are stronger because the control plane is decoupled and hosted on a dedicated hosting service cluster. As a result, you are less likely to leak credentials for clusters to other users. Because infrastructure secret account management is also decoupled, cluster infrastructure administrators cannot accidentally delete control plane infrastructure.
With hosted control planes, you can run many control planes on fewer nodes. As a result, clusters are more affordable.
Because the control planes consist of pods that are launched on OKD, control planes start quickly. The same principles apply to control planes and workloads, such as monitoring, logging, and auto-scaling.
From an infrastructure perspective, you can push registries, HAProxy, cluster monitoring, storage nodes, and other infrastructure components to the tenant’s cloud provider account, isolating usage to the tenant.
From an operational perspective, multicluster management is more centralized, which results in fewer external factors that affect the cluster status and consistency. Site reliability engineers have a central place to debug issues and navigate to the cluster data plane, which can lead to shorter Time to Resolution (TTR) and greater productivity.
You can configure hosted control planes by using the multicluster engine for Kubernetes Operator. The multicluster engine is an integral part of Red Hat Advanced Cluster Management (RHACM) and is enabled by default with RHACM. The multicluster engine Operator cluster lifecycle defines the process of creating, importing, managing, and destroying Kubernetes clusters across various infrastructure cloud providers, private clouds, and on-premises data centers.
The multicluster engine Operator is the cluster lifecycle Operator that provides cluster management capabilities for OKD and RHACM hub clusters. The multicluster engine Operator enhances cluster fleet management and supports OKD cluster lifecycle management across clouds and data centers.
You can use the multicluster engine Operator with OKD as a standalone cluster manager or as part of a RHACM hub cluster.
A management cluster is also known as the hosting cluster. |
You can deploy OKD clusters by using two different control plane configurations: standalone or hosted control planes. The standalone configuration uses dedicated virtual machines or physical machines to host the control plane. With hosted control planes for OKD, you create control planes as pods on a management cluster without the need for dedicated virtual or physical machines for each control plane.
If you want to bring hosted clusters to a Red Hat Advanced Cluster Management (RHACM) hub cluster to manage them with RHACM management components, see the instructions in the Red Hat Advanced Cluster Management official documentation.
The hosted control planes feature includes the following components, which might require independent versioning and support levels:
Management cluster
HyperShift Operator
Hosted control planes (hcp
) command-line interface (CLI)
hypershift.openshift.io
API
Control Plane Operator
In management clusters for production use, you need multicluster engine for Kubernetes Operator, which is available through OperatorHub. The multicluster engine Operator bundles a supported build of the HyperShift Operator. For your management clusters to remain supported, you must use the version of OKD that multicluster engine Operator runs on. In general, a new release of multicluster engine Operator runs on the following versions of OKD:
The latest General Availability version of OKD
Two versions before the latest General Availability version of OKD
The full list of OKD versions that you can install through the HyperShift Operator on a management cluster depends on the version of your HyperShift Operator. However, the list always includes at least the same OKD version as the management cluster and two previous minor versions relative to the management cluster. For example, if the management cluster is running 4.17 and a supported version of multicluster engine Operator, the HyperShift Operator can install 4.17, 4.16, 4.15, and 4.14 hosted clusters.
With each major, minor, or patch version release of OKD, two components of hosted control planes are released:
The HyperShift Operator
The hcp
command-line interface (CLI)
The HyperShift Operator manages the lifecycle of hosted clusters that are represented by the HostedCluster
API resources. The HyperShift Operator is released with each OKD release. The HyperShift Operator creates the supported-versions
config map in the hypershift
namespace. The config map contains the supported hosted cluster versions.
You can host different versions of control planes on the same management cluster.
supported-versions
config map object apiVersion: v1
data:
supported-versions: '{"versions":["4.17"]}'
kind: ConfigMap
metadata:
labels:
hypershift.openshift.io/supported-versions: "true"
name: supported-versions
namespace: hypershift
You can use the hcp
CLI to create hosted clusters. You can download the CLI from multicluster engine Operator. When you run the hcp version
command, the output shows the latest OKD that the CLI supports against your kubeconfig
file.
You can use the hypershift.openshift.io
API resources, such as, HostedCluster
and NodePool
, to create and manage OKD clusters at scale. A HostedCluster
resource contains the control plane and common data plane configuration. When you create a HostedCluster
resource, you have a fully functional control plane with no attached nodes. A NodePool
resource is a scalable set of worker nodes that is attached to a HostedCluster
resource.
The API version policy generally aligns with the policy for Kubernetes API versioning.
Updates for hosted control planes involve updating the hosted cluster and the node pools. For more information, see "Updates for hosted control planes".
When you use hosted control planes for OKD, it is important to understand its key concepts and the personas that are involved.
An OKD cluster with its control plane and API endpoint hosted on a management cluster. The hosted cluster includes the control plane and its corresponding data plane.
Network, compute, and storage resources that exist in the tenant or end-user cloud account.
An OKD control plane that runs on the management cluster, which is exposed by the API endpoint of a hosted cluster. The components of a control plane include etcd, the Kubernetes API server, the Kubernetes controller manager, and a VPN.
See management cluster.
A cluster that the hub cluster manages. This term is specific to the cluster lifecycle that the multicluster engine for Kubernetes Operator manages in Red Hat Advanced Cluster Management. A managed cluster is not the same thing as a management cluster. For more information, see Managed cluster.
An OKD cluster where the HyperShift Operator is deployed and where the control planes for hosted clusters are hosted. The management cluster is synonymous with the hosting cluster.
Network, compute, and storage resources of the management cluster.
A resource that contains the compute nodes. The control plane contains node pools. The compute nodes run applications and workloads.
Users who assume this role are the equivalent of administrators in standalone OKD. This user has the cluster-admin
role in the provisioned cluster, but might not have power over when or how the cluster is updated or configured. This user might have read-only access to see some configuration projected into the cluster.
Users who assume this role are the equivalent of developers in standalone OKD. This user does not have a view into OperatorHub or machines.
Users who assume this role can request control planes and worker nodes, drive updates, or modify externalized configurations. Typically, this user does not manage or access cloud credentials or infrastructure encryption keys. The cluster service consumer persona can request hosted clusters and interact with node pools. Users who assume this role have RBAC to create, read, update, or delete hosted clusters and node pools within a logical boundary.
Users who assume this role typically have the cluster-admin
role on the management cluster and have RBAC to monitor and own the availability of the HyperShift Operator as well as the control planes for the tenant’s hosted clusters. The cluster service provider persona is responsible for several activities, including the following examples:
Owning service-level objects for control plane availability, uptime, and stability
Configuring the cloud account for the management cluster to host control planes
Configuring the user-provisioned infrastructure, which includes the host awareness of available compute resources