MetalLB

What it is

MetalLB is a load-balancer implementation for bare-metal Kubernetes clusters. If you're not running on AWS, GCP, or Azure, Service type: LoadBalancer does nothing by default — there's no cloud controller to provision an external IP. MetalLB fills that gap using two modes: Layer 2 (ARP/NDP-based failover, simple but no real load balancing) and BGP (advertises service IPs to your network's routers, gets you actual multi-node load balancing and failover). It's the de facto answer to "how do I get LoadBalancer services on-prem or on bare metal" without buying an F5 or building your own.

Who builds it and why

MetalLB started as a project by Google engineer Dave Anderson, born out of the same frustration every bare-metal K8s operator hits: cloud-native manifests assume cloud-native infrastructure. It's now a CNCF Sandbox project with 242 contributors and an active commit history (last commit July 2026), which is a healthy signal for a project at this maturity level. There's no single vendor behind it — it's community-driven, which is both a strength (no vendor lock-in, no upsell pressure) and a risk (no one obligated to keep the lights on).

Production readiness signal

8,254 GitHub stars and 242 contributors is a solid, mature user base for a Sandbox-tier project — most Sandbox projects don't get this level of real-world adoption. Continuous commits through 2026 indicate it's actively maintained, not abandoned. That said, CNCF Sandbox status means it hasn't gone through the graduation rigor of Incubating or Graduated projects — no CNCF-mandated security audits, no governance guarantees. In practice, MetalLB has been running in production bare-metal clusters for years (on-prem shops, edge deployments, homelab-to-enterprise) and is considered stable for its core use case. Check the changelog before upgrading across major versions — BGP mode config has had breaking changes historically.

Who should use this

• Teams running Kubernetes on bare metal or in on-prem data centers with no cloud LB available.
• Edge and telco deployments where nodes sit outside any cloud provider's network fabric.
• Homelab/dev clusters (k3s, kubeadm) that want LoadBalancer semantics without hacking NodePort + external DNS.
• Shops with existing BGP-capable routers who want real load distribution, not just failover.

Who should NOT use this

• If you're running on AWS, GCP, or Azure — use the native cloud load balancer integration. MetalLB adds complexity for a problem you don't have.
• Environments without any BGP-capable router and no tolerance for L2 mode's failover-only limitations (L2 mode funnels all traffic through a single node — it's not a load balancer in the traffic-distribution sense).
• Teams needing L7 features (path-based routing, TLS termination, WAF) — MetalLB is L2/L3 only. Pair it with an Ingress controller or use something like Traefik/Envoy standalone instead.
• Regulated environments requiring vendor support contracts and SLAs — Sandbox status means community support only, no commercial backstop unless you find a consultancy that supports it.

Alternatives

• kube-vip — similar bare-metal LB/VIP tool, also handles control-plane HA, lighter footprint.
• Cilium (with BGP control plane) — if you're already running Cilium as CNI, its LB IP + BGP features can replace MetalLB and reduce your component count.
• Cloud provider LB integrations (AWS ALB/NLB, GCP LB, Azure LB) — not an alternative for bare metal, but the obvious choice if you're actually in the cloud.

Pricing

Fully open source, Apache-2.0 licensed. No paid tier, no enterprise edition, no vendor. Cost is your own operational overhead — running and troubleshooting it yourself.