Deploying OpenShift 4.x on non-tested platforms using the bare metal install method

Red Hat OpenShift Container Platform 4 can be deployed to many on-premise and public cloud providers in addition to bare metal physical servers. While Red Hat is working to expand provider support in future releases, customers may need to deploy OpenShift in their environment in advance of Red Hat delivering this capability.

The bare metal installation method (this includes using the This page is not included, but the link has been rewritten to point to the nearest parent document.Agent based installer with platform=none starting with 4.14 and the platform agnostic installation method) provides a generic approach for deploying OpenShift 4 to environments that may lack formal integration with your private or public cloud provider. Customers should be aware of the constraints associated with this deployment method in advance of deploying their OpenShift 4 cluster and plan accordingly.

Once customers have familiarized themselves with how the installation should be performed (please refer to the bare metal installation documentation for further details), OpenShift 4 can be successfully deployed in most environments. You should be aware of a number of areas where this installation method may not support your particular provider or may even require minor modifications when deploying OpenShift. Remember, these areas are only applicable if you are trying to use our bare metal installation method to deploy OpenShift on virtualization or cloud solutions that Red Hat has not yet tested or provided a documented installation method.

Note: 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 provider, which OpenShift 4 has not yet been specifically developed for or tested on.

1. Red Hat Enterprise Linux CoreOS: Validate the level of support available from RHEL CoreOS for the targeted server hardware or virtualization technology. Levels of support will range from certified to commercially reasonable, refer to listings for ‘Red Hat Enterprise Linux 8’ in the Red Hat Enterprise Linux Certified Ecosystem for more information.

2. Guest Management Agent: Many virtualization solutions or clouds require the use of an agent be loaded on the operating system. Required agents should be installed as a containerized workload deployed via a daemonset. Non-containerized agents are not supported on RHEL CoreOS.

3. 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 Baremetal 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 can't be enabled, because the nodeControllerLifecycle won’t allow foreign nodes (outside of the provider you’re running with) to be added to the cluster, and you can't specify more than 1 cloud provider integration.

4. Machine API: In order to use MachineSets 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.

5. Ignition Handling: As part of the RHEL CoreOS bootstrap process, an ignition config needs to be provided to the host. A number of cloud providers have the mechanism to inject the ignition config to the system as an initial part of it’s deployment, administrators should leverage this functionality if it is available. Where the provider does not have this functionality, administrators will need to host ignition configs on a separate HTTP server instance.

6. VM format: Determine if Red Hat offers a pre-built VM disk format of RHEL CoreOS for your environment. If not, administrators will need to deploy RHEL CoreOS using the ISO image, this is part of the procedure to manually deploy the nodes.

7. 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.

8. Load Balancers: The control plane requires a load balancer to distribute API requests accross all 3 master nodes for in 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 will suffice.