Making OpenShift on Bare Metal easy

Overview

Provisioning systems is an age-long challenge; applications have to run somewhere and infrastructure is of course required to do so. Over the years we’ve seen automation, standardization of interfaces, and virtualization/cloud API’s making much of the associated problems of provisioning systems go away -- simply login to your favorite platform, click a few buttons, and within minutes your infrastructure is served. But provisioning bare-metal machines has always been a little bit more of a challenge, and aside from ensuring that you’ve got everything plugged in correctly, automating, configuring, and managing the lifecycle of bare-metal systems leaves a lot to be desired.

This problem is further compounded when trying to deploy a distributed system, such as an OpenShift (built on Kubernetes) cluster, where there are many moving parts involved. One of Red Hat’s key goals over the past few OpenShift releases has been to ensure there’s a consistent user experience across the various deployment footprints that our customers are trying to deploy on, e.g. private/public cloud, virtualization, or bare-metal. Just because a customer has a desire to run directly on bare-metal shouldn’t mean that they’re locked out of the automation and platform integration benefits that we strive for with OpenShift. 

In OpenShift 4.6 we introduced the installer-provisioned infrastructure (IPI) workflow using Metal3 to deploy OpenShift on bare metal infrastructure allowing that consistency and common experience to be met. This end-to-end automation, from cabled bare metal nodes in a rack to a working OpenShift cluster with bare metal management capabilities provides the flexibility needed at scale, only requiring simple pre-requisites such as node BMC address and credentials, and an optional network for node deployment (e.g. PXE or virtual media), to be provided.

As we continue to improve the workflow for provisioning bare-metal OpenShift clusters, in this blog post we’re introducing the concept of the Assisted Installer, which focuses in reducing the prerequisites for OpenShift deployment on bare metal nodes even further, bringing the barrier to entry down to a minimum, further simplify and streamline the deployment experience of OpenShift on bare-metal hardware with the very minimum of external requirements. Our vision is a combination of both strengths; fully automated bare metal cluster deployments at scale, and a very low barrier of entry when required.

When it’s required to deploy an OpenShift cluster really fast and with a minimal set of requirements, the assisted installer provides an ideal installation workflow. When we have to deploy and automate the installation of many nodes, tightly integrated with OpenShift’s platform integration, the installer-provisioned infrastructure workflow can do this with Metal3 today.

We had some very firm expectations and design goals associated with this project-

• Cloud hosted web-based UI with a great UX - simplifying the interface to deploying an OpenShift cluster was, of course, paramount, and we felt that to achieve that we needed to have the cluster deployment process driven by a cloud-hosted UI on cloud.redhat.com.
• Minimize complexity and environmental requirements - we really wanted to reduce the list of prerequisites we had for “non-assisted” bare-metal OpenShift installations, namely we wanted to achieve the following-
• Elimination of a separate bootstrap node - OpenShift installs typically require a temporary bootstrap machine, which usually is a separate machine to the three control plane machines. With the assisted installer we only need a minimum of three systems in total - we first deploy a two-node cluster and have the third node be the temporary bootstrap machine; this third machine then pivots to become the third cluster node to complete the installation.
• Elimination of a separate machine to run the openshift-installer binary - this process is now handled and managed by the cloud.redhat.com hosted service, further reducing the number of systems required.
• No reliance on pre-allocated IP addresses from IT for API or ingress services. With the assisted installer it should be possible to set particular IP’s or request an allocation from DHCP, where possible. The cluster will then manage these internally, keep them highly-available, and renew the lease if using DHCP.
• Only a reliance on “simple DHCP” - only requiring a lease for each target node, one that issues a gateway and a DNS server to use, and that’s it. Hostname allocation is not required, and can be overridden in the UI.

• Ability to deploy multiple clusters on a single network, with nodes being deployed in parallel, i.e. masters and workers being deployed at the same time.
• “BIY” (Boot It Yourself) - we recognize that powering systems up and providing them with instructions is straight forward, it can be automated through standardized interfaces, or the web-consoles of the hardware being used -- we’ve implemented a simple ISO-based artifact that each system that’ll be part of the cluster will need to boot from, be that via real CD, virtual CD, USB, or PXE. From then it’s “zero touch” - everything else is driven by the assisted installer, with no need for the installation process to contact the out-of-band management platforms. This ISO is generated on-demand and is therefore customized for each cluster deployment.
• Call-home mechanism - Once the ISO boots up on the target system, provided that there’s a basic set of external networking in place (DHCP enabled, basic DNS to allow internet-based resolution, and a network route, or via proxy, to the cloud-hosted assisted installer platform), the system will call-home, enabling users of the assisted installer to drive the rest of the configuration. This call-home mechanism exploits well-known and trusted APIs over HTTPs - no need for anything more complicated.
• Pre-flight validations - the deployment process should do its best to identify problems and conduct pre-flight checks to ensure that the cluster “should deploy” once kicked-off.
• “Smart” defaults & recommended practices - while we recognize that there’s no “one-size-fits-all” deployment of OpenShift, we wanted to try and standardize the deployment configurables based on what we recommend, including network CIDR’s, optional dynamic role allocation based on available hardware resources, etc.
• Process monitoring and error handling - at all times, we wanted to provide the ability to see what’s going on under the covers - just because it’s a simplified and streamlined process, everything needs to remain visible, helping with troubleshooting, but also to understand progress. The assisted installer is designed to provide deep-dive analysis of cluster deployment progress as well as providing the ability to download the log files throughout the deployment process, avoiding the need to connect directly to the machines; everything is pulled from the cloud service.
• Visualization and persistence - once the cluster is up and running, the assisted installer platform will link you to the endpoint of your new cluster, provide the username/password, the kubeconfig, and persist this information for as long as you need or want it.

With that in mind, as of the release of OpenShift 4.6 earlier this month, we’re excited to announce the developer preview availability of our Assisted Installer platform for all of our OpenShift customers right away - we want you to put it through its paces and we really welcome all of the feedback that you have to give us. We’re happy to say that we’ve met all of our design goals and have a very rich roadmap ahead of us and we can’t wait to hear what you think about it!

Seeing it in Action

If you’d like to put it through its paces, you’re more than welcome to do so right now - we’re live on cloud.redhat.com. If you’d like to see a demo first, here’s a link to a recording we made in the staging environment prior to wider availability on cloud.redhat.com.