Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

OCPBUGS-15443: [enterprise-4.13] Issue in file installing/installing_bare_metal_ipi/ipi-install-installation-workflow.adoc #63610

Merged
merged 2 commits into from
Aug 17, 2023
Merged

OCPBUGS-15443: [enterprise-4.13] Issue in file installing/installing_bare_metal_ipi/ipi-install-installation-workflow.adoc #63610

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
1b23a1d
Added a load balancing discussion to the overview.
johnwilkins Aug 15, 2023
570704b
Incorporated feedback and removed reference to systemd.
johnwilkins Aug 16, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
13 changes: 9 additions & 4 deletions installing/installing_bare_metal_ipi/ipi-install-overview.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,23 +6,28 @@ include::_attributes/common-attributes.adoc[]

toc::[]

Installer-provisioned installation on bare metal nodes deploys and configures the infrastructure that a {product-title} cluster runs on. This guide provides a methodology to achieving a successful installer-provisioned bare-metal installation. The following diagram illustrates the installation environment in phase 1 of deployment:
Installer-provisioned installation on bare metal nodes deploys and configures the infrastructure that an {product-title} cluster runs on. This guide provides a methodology to achieving a successful installer-provisioned bare-metal installation. The following diagram illustrates the installation environment in phase 1 of deployment:

image::210_OpenShift_Baremetal_IPI_Deployment_updates_0122_1.png[Deployment phase one]

For the installation, the key elements in the previous diagram are:

- **Provisioner**: A physical machine that runs the installation program and hosts the bootstrap VM that deploys the controller of a new {product-title} cluster.
- **Provisioner**: A physical machine that runs the installation program and hosts the bootstrap VM that deploys the control plane of a new {product-title} cluster.
- **Bootstrap VM**: A virtual machine used in the process of deploying an {product-title} cluster.
- **Network bridges**: The bootstrap VM connects to the bare metal network and to the provisioning network, if present, via network bridges, `eno1` and `eno2`.
- **API VIP**: An API virtual IP address (VIP) is used to provide failover of the API server across the control plane nodes. The API VIP first resides on the bootstrap VM. `systemd` manages a `keepalived` instance. A script generates the `keepalived.conf` configuration file before launching the service. The VIP moves to one of the control plane nodes after the bootstrap process has completed and the bootstrap VM stops.
johnwilkins marked this conversation as resolved.
Show resolved Hide resolved

In phase 2 of the deployment, the provisioner destroys the bootstrap VM automatically and moves the virtual IP addresses (VIPs) to the appropriate nodes. The API VIP moves to the control plane nodes and the Ingress VIP moves to the worker nodes.
In phase 2 of the deployment, the provisioner destroys the bootstrap VM automatically and moves the virtual IP addresses (VIPs) to the appropriate nodes.

The `keepalived.conf` file sets the control plane machines with a lower Virtual Router Redundancy Protocol (VRRP) priority than the bootstrap VM, which ensures that the API on the control plane machines is fully functional before the API VIP moves from the bootstrap VM to the control plane. Once the API VIP moves to one of the control plane nodes, traffic sent from external clients to the API VIP routes to an `haproxy` load balancer running on that control plane node. This instance of `haproxy` load balances the API VIP traffic across the control plane nodes.

The Ingress VIP moves to the worker nodes. The `keepalived` instance also manages the Ingress VIP.

The following diagram illustrates phase 2 of deployment:

image::210_OpenShift_Baremetal_IPI_Deployment_updates_0122_2.png[Deployment phase two]

After this point, the node used by the provisioner can be removed or repurposed. From here, all additional provisioning tasks are carried out by controllers.
After this point, the node used by the provisioner can be removed or repurposed. From here, all additional provisioning tasks are carried out by the control plane.

[IMPORTANT]
====
Expand Down