ScriptsApr 15, 2026·3 min read

MetalLB — Load Balancer Implementation for Bare-Metal Kubernetes

MetalLB is a network load-balancer implementation for bare-metal Kubernetes clusters using standard routing protocols (Layer 2 ARP/NDP or BGP). It lets Services of type LoadBalancer work on clusters that do not run on a cloud provider.

Script Depot
Script Depot · Community
TL;DR
Network load-balancer implementation for bare-metal Kubernetes using Layer 2 or BGP routing protocols.
§01

What it is

MetalLB is a load-balancer implementation for bare-metal Kubernetes clusters. In cloud environments, Services of type LoadBalancer are automatically provisioned by the cloud provider. On bare-metal clusters, this service type remains in a perpetual 'Pending' state because no external load balancer exists. MetalLB fills this gap by using standard routing protocols (Layer 2 ARP/NDP or BGP) to assign external IP addresses to Kubernetes Services.

This tool targets teams running Kubernetes on their own hardware, in colocation facilities, or on-premise data centers. Anyone who needs external traffic routing to Kubernetes Services without a cloud provider benefits from MetalLB.

§02

How it saves time or tokens

Without MetalLB, bare-metal Kubernetes operators must manually configure NodePort services, external HAProxy instances, or custom iptables rules. MetalLB automates this entirely: declare a Service of type LoadBalancer, and MetalLB assigns an IP and advertises it. This eliminates hours of manual network configuration per service.

§03

How to use

  1. Install MetalLB via kubectl apply or Helm into your cluster
  2. Configure an IP address pool that MetalLB can assign to Services
  3. Create a Service of type LoadBalancer; MetalLB assigns an IP automatically
§04

Example

# Install MetalLB
# kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.14.8/config/manifests/metallb-native.yaml

# Configure IP pool
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: production-pool
  namespace: metallb-system
spec:
  addresses:
    - 192.168.1.240-192.168.1.250
---
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: l2-advert
  namespace: metallb-system
§05

Related on TokRepo

§06

Common pitfalls

  • Layer 2 mode has a single-node failover limitation; only one node handles traffic for each IP at a time
  • BGP mode requires a compatible router and proper peering configuration; misconfigured BGP drops all traffic
  • IP address pools must not overlap with your DHCP range or other network allocations

Frequently Asked Questions

What is the difference between Layer 2 and BGP mode?+

Layer 2 mode uses ARP/NDP to announce IPs on the local network segment. It is simpler to set up but limits failover to one node per IP. BGP mode advertises routes to upstream routers, enabling true load distribution across nodes but requiring BGP-capable network gear.

Does MetalLB work with any Kubernetes distribution?+

Yes. MetalLB works with vanilla Kubernetes, k3s, kubeadm, RKE, and other distributions. It requires Kubernetes 1.13 or later and a cluster network that allows the chosen protocol (Layer 2 or BGP).

Can I use MetalLB in a home lab?+

Yes. Layer 2 mode is ideal for home labs because it needs no special network equipment. Just reserve a range of IPs on your local subnet and configure MetalLB to use them.

How does failover work in Layer 2 mode?+

One node holds the IP and responds to ARP requests. If that node goes down, another node takes over the IP. Failover typically takes a few seconds as ARP caches expire and refresh.

Is MetalLB production-ready?+

Yes. MetalLB is widely used in production bare-metal Kubernetes clusters. BGP mode is preferred for production because it offers better load distribution and faster failover than Layer 2 mode.

Citations (3)
Related on TokRepo
DevOps toolsSelf-hosted toolsFeatured workflows

Discussion

Sign in to join the discussion.
No comments yet. Be the first to share your thoughts.

Related Assets

Heimdall — Application Dashboard for Your Server

Heimdall is an elegant self-hosted application dashboard that organizes all your web services and apps into a single, customizable start page with enhanced tile features.

Script Depot

Healthchecks — Cron Job Monitoring with Smart Alerts

Healthchecks is a self-hosted cron job and scheduled task monitor that alerts you when your periodic jobs fail to run on time.

Script Depot

Shiori — Simple Self-Hosted Bookmark Manager

Shiori is a lightweight self-hosted bookmark manager written in Go with full-text search, archiving, and a clean web interface for organizing your saved links.

Script Depot
◈Home🔍Search👤Me