@etlweather I found a question on stack overflow with an interesting answer. It looks a lot like the comment from @cwade
I’m not sure if I would have to point each service on the MetalLB or my Ingress Controller (Ngnix) could use it.
MetalLB looked like a good option, but I didn’t try it because its Layer 2 mode (I wouldn’t be using BGP in my case) is not much different than Keepalived and since I was already familiar and experienced with Keepalived, I preferred sticking with it rather than brigning yet another technology to my growing list.
But from what I read in its docs, it seems to be a very good solution.
I think I will try it. What I’m wondering is if I can make it work with the Nginx Controller so that I can use the UI or if I have to always configure it in .yml. I’m not Rancher/Kubernetes experts (first time deploying it) so I don’t understand everything that is going on.
Also since I’m more a Dev than a OP, your keepalived configuration files scared me, but maybe I’ll try it.
@etlweather Thanks for the writeup! I work on Ambassador, so your feedback is greatly appreciated.
- Right now, Ambassador only routes to Kubernetes services, not pods. Thus, the load balancing is limited to round robin, and we rely on Kubernetes to remove pods from the round robin.
- We are working on changing Ambassador to route dynamically to pods, which will enable more advanced behavior (e.g., circuit breaking, smarter load balancing, etc.). This work is very much in progress at the moment, hopefully in the next month or so.
- The reason why the documentation suggests you create the annotations on a per-service basis is because we typically see different engineers/teams responsible for different services, and in this model, each service team can control / manage their own routes. As you discovered, you can of course create a central configuration, but this can get big over time.
Thanks again, hope this is useful info!
Thanks @richarddli - that explains the results I got.