This message was deleted.

We tried a few months back and found it to be unreliable and buggy

may i know what kind of issues you ran into. My research says that when it comes to native integration with big ip this controller is our best path. rancher by default installs nginx controller as host port in on prem scenarios. We cannot scale it out and it is not the kubernetes standards

We ended up creating dedicated ingress nodes that we pointed our BigIP set up at and let K8s do the routing. Looking at my notes our biggest issues were something about HTTPS health probes not being supported and then it's update cycle was very slow. A pod would go down and it would take some time for the controller to then update the F5 with the fact the pod was down. We were also in VXLAN mode, so that may be part of it, but if I recall we asked around and other people weren't very happy with it either. That was some time ago, so things may have changed, but so far we haven't looked back

hmm interesting observations. The issue I have with your set up is that big ip is just proxying to the k8s node in round-robin fashion so no real loadbalancing happens on big ip side. Once it comes to kubernetes in host port fashion then it would route it to the appropriate service. The issue I had with it is as it round robin at times the ingress controller you have would get hot and then clients will be suddenly lost in that set up. We are facing that today, we have ingress controllers that are running in host port fashio

Yeah, it's not perfect, but in our case we couldn't accept sending traffic to dead pods and clients getting timeouts over and over. In any case, hopefully you have more success with it than we did

in your case did you suffer clients getting timeouts as well? in our case with current set up we need to restart nginx ingres scontroller from time to time

We did in our testing, but we also don't use nginx as our ingress

even in your case big ip would randomly send traffic to a kubernetes node meant for ingress and if the ingress is running hot your requests are trapped

We use Istio

ah ok istio gateway should be better 🙂

We're RKE2 with Canal. If I recall we did manage to get vxlan working but it wasn't documented. I think we ended up finding the instructions in a recorded lab demo they showed

ah thanks so much for sharing the link really appreciate it. we have rke1 and canal i believe is calico + flannel d( for pod ip address). However, canal is not an option for us, we need calico cni for our cluster.