I installed k3s on one of the node on the TP2 and I am using NGINX as ingress controller. Without any setup the ingress IP is automatically the same as the one of the BMC. This is somehow amazing (and unexpected). The only drawback is that every time I want to make an HTTP request to the BMC, this gets intercepted by nginx and end up with a "not-found" error. Is there any documentation on how to control the load-balancer and what is actually load-balancing? 🙂 Thank you very much! Riccardo

Check metalLB

mmm no, I am saying that wihtout any configuration, NGINX uses the BMC address as the ingress instead of the address of one of the noes... is this expected?

I know nearly not enough about k3s and Kubernetes in general, but this is not Nginx which uses an IP. An app like this cannot just use an IP. This IP had to be assigned to a node. When setting IP addresses, you always need to use these outside of the range of the DHCP in your router

Yeah there is something funny going on with your configuration

But then the BMC gets it's IP first (it's network interface appears in the network first, then the nodes with statically-configured IPs) 🙂

VladoPortos have a nice starting tutorial regarding networking https://help.turingpi.com/hc/en-us/articles/8942935354013-Network-setting

I am using NGINX as. a ingress controller. Even in case I set somewhere by mistake that the IP of the ingress was the same as the one of the bmc, the bmc, the IP of the BMC was redirected to the NGINX controller.... This is why I was imagining that the BMC was somehow working as a loadbalancer for the nodes...

nope

Thank you... I ll test it again installing everything from scratch 🙂

Can you check the IPs?

if the OS on the BMC itself would understand IPVS it could do some cheap loadbalancing on layer 2, by MAC rewrite, the mode is "DirectRouting" in IPVS. In this case the Pis and the BMC need to be on the same L2 segment. And only the SYN and ACK packets are seen by the BMC, and the data is flowing via the switch directly to the client. Nearly no work for the CPU of the BMC.

The IP are assigned directly from the router using dhcp but they are static. The IPs are 10.1.10.200/1/2/3/4. When you say non-colliding you mean in different networks?

that what I meant, the assignment vioa DHCP cannot be changed except for the DHCP server. But the range MetalLB uses is declared in the config structures you write 🙂 good that you found it

Yep... I thought I was using metallb only for the kube api... But nginx was there too 🙂