Load Balancing and MetalLB [ENT 21.3 ARC]

Cloud

When using managed Kubernetes clusters in the cloud (Azure, AWS, Google) the Kubernetes ingress controller(s) can create and/or communicate with the load balancer(s) of the respective cloud provider. This connection between the ingress controller and the cloud load balancer ensures that the cloud load balancer routes the traffic to the cluster nodes where the ingress controllers are running on. It also ensures distribution of the traffic between these cluster nodes according to the rules available on the cloud’s load balancers.

Draw.io diagram view with the standard Confluence view.

On-Premises

For on-premises systems there’s no ready-made concept available in Kubernetes. This is where MetalLB jumps in.

MetalLB can run in two different modes:

Layer-2 mode
BGP mode

MetalLB Layer 2 Mode

How It Works

In layer-2 mode a virtual load balancer IP needs to be defined. The hostname of your application (https://vidispine.customer.com in the diagram) needs to resolve to this virtual IP.

The MetalLB controller running in a single instance decides which node should receive the traffic for the virtual IP. The MetalLB speaker on the designated node responds to ARP/NDP requests for this LB virtual IP and returns the MAC address of the node it is running on.

When the MetalLB controller detects that the designated node is down, it selects one of the other nodes for receiving the external traffic. Now the MetalLB speaker on the new node takes over and will respond to ARP/NDP requests for the LB virtual IP.

In case the node with MetalLB controller does down Kubernetes will start up the controller pod on a different node.

Drawbacks

Failover from one node to another may take up to 10 seconds. During this time the system is not reachable.
As the LB virtual IP always points to a single node there is no load balancing taking place. Only failover in case of a node failure is ensured.