I'd like to put F5 BIG-IP devices in front of my traffic that is inbound to my ARO cluster. This is supported by both RH and F5.
In the past I have done this by integrating the BIG-IP's with the Openshift CNI and using VXLAN. However, now that OVN Kubernetes is the preferred CNI, I would like to use the "no tunnels" option and route traffic that is destined for Pod IP addresses directly at the worker nodes hosting the pod.
This would require me to check the box "Enable IP forwarding" on the NIC of the Azure VM that is the OCP worker node. However, we cannot do this via the Azure portal. We get an error due to insufficient permissions, and it appears that the ARO deployment has created RBAC resources to disallow changes to the NIC that are not created by the ARO deployment itself.
I would like the ability to either update this checkbox in the portal, or, for the ARO deployment to enable this attribute itself (or, for the deployment to have the option to enable this attribute).
Please let me know if this makes sense. Without this, NodePort (and therefore kube-proxy) must be used to ingress traffic into the cluster. Thanks.
Hi,
I'd like to put F5 BIG-IP devices in front of my traffic that is inbound to my ARO cluster. This is supported by both RH and F5.
In the past I have done this by integrating the BIG-IP's with the Openshift CNI and using VXLAN. However, now that OVN Kubernetes is the preferred CNI, I would like to use the "no tunnels" option and route traffic that is destined for Pod IP addresses directly at the worker nodes hosting the pod.
Here is an example F5/Openshift architecture that I am looking to achieve with ARO: https://clouddocs.f5.com/containers/latest/userguide/openshift/openshift-4-12-cluster.html
This would require me to check the box "Enable IP forwarding" on the NIC of the Azure VM that is the OCP worker node. However, we cannot do this via the Azure portal. We get an error due to insufficient permissions, and it appears that the ARO deployment has created RBAC resources to disallow changes to the NIC that are not created by the ARO deployment itself.
I would like the ability to either update this checkbox in the portal, or, for the ARO deployment to enable this attribute itself (or, for the deployment to have the option to enable this attribute).
Please let me know if this makes sense. Without this, NodePort (and therefore kube-proxy) must be used to ingress traffic into the cluster. Thanks.