-
Epic
-
Resolution: Done
-
Major
-
None
-
None
-
Control plane nodes on separate subnets for on-prem IPI deployments
-
BU Product Work
-
False
-
-
False
-
Not Selected
-
To Do
-
OCPSTRAT-462 - Control plane nodes on separate subnets for on-prem IPI [Phase 2]
-
-
0% To Do, 0% In Progress, 100% Done
-
Epic Goal
I want to install OpenShift with IPI on an on-prem platform (especially on bare metal and vSphere) I need to distribute my control plane nodes across multiple subnets.
Why is this important?
Customers require using multiple logical availability zones to define their architecture and topology for their datacenter. OpenShift clusters are expected to be suitable for this topology and fit in the high availability and disaster recovery plans they designed their datacenter with.
Customers want the benefits of IPI and automated installations and avoid UPI.
Previous Work
Workers on separate subnets
We can already deploy compute nodes on separate subnets by preventing the built-in LBs from running on the compute nodes. This is documented for bare metal only for the Remote Worker Nodes use case: https://docs.openshift.com/container-platform/4.11/installing/installing_bare_metal_ipi/ipi-install-installation-workflow.html#configure-network-components-to-run-on-the-control-plane_ipi-install-installation-workflow
This procedure works on vSphere too, albeit not documented.
Scenarios
- vSphere: I can define 3 or more networks in vSphere and distribute my masters across them. I can configure an external load balancer for the VIPs.
- Bare metal: I can configure the IPI installer and the agent-based installer to place my control plane nodes on 3 or more subnets at installation time. I can configure an external load balancer for the VIPs.
- OpenStack: I can define 3 or more networks in OpenStack and distribute my masters across them. I can configure an external load balancer for the VIPs.
Acceptance Criteria
- Can place control plane nodes on multiple subnets with IPI installations
Done Checklist
- CI - CI is running, tests are automated and merged.
- Release Enablement <link to Feature Enablement Presentation>
- DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
- DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
- DEV - Downstream build attached to advisory: <link to errata>
- QE - Test plans in Polarion: <link or reference to Polarion>
- QE - Automated tests merged: <link or reference to automated tests>
- DOC - Downstream documentation merged: <link to meaningful PR>
- is cloned by
-
-
- Closed
-
