LoadBalancer Services on Bare Metal with MetalLB

Services and Networking / Guide 63 of 103 / Intermediate

• Kubernetes1.36.4
• Cluster4 nodes
• Runtimecontainerd 2.2.6
• CNICalico v3.32.1
• TimeAbout 40 min

L2 mode, which needs only a free range on the node subnet. BGP mode needs a router that will peer, and behaves quite differently.

• MetalLBv0.15.2
• ModeL2Advertisement

This guide includes

Use this when a LoadBalancer Service sits at Pending forever off-cloud. This matters because nothing in Kubernetes implements that type - and installing MetalLB is not sufficient on its own, which is the part that catches people out.

• creating a LoadBalancer Service with no cloud provider and watching it stay Pending
• installing MetalLB as a controller plus a speaker on every node, and finding the Service still Pending - which is exactly the point
• adding an address pool and an L2 advertisement, and watching the address finally appear
• confirming it answers, and working out which node is answering for it
• seeing four allocation behaviours - sequential, requested, refused and exhausted

Before you start

• The Services guide, particularly the ClusterIP, NodePort and LoadBalancer types.
• A free range of addresses on the node subnet, outside any DHCP scope.
• Layer 2 reachability between the nodes, which L2 mode requires.

1. 1

   The Pending that never resolves

2. 2

   Install MetalLB: a controller and a speaker on every node

3. 3

   Installed and still Pending, which is the point

4. 4

   A pool and an advertisement, and the address appears

5. 5

   It answers, and one node is answering for it

6. 6

   Allocation: sequential, requested, refused, exhausted

Official sources

• MetalLB documentation
• MetalLB L2 mode concepts
• Service type LoadBalancer
• Preserving the client source IP
• Cloud controller manager