4.4 RedHat OpenShift 4.x installation
RedHat OpenShift Container Platform is run under the RedHat Enterprise Linux operating system providing a management layer for the Kubernetes Container system, including an integrated application system for runtimes and libraries.
The bare metal installation method described in this section allows deployment of OpenShift 4.x to environments that are not integrated with a private or public cloud provider.
4.4.1 Overview
For the full step-by-step procedure for the base installation of RedHat OpenShift 4.x see the BPB book, Installation and Configuration of IBM Watson Analytics and StoredIQ in Chapter 7: Red Hat OpenShift 4.x Installations (BPB Publications, ISBN 9390684498, 9789390684496).
This covers the pre-requisite setup of the cluster servers required for the following procedure. Also, the step by step procedure is covered by RedHat at https://docs.openshift.com/container-platform/4.7/installing/installing_vsphere/installing-vsphere-installer-provisioned.html#installation-vsphere-infrastructure_installing-vsphere-installer-provisioned
4.4.2 Pre-requisites
An outline list of prerequisites is provided at the following link (you will need a Red Hat logon to view this page):
https://access.redhat.com/articles/4207611
In summary, the following is only applicable for customers using the OpenShift 4 bare metal installation method to deploy OpenShift on a RHEL certified virtualization or cloud:
• Validate the level of support available from RHEL CoreOS See the link https://catalog.redhat.com/#/ecosystem/Red%20Hat%20Enterprise%20Linux
• Guest Management Agent: Many virtualization solutions or clouds require the use of an agent be loaded on the operating system.
Non-containerized agents are not supported on RHEL CoreOS.
• OpenShift cloud provider: This provides an interface between an OpenShift cluster and the cloud provider’s API and is required to use features such as dynamic storage, on-demand service routing, node hostname to Kubernetes hostname resolution, and cluster autoscaling. An OpenShift 4 cluster will not have access to these capabilities if there is no cloud provider integration.
Note: Often times, a Bare metal install (on one or more cloud) decision will be made to mix, resources from different services, providers or span physical and virtual boundaries. In these situations, the cloud provider integrations cannot be enabled, because the node controller lifecycle will not allow foreign nodes (outside of the provider you are running with) to be added to the cluster, and you cannot specify more than 1 cloud provider integration.
• Machine API: In order to use Machine Sets or cluster-autoscaling to automate the provisioning of nodes within the cluster, OpenShift requires a machine API implementation for the targeted provider. Without the Machine API, a cluster administrator has the responsibility to create and join nodes to the OpenShift 4 cluster.
• Ignition handling: As part of the RHEL CoreOS bootstrap process, an ignition config needs to be provided to the host. On RHEL 8.0 administrators will need to host ignition configs on a separate HTTP server instance. There is an installation using the RHEL ISO image, this is part of the procedure to manually deploy the nodes.
• Persistent storage: Storage will need to be manually provisioned to leverage the optional framework components such as the embedded container registry, Elasticsearch, or Prometheus. Unless configured, Bare Metal deployments do not define a default storage class.
• Load balancers: The control plane requires a load balancer to distribute API requests across all 3 master nodes, for a highly available architecture. While Red Hat Enterprise Linux ships with tools to provide load balancer functionality, any TCP base load balancing solution that meets the DNS routing and port requirements should work.