Uploaded image for project: 'OpenShift Container Platform (OCP) Strategy'
  1. OpenShift Container Platform (OCP) Strategy
  2. OCPSTRAT-1832

Separate subnets for control plane vs worker nodes with on-prem networking

XMLWordPrintable

    • BU Product Work
    • False
    • Hide

      None

      Show
      None
    • False
    • 100% To Do, 0% In Progress, 0% Done
    • 0

      Feature Overview (aka. Goal Summary)  

      With on-prem networking (i.e. platform:baremetal or platform:vsphere), all control plane nodes must be in the same subnet, as they share the API VIP that is managed using VRRP. Similarly, all worker nodes must be in the same subnet because they share the Ingress VIP in the same way.

      However, there is no reason in principle that the control plane machine subnet and the worker machine subnet need to be the same subnet.

      Goals (aka. expected user outcomes)

      Allow the API and Ingress VIPs to belong to different subnets.

      Requirements (aka. Acceptance Criteria):

      • Must work in all of Metal IPI, Assisted, ABI, and ZTP installers
      • Verifiable in dev-scripts
      • Exercised by at least a periodic CI job
         
        Deployment considerations List applicable specific needs (N/A = not applicable)
        Self-managed, managed, or both Self-managed
        Classic (standalone cluster) Yes
        Hosted control planes N/A
        Multi node, Compact (three node), or Single node (SNO), or all HA
        Connected / Restricted Network N/A
        Architectures, e.g. x86_x64, ARM (aarch64), IBM Power (ppc64le), and IBM Z (s390x) N/A
        Operator compatibility N/A
        Backport needed (list applicable versions) N/A
        UI need (e.g. OpenShift Console, dynamic plugin, OCM) N/A
        Other (please specify)  

        Use Cases (Optional):

      Include use case diagrams, main success scenarios, alternative flow scenarios.  Initial completion during Refinement status.

      <your text here>

      Questions to Answer (Optional):

      Out of Scope

      Handling topologies where worker nodes are not in the same subnet as each other is out of scope for this Feature.

      Background

      Reportedly, baremetal-runtimecfg contains a number of assumptions that the Ingress and API VIPs are part of the same subnet. Customers have reportedly tried putting them in different subnets without success.

      OCPBUGS-30730 contains information about what would be needed in assisted-service to ensure that validations pass in Assisted/ABI/ZTP, assuming that this were fundamentally possible in OpenShift. (However, the ticket is closed since currently it is not.)

      Customer Considerations

      Documentation Considerations

      Both the baremetal IPI and ABI documentation will need to be updated.

      Interoperability Considerations

              mcurry@redhat.com Marc Curry
              zabitter Zane Bitter
              Ashley Hardin Ashley Hardin
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated: