Red Hat OpenShift at the edge: zero-touch provisioning

Information technology is undergoing a remarkable evolution, with deployment and maintenance scenarios changing day by day. Processing and managing data and devices at the edge is increasingly required, so technologies need to adapt to support and encourage the adoption of such strategies.

Red Hat OpenShift is capable of covering needs ranging from the management of an infrastructurally-agnostic application platform to deployment on-premises or in the cloud, whether private, public or hybrid.

However, the ability to adapt to any scenario has evolved enormously over time. Leveraging lighter configurations, such as the compact 3-node deployment mode or the single-node configuration, allow the same flexibility and performance characteristics, albeit with a smaller footprint. 

This flexibility allows OpenShift to adapt to deployments in scenarios with reduced computing capacity and hardware usage constraints, such as remote sites, whether they are branch offices or individual computing and processing sites.

Let's imagine that we have a multitude of these edge sites, and we need to reach all of them with technology that guarantees centralized computing capacity and management of our workloads. We are able to replicate and propagate configurations and settings that are compliant with the pre-defined policies and site-related scenarios and that, above all, are available in a short time, reducing complexity and improving replicability and reliability.

This use case can be covered with zero-touch provisioning (ZTP), which is possible thanks to the flexibility of the Assisted Installer of OpenShift and the versatility and simplicity of centralized cluster and infrastructure management offered by Red Hat Advanced Cluster Management for Kubernetes.

Zero-touch provisioning, as the name suggests, is a mode of provisioning OpenShift clusters on bare metal. This type of provisioning allows us to create multiple cluster-setup flavors based on the needs of remote sites without physically interacting with our devices. To achieve this, it is necessary to declare the desired configurations for our clusters on specific resources, leaving the various components of Red Hat Advanced Cluster Management with the task of translating them into provisioning operations, both of the infrastructure nodes by interfacing with the Baseboard Management Controller (BMC) and of the clusters, by exploiting the OpenShift Assisted Installer functions.

Since all the resources defined are self-contained, they can be stored in a Git repository and applied using the OpenShift GitOps operator (based on ArgoCD), defining our sites and clusters as if they were normal applications.

Below is a diagram of some of the use cases, where we can see that this mode of provisioning involves only one cluster, which will act as a hub within the central data center.

The features we are going to discuss today are currently in technology preview. However, we can see how we can create and deploy streamlined configurations at scale.

Use case: single-node OpenShift at the edge with ZTP

Let’s look at each piece that makes up our puzzle and how we can put them all together to get a complete picture.

The main Red Hat Advanced Cluster Management components involved in the process are:

• OpenShift bare metal operator
• Assisted Installer
• multicluster engine - Hive Operator

Since we are going to touch on issues relating to edge devices, our reference world is that of bare metal. Here, setup modes are already available based on the infrastructure provided by the user and installations on the infrastructure provided by the installer, which we will exploit in the various stages of deployment.

Each remote device is associated with a site, which corresponds to the definition of the fundamental parameters that must be considered during the configuration phase, which translates into a custom resource definition (CRD) called SiteConfig.

The CRD will define:

• Details about the BMC that we will use to manage our nodes
• Details relating to the cluster(s) (cluster name, domain) 
• Network configurations (subnet for pods, services, machines)
• Node(s) configurations (network settings, partitioning, any hardening needed via policy)

This information is managed and translated into sub-resources that are managed by the different components to orchestrate the different stages of deployment.

To simplify, the logical flow of ZTP is as follows:

Let us look in detail at the different resources mentioned and their role.

BareMetalHost

BareMetalHost (BMH) handles information from the BMC, which is then interpreted by the OpenShift bare metal operator to create the bare metal node within OpenShift to prepare and configure the remote node. This is the beating heart of node provisioning, as it allows the operator to remotely configure the boot devices tailored to the setup we are going to perform.

InfraEnv

InfraEnv defines details about networking, the NTP servers to be used on the nodes it will host, the secure shell (SSH) key that will be used to access the nodes that will be hooked up and the credentials to access the container images required for installation. Along with the ClusterDeployment resource, it is used to build the discovery ISO for the assisted installer.

AgentClusterInstall

Contains the information that will be consumed by the Assisted Installer to generate the boot image that will be used by our nodes to continue installing and configuring the cluster, including the version, name and network configurations.

ClusterDeployment

Combines the information defined in AgentClusterInstall and adds other information required for the correct deployment of the cluster, which will be embedded in the boot ISO for the node.

ManagedCluster and KlusterletAddonConfig

These resources may already be familiar to users of Red Hat Advanced Cluster Management. These define information about the cluster to allow it to be imported and managed within the Red Hat Advanced Cluster Management hub, configuring the services required for communication.

Once the provisioning process and cluster setup through the OpenShift Installer are complete, our hub will display the new single node OpenShift as installed and docked, ready to be used to deploy our workloads.

Summary

In this article, we introduced the concept of ZTP for OpenShift in edge scenarios and explained how it can make the platform provisioning process simpler, repeatable and scalable from an Infrastructure as Code (IaC) approach.

The technology is in continuous development and is currently mature enough that you can experiment with this innovative method for bringing a complete application platform into any scenario.