As a cluster administrator, you can add the MetalLB Operator to your cluster so that when a service of type
LoadBalancer is added to the cluster, MetalLB can add an external IP address for the service.
The external IP address is added to the host network for your cluster.
You can configure MetalLB so that the IP address is advertised with layer 2 protocols. With layer 2, MetalLB provides a fault-tolerant external IP address.
You can configure MetalLB so that the IP address is advertised with the BGP protocol. With BGP, MetalLB provides fault-tolerance for the external IP address and load balancing.
MetalLB supports providing layer 2 for some IP addresses and BGP for other IP addresses.
Using MetalLB is valuable when you have a bare-metal cluster, or an infrastructure that is like bare metal, and you want fault-tolerant access to an application through an external IP address.
You must configure your networking infrastructure to ensure that network traffic for the external IP address is routed from clients to the host network for the cluster.
After deploying MetalLB with the MetalLB Operator, when you add a service of type
LoadBalancer, MetalLB provides a platform-native load balancer.
The MetalLB Operator monitors its own namespace for the following custom resources:
When you add a
MetalLB custom resource to the cluster, the MetalLB Operator deploys MetalLB on the cluster.
The Operator only supports a single instance of the custom resource.
If the instance is deleted, the Operator removes MetalLB from the cluster.
MetalLB requires one or more pools of IP addresses that it can assign to a service when you add a service of type
When you add an
AddressPool custom resource to the cluster, the MetalLB Operator configures MetalLB so that it can assign IP addresses from the pool.
An address pool includes a list of IP addresses.
The list can be a single IP address that is set using a range, such as 188.8.131.52-184.108.40.206, a range specified in CIDR notation, a range specified as a starting and ending address separated by a hyphen, or a combination of the three.
An address pool requires a name.
The documentation uses names like
An address pool specifies whether MetalLB can automatically assign IP addresses from the pool or whether the IP addresses are reserved for services that explicitly specify the pool by name.
An address pool specifies whether MetalLB uses layer 2 protocols to advertise the IP addresses, or whether the BGP protocol is used.
The BGP peer custom resource identifies the BGP router for MetalLB to communicate with, the AS number of the router, the AS number for MetalLB, and customizations for route advertisement.
MetalLB advertises the routes for service load-balancer IP addresses to one or more BGP peers.
The service load-balancer IP addresses are specified with
AddressPool custom resources that set the
protocol field to
The BFD profile custom resource configures Bidirectional Forwarding Detection (BFD) for a BGP peer. BFD provides faster path failure detection than BGP alone provides.
After you add the
MetalLB custom resource to the cluster and the Operator deploys MetalLB, the MetalLB software components,
speaker, begin running.
The Operator includes validating webhooks for the
BGPPeer custom resources.
The webhook for the address pool custom resource performs the following checks: that the address pool name is unique.
Address pool names must be unique.
IP address ranges do not overlap with an existing address pool.
If the address pool includes a
bgpAdvertisement field, the
protocol field must be set to
The webhook for the BGP peer custom resource performs the following checks:
If the BGP peer name matches an existing peer, the IP address for the peer must be unique.
keepaliveTime field is specified, the
holdTime field must be specified and the keep-alive duration must be less than the hold time.
myASN field must be the same for all BGP peers.
When you install the MetalLB Operator, the
metallb-operator-controller-manager deployment starts a pod.
The pod is the implementation of the Operator.
The pod monitors for changes to the
MetalLB custom resource and
AddressPool custom resources.
When the Operator starts an instance of MetalLB, it starts a
controller deployment and a
speaker daemon set.
The Operator starts the deployment and a single pod.
When you add a service of type
LoadBalancer, Kubernetes uses the
controller to allocate an IP address from an address pool.
The Operator starts a daemon set for
By default, a pod is started on each node in your cluster.
You can limit the pods to specific nodes by specifying a node selector in the
MetalLB custom resource when you start MetalLB.
For layer 2 mode, after the
controller allocates an IP address for the service, the
speaker pods use an algorithm to determine which
speaker pod on which node will announce the load balancer IP address.
The algorithm involves hashing the node name and the load balancer IP address.
See the section about external traffic policy for more information.
speaker uses Address Resolution Protocol (ARP) to announce IPv4 addresses and Neighbor Discovery Protocol (NDP) to announce IPv6 addresses.
For BGP mode, after the
controller allocates an IP address for the service, each
speaker pod advertises the load balancer IP address with its BGP peers.
You can configure which nodes start BGP sessions with BGP peers.
+ Refer to the concepts for layer 2 mode and BGP mode for more information.
Requests for the load balancer IP address are routed to the node with the
speaker that announces the IP address.
After the node receives the packets, the service proxy routes the packets to an endpoint for the service.
The endpoint can be on the same node in the optimal case, or it can be on another node.
The service proxy chooses an endpoint each time a connection is established.
In layer 2 mode, the
speaker pod on one node announces the external IP address for a service to the host network.
From a network perspective, the node appears to have multiple IP addresses assigned to a network interface.
speaker pod responds to ARP requests for IPv4 services and NDP requests for IPv6.
In layer 2 mode, all traffic for a service IP address is routed through one node. After traffic enters the node, the service proxy for the CNI network provider distributes the traffic to all the pods for the service.
Because all traffic for a service enters through a single node in layer 2 mode, in a strict sense, MetalLB does not implement a load balancer for layer 2.
Rather, MetalLB implements a failover mechanism for layer 2 so that when a
speaker pod becomes unavailable, a
speaker pod on a different node can announce the service IP address.
When a node becomes unavailable, failover is automatic.
speaker pods on the other nodes detect that a node is unavailable and a new
speaker pod and node take ownership of the service IP address from the failed node.