Overview
Glossary
| Term | Description |
|---|---|
| VIP | Virtual IP Address (VIP) is the IP address allocated by MetalLB for LoadBalancer-type internal routes. It provides a unified access entry for external traffic to access services within the cluster. |
| ARP | Address Resolution Protocol (ARP) is a protocol used to map network layer IP addresses to data link layer MAC addresses. |
| GARP | Gratuitous ARP (GARP) is a special type of ARP request used to notify other nodes in the network about the binding relationship between an IP address and a MAC address. Unlike normal ARP requests, GARP does not wait for responses from other nodes; instead, it actively sends information to the network. |
| ARP Responder | A component of MetalLB that responds to ARP requests, mapping VIPs to the MAC addresses of nodes. When nodes need to communicate with a VIP, they send ARP requests to obtain the MAC address corresponding to the VIP. Each available node’s ARP Responder responds to these ARP requests, mapping the VIP to the MAC address of the node. |
| Controller | A component of MetalLB responsible for dynamically allocating VIPs from an external address pool for LoadBalancer-type internal routes. The Controller component listens for the creation and deletion events of internal routes in the cluster, allocating or releasing VIPs as needed. |
| Speaker | A component of MetalLB responsible for deciding whether a node should host a VIP based on policies or algorithms, ensuring a certain level of load balancing between nodes. It also ensures that if one node becomes unavailable, other nodes can take over the VIP and send GARP to maintain high availability. |
MetalLB High Availability Principle
The platform defaults to using MetalLB’s ARP mode. The implementation process and principles are as follows:
-
MetalLB’s Controller component selects an IP address from the external address pool and allocates it to LoadBalancer-type internal routes as a VIP.
-
MetalLB selects available nodes to host this VIP based on the algorithm .
-
The Speaker component on this node proactively sends GARP to establish the mapping relationship between VIPs and MAC addresses on all nodes.
-
Nodes in the same subnet, after learning the mapping relationship between VIPs and MAC addresses of available nodes, directly communicate with this node when accessing the VIP.
-
Nodes in different subnets accessing this VIP route traffic to the subnet’s gateway first, and the gateway forwards the traffic to the node hosting the VIP.
-
-
When this node encounters an abnormality, MetalLB selects another available node to host the VIP, achieving high availability.
-
Once the traffic arrives at the node, Kube-Proxy forwards the traffic to the corresponding Pod.
Algorithm for MetalLB Node Selection to Host VIP
MetalLB hashes all available nodes corresponding to VIPs, sorts them according to a certain algorithm, and selects the first available node as the one to host the VIP.
External Address Pool and Node Quantity
Create an external address pool and add available nodes. All available nodes are in a backup relationship, meaning that only the node hosting the VIP can forward traffic among all available nodes. Therefore, this node needs to handle the traffic of all VIPs in the external address pool.
Calculation Formula
The calculation formula is: External Address Pool Quantity = ceil(n-vip / n-node). Here, ceil rounds up.
Note: If using virtual machines, the number of virtual machines = External Address Pool Quantity * n. Here, n must be greater than 2, and at most one node failure is allowed.
-
n-vip: Number of VIPs.
-
n-node: Number of VIPs a single node can handle.
Application Example
Suppose a company has 10 VIPs, each available node can host 5 VIPs, and one node failure is allowed. How should the company plan the external address pool and the number of available nodes?
Analysis:
Two external address pools and four available nodes are needed in total.
-
Each available node can host up to 5 VIPs, i.e., one external address pool can accommodate 5 VIPs. Thus, for 10 VIPs, two external address pools are required.
-
Allowing one node to fail, each address pool needs to include one node hosting VIPs and one backup node. This requires two available nodes for each address pool, resulting in a total of four available nodes for the two external address pools.