Kubernetes is designed to integrate with major cloud provider's load balancers to provide public IP addresses and direct traffic into a cluster. Kubernetes does not have a built-in network load-balancer implementation. A bare-metal cluster or really any cluster deployed outside a public cloud and lacking expensive professional hardware, needs another solution.
Some professional network equipment manufacturers also offer controllers to integrate their physical load-balancing products into Kubernetes installations in private data centers. However, this can be prohibitively expensive.
Load Balancer vs Ingress¶
While Kubernetes does support Ingress, it is limited to only HTTP or HTTPS traffic, while MetalLB can support any network traffic. In a nutshell, MetalLB provides resolution of an unassigned IP address to a particular cluster node and assigns that IP to a Service, while Ingress uses a specific IP address and internally routes HTTP or HTTPS traffic to a Service or Services based on routing rules.
MetalLB is a network load balancer and can expose cluster services on a dedicated IP address on the network, allowing external clients to connect to Kubernetes services inside the Kubernetes cluster. It performs this via either Layer 2 (data link) using Address Resolution Protocol (ARP) or Layer 3 (transport) using Border Gateway Protocol (BGP).
Instead of using a NodePort to expose services (not ideal for a production implementation), MetalLB offers a network load-balancer implementation that integrates with the networking equipment you already have in place. This makes it an ideal solution for bare-metal and VM based clusters in non-public cloud environments.
ARP vs BGP¶
MetalLB works via either ARP or BGP to resolve IP addresses to specific hosts. So, when a client attempts to connect to a specific IP, it will ask "which host has this IP?" and the response will point it to the correct host (i.e., the host's MAC address).
The request is broadcast to the entire network, and a host that knows which MAC address has that IP address responds to the request. In this case, MetalLB's response will direct the client to the correct node. Once the traffic has arrived at a host, Kubernetes takes over directing the traffic to the correct pods.
Each "peer" maintains a table of routing information directing clients to the host handling a particular IP for IPs and the hosts the peer knows about, and it advertises this information to its peers. When configured for BGP, MetalLB peers each of the nodes in the cluster with the network's router, allowing the router to direct clients to the correct host.
Consumer-grade routers do not generally support BGP. Even professional routers that do support BGP can be difficult to configure. ARP can be just as useful and requires no configuration on the network to work. It can also be considerably easier to implement. A simple ConfigMap to establish a peering session to a BGP peer is given below. For services that utilize DNS and require a static IP you can create multiple address pools and disable auto assignment to insure IPs are never dynamically allocated for a static pool.
apiVersion: v1 kind: ConfigMap metadata: namespace: metallb-system name: config data: config: | peers: - peer-address: 10.0.0.1 peer-asn: 64501 my-asn: 64500 address-pools: - name: dynamic-pool protocol: bgp addresses: - 192.168.10.0/25 auto-assign: true - name: static-pool protocol: bgp addresses: - 192.168.10.128/25 auto-assign: false