This message was deleted.
# general
a
This message was deleted.
c
Yes, start them with --node-external-ip set to the correct value. Or disable the built in stub cloud controller and deploy the correct one for where your infra is hosted.
This is covered in the docs
c
Hi Brad,
Thanks for taking the time to reply. I tried stopping the k3 server via systemctl and manually started it with --node-external-ip set to the IP Address of the server and that works however I have both k3s and rke2 test clusters (for learning) and was told that metallb was the best choice? I created a test Nginx deployment and a service and that does get a working IP-Address from the pool so I am now very confused as to which is the best way forward? Can I use just ServiceLB with K3s and not even install Metallb and what happens with RKE2? Thanks again in advance, Andrew
c
I’m confused what the node external IP has to do with your LoadBalancer controller? What are you trying to do?
c
Brad, I am just trying to build containers and services that I can access from the (external) network. I have been learning how to build Rancher K3s and RKE2 clusters on bare-metal Linux as most of my customers cannot afford to use the cloud for these kinds of projects. In my experience there are a lot of companies that would love to experiment in this way and to modernise their workloads but the initial learning curve is very steep and they afraid of a costly mistake. My biggest point of confusion is the best way to expose services externally whilst providing HA and all the docs I have read seem to always use Metallb (or sometimes Nginx). Any advice would be gratefully received. Regards, Andrew
c
ServiceLB is not a real LB controller. It just uses the nodes IPs as an entrypoint for LoadBalancer type Services. It is enough to use LoadBalancer Services but does not actually add any HA. This is covered in the K3s docs. If you want a real load-balancer, with virtual IPs and such, you should use kube-vip or metallb.