-
Feature
-
Resolution: Unresolved
-
Normal
-
None
-
None
-
BU Product Work
-
False
-
-
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:
- Implementation using a FRR router pod https://josecastillolema.github.io/icni2/
- Implementation using OVN https://developers.redhat.com/blog/2018/11/08/how-to-create-an-open-virtual-network-distributed-gateway-router#
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
- clones
-
RFE-5459 Support of routed ingress for secondary OVN Kubernetes networks
- Accepted