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

Support of routed ingress for secondary OVN Kubernetes networks

XMLWordPrintable

    • BU Product Work
    • False
    • Hide

      None

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

      Feature Overview (aka. Goal Summary)  

      Support of routed ingress for secondary OVN Kubernetes networks.

      Goals (aka. expected user outcomes)

      OVN Kubernetes secondary network overlay should add a support for a new ingress method. While RFE-4938 already asks for a NAT'ed approach, this new RFE is interested in routed ingress.

      Requirements (aka. Acceptance Criteria):

      PoCs of this approach exist online:

      We already have FRR controller available in MetalLB CNF-10216 https://github.com/metallb/frr-k8s, that may handle the route advertisement part of the implementation. The changes on OVN Kubernetes should be similar to those done for NAT'ed approach, possibly just being a new "mode" of ingress.

       

      Deployment considerations List applicable specific needs (N/A = not applicable)
      Self-managed, managed, or both  
      Classic (standalone cluster)  
      Hosted control planes  
      Multi node, Compact (three node), or Single node (SNO), or all  
      Connected / Restricted Network  
      Architectures, e.g. x86_x64, ARM (aarch64), IBM Power (ppc64le), and IBM Z (s390x)  
      Operator compatibility  
      Backport needed (list applicable versions)  
      UI need (e.g. OpenShift Console, dynamic plugin, OCM)  
      Other (please specify)  

      Use Cases (Optional):

      • A customer requires that their virtual machines on OpenShift are directly routable from inside and outside of the cluster. A virtual machine should get an IP address so that clients running in OpenShift pods and clients running outside of OpenShift can open a connection to the VM.
      • It is required that we use no NAT to achieve this. The IP address the VM has must be the IP that is used to communicate with it, both for inbound and outbound communication patterns.
      • Nice to have:  Use NetworkPolicies to filter the VM traffic.

      Questions to Answer (Optional):

      Out of Scope

      Background

      • So far, the customer has been connecting the VMs to a custom VLAN via bridge to achieve the direct routing goal. The customer doesn't like this approach since it's difficult to automate the management of VLAN configurations on the cluster nodes and physical switches …
      • It is known that the VMware NSX Edge router provides such functionality.

      Customer Considerations

      Documentation Considerations

      Interoperability Considerations

       

              mcurry@redhat.com Marc Curry
              anosek@redhat.com Ales Nosek
              Ashley Hardin Ashley Hardin
              Tim Rozet Tim Rozet
              Tim Rozet Tim Rozet
              Marc Curry Marc Curry
              Chris Fields Chris Fields
              Votes:
              2 Vote for this issue
              Watchers:
              7 Start watching this issue

                Created:
                Updated: