Do we need any specific wifi-router/ LAN router with metalLb in kubernetes.
How does metalLB help if it is on a machine .. all the router traffic would have to first come on the machine and then get routed; causing the machine to be the bottleneck.
Shouldn't the metalLB solution fit somewhere in the router itself ?
Maybe first what is MetalLB and why to use it:
MetalLB is a load-balancer implementation for bare metal Kubernetes clusters, using standard routing protocols. ... Bare metal cluster operators are left with two lesser tools to bring user traffic into their clusters, “NodePort” and “externalIPs” services. Both of these options have significant downsides for production use, which makes bare metal clusters second class citizens in the Kubernetes ecosystem.
MetalLB aims to redress this imbalance by offering a Network LB implementation that integrates with standard network equipment, so that external services on bare metal clusters also “just work” as much as possible.
There is nothing special needed besides correctly routing the traffic to your bare metal server. You might set it up as DMZ Host or just forward ports to the server behind the router.
If you are looking into Load Balancing a traffic before the server, that will only work with several servers. If you have 4 bare metal serves, you can setup one as master node and other three as worker nodes, so master node would be responsible for balancing the load across worker nodes.
You can use MetalLB in Layer 2 Mode
In layer 2 mode, one node assumes the responsibility of advertising a service to the local network. From the network’s perspective, it simply looks like that machine has multiple IP addresses assigned to its network interface.
Under the hood, MetalLB responds to ARP requests for IPv4 services, and NDP requests for IPv6.
The major advantage of the layer 2 mode is its universality: it will work on any ethernet network, with no special hardware required, not even fancy routers.
and BGP Mode
In BGP mode, each node in your cluster establishes a BGP peering session with your network routers, and uses that peering session to advertise the IPs of external cluster services.
Assuming your routers are configured to support multipath, this enables true load-balancing: the routes published by MetalLB are equivalent to each other, except for their nexthop. This means that the routers will use all nexthops together, and load-balance between them.
Once the packets arrive at the node,
kube-proxyis responsible for the final hop of traffic routing, to get the packets to one specific pod in the service.
You can read more about usage or MetalLB here.