This page analyses the steps and components used by OpenShift's Installer-provisioned installation (IPI) when deploying a multi-node cluster on bare-metal servers. It assumes the reader is familiar with the overall architecture and workflow of IPI and has successfully deployed an OpenShift or OKD cluster using IPI before (guide).
Installer-provisioned installation (IPI) is a part of and triggered by OpenShift Installer.
When creating OpenShift Container Platform manifests with OpenShift Installer, i.e.
openshift-baremetal-install create manifests, the bare-metal nodes listed in install-config.yaml are turned into
TerraForm variables for the Terraform provider for Ironic and
into BareMetalHost resources for Metal³'s Bare Metal Operator.
When OpenShift Installer, i.e. openshift-baremetal-install create cluster, is run to deploy a cluster, it starts a bootstrap VM at the provisioner host using Terraform (stages, variables).
Master nodes are bootstrapped with Ironic in Podman containers with help of the Bare Metal
Operator (in the bootstrap control plane) running on the bootstrap VM. Worker nodes are provisioned
later using the same components but running on the control plane provided by the master nodes.
The bootstrap VM will run build-ironic-env.service which in turn will run build-ironic-env.sh to prepare an environment, in particular extract container image urls, for Metal³'s Bare Metal Operator, Machine Image Customization Controller, Metal3 Ironic Container and others. Afterwards, the bootstrap VM will run these services as Podman containers.
The Machine Image Customization Controller will build "a CoreOS live image customized with an Ignition file to start the Ironic Python Agent (IPA) and containing any per-host network data provided in NMState format" and will serve it "from a webserver built in to the controller". It will be run on the bootstrap VM as Podman container image-customization. The script setup-image-data.sh is responsible for pulling the NMState network data for each master node from Bare Metal Operator which runs on the bootstrap control plane. The CoreOS images has been extracted before with extract-machine-os.service.
The Metal3 Ironic Container, also running at the bootstrap VM, will be fed with configuration data about the master nodes by the Terraform provider for Ironic from OpenShift Installer. It will launch, inspect and deploy each master node from a tailored CoreOS live image which was created by Machine Image Customization Controller earlier. The CoreOS live image runs the Ironic Agent Container which contains the Ironic Python Agent (IPA) for communication with Ironic as well as the ironic_coreos_install.py script. The latter will run the custom deployment step install_coreos which will use coreos-installer to install CoreOS to disk together with a suitable Ignition config, network config and kernel arguments to bring up that master node.
While Ironic is running on the bootstrap VM, another service master-bmh-update.service, i.e. script master-bmh-update.sh, will be started. It waits until
the Bare Metal Operator has been started on the bootstrap control plane, has been populated with BareMetalHost
resources and Ironic has finished the hardware introspection of all master nodes. It will then update the Bare Metal
Operator with the introspection results and shutdown Ironic on the bootstrap VM so that the API VIP can fail over to the
control plane which is running on the master nodes by now.
When master nodes have been provisioned successfully, Terraform will destroy the bootstrap VM. The master nodes will now run the control plane exclusively. The Bare Metal Operator and Ironic running on the master nodes' control plane will then provision all worker nodes.