Introducing OpenShift on OpenShift with Hosted Control Planes

With the introduction of OpenShift Virtualization Engine (OVE), Red Hat now provides an OpenShift experience that is tailored for, and targeted at, virtualization-only administrators. For customers who are using virtual OpenShift deployed to other hypervisor platforms, they can move to OVE without needing to change the way their hosted clusters are subscribed.

Furthermore, with updates to the bare metal OpenShift Kuberntes Engine (OKE), OpenShift Container Platform (OCP), and OpenShift Platform Plus (OPP) offerings, virtual OpenShift clusters deployed to these bare metal clusters inherit subscriptions of the same product type from the bare metal cluster. For cusotmers with substantial virtual OpenShift deployments, this offers a cost efftive way to move their OpenShift footprint away from existing hypervisors while also simplifying the management paradigm and improving resource efficiency.

Distributed Clusters for Disaster Recovery: A single hosted control plane instance deployed to a management or hub cluster could have a number of node pools assigned to the cluster from remote managed locations in disparate data centers, helping to protect against the loss of a cluster in the event of an unplanned disaster or data center outage. Should the worker nodes in one data center become unavailable, the application pods that are non-responsive could be relaunched on additional worker nodes in the cluster that reside in a different location.

Ease of Cluster Administration: Service providers or groups acting in such a manner can provision entirely new cluster environments rapidly, without additional overhead. New clusters can be made available to end users in a matter of minutes, and taken down once they are no longer needed. Developers may even be able to request the provisioning of clusters on demand for testing of a specific application in an isolated environment. The physical separation of control planes and worker nodes also allows cluster administrators to update control planes individually or even without updating the worker nodes for a cluster in tandem.

Reduction of Physical Resources: A traditional OpenShift deployment requires a minimum of 3 control plane hosts and 2 data plane hosts in order to be deployed as a highly available and fault-tolerant platform. In an environment where a number of separate clusters are being deployed, it would be more cost-effective to be able to deploy only worker nodes for each new cluster instance and to have the control plane for each not be localized but hosted in a centralized data center.

Secure Multi-Tenancy: In OpenShift, workloads and their responsibilities are often segregated through projects and access to these projects is governed by user accounts and permissions. While this virtual separation of applications exists, they still share the same level of access to all physical system resources as any other application and or project. The use of hosted control planes to dedicate entirely managed OpenShift clusters, either virtual or physical to projects or end users, offers a cluster the ability to safely separate workloads completely and allows for a truer form of multi-tenancy than traditionally available in OpenShift.

Secure Network Segregation: Due to the natural decoupling of the infrastructure, hosted control planes allow for the control planes themselves to be a part of the network domain of the management cluster, while the worker nodes reside on a different physical network and are able to be a part of that network domain. This arrangement ensures that management traffic is separated from data plane traffic, and that applications deployed do not have access to the control plane through physical separation.

A hosted control planes cluster can be deployed to either bare metal nodes or virtual nodes provisioned with OpenShift Virtualization. In this lab we will be focused on deployments of virtual OpenShift clusters provided by OpenShift Virtualization.

A hosted control planes cluster saves on physical resources by reducing the number of nodes that need to be deployed to support the cluster. The hosted cluster control plane services are run in Pods, in a dedicated namespace, on the hosting cluster. This results in only worker nodes being provisioned for the hosted cluster.

The following graphic compares a hosted control planes cluster to a traditional OpenShift cluster:

As stated previously, with virtual clusters provided by OpenShift Virtualization, administration teams can use a single centralized cluster with physical nodes to deploy a large number of individual clusters for multi-tenant workloads.

This is an example architecture showing a single hosting cluster, and multiple virtual clusters:

Such fleet management is greatly eased by the deployment of Red Hat Advanced Cluster Management for Kubernetes (RHACM) as a part of the solution.

The following graphic shows how a managed cluster depends on the hub cluster for a number of advanced features:

These are the four main sections that will be covered in the lab:

Deployment: Using Red Hat Advanced Cluster Management for Kubernetes (RHACM) to deploy a virtual OpenShift on OpenShift cluster using Red Hat OpenShift Virtualization. This section also explores the environment once it’s deployed.

Configuration: Performing operations on the hosting cluster to enact configuration changes on the hosted cluster.

Scaling: NodePools in a hosted control planes environment, like MachineSets in standard clusters, can be configured to autoscale when resources are unavaialable to meet application requests. In this module we will deploy an application and scale it up, requiring the cluster to scale up dynamically to meet application needs.

Cluster Upgrades: This module is an exploration of centralized fleet management by experiencing the cluster upgrade processes, and a walkthrough of the cluster upgrade process using Red Hat Advanced Cluster Management for Kubernetes.