-
Feature Request
-
Resolution: Done
-
Normal
-
None
-
openshift-4.11.z
-
False
-
None
-
False
-
Not Selected
-
-
-
-
-
1. Proposed title of this feature request
Allow Openshift Baremetal IPI deployment in routed networks
2. What is the problem that your customer is facing?
Currently, Openshift BM IPI does not support deploying in a layer 3 setup because it uses keepalived/haproxy deployment for Ingress/API VIP. Which cannot be used in a layer 3 setup.
3. What is the nature and description of the request?
Layer3 spine-and-leaf architecture is way more scalable in a larger Openshift environment than deploying everything in a single layer2 network. Also these are the benefits of a spine-and-leaf architecture:
- Reduced domain for broadcast, unknown unicast, and multicast (BUM) traffic.
- Reduced failure domain.
- Geographical separation.
- Association between IP address and rack location.
- Better cross-vendor support for multipath forwarding using equal-cost multipath forwarding (ECMP) via L3 routing, instead of proprietary “fabric”.
4. Why does the customer need this? (List the business requirements here)
Our datacenter architecture is setup like this (L3 setup), we don't want to deviate from our architecture. Also the L3 setup is way more scalable (see benefits in question #3)
5. What is the business impact, if any, if this request will not be made available?
A Baremetal Openshift cluster that does not scale. Also all traffic for ingress & API is currently forwarded to a single node where the VIP lives.
6. List any affected packages or components.
Bootstrapping needs to change so it doesn't use keepalived. It needs to deploy a BGP client (or metallb) in bootstrapping phase which announces a VIP towards the ToR switches.
Customer currently deploys our cluster with Calico SDN which supports BGP by default and announces all the routes of pods/services cidr's towards the TORs. They don't know if OVN SDN can do the same. They use these architecture docs:
- is related to
-
OPNET-14 Add override for internal api and ingress DNS records
- New