Learn MetalLB - History, Background & Why You Need MetalLB

#Introduction

Before you install MetalLB, it's worth understanding where this project comes from and what problem it truly solves. Episode 1 dissects the history, background, and reasons why MetalLB is needed — while also comparing it with other approaches that were commonly used before.

The name "MetalLB" itself is short for Metal Load Balancer. The name already explains its mission: to be a load balancer for Kubernetes clusters running on metal — physical servers or VMs that don't enjoy the automatic load balancer facilities of a cloud provider.

Understanding this history isn't just trivia. When you have to choose between MetalLB, kube-vip, or plain NodePort, the reasoning behind that decision actually comes from understanding the problem we discuss in this episode.

#The Beginning: Born from Bare-Metal Cluster Needs

#2017: The Project at Google Cloud

MetalLB was first created at Google Cloud in 2017 by David Anderson, a software engineer who saw a big gap in the Kubernetes ecosystem. At the time, Kubernetes was growing in popularity, but its support for external networking (load balancers) was only mature on big cloud providers like AWS, GCP, and Azure.

Clusters running on-premise, in labs, or in your own data centers had to manage load balancers manually. David Anderson wrote MetalLB as an open-source solution, then in 2018 the project was donated to the CNCF (Cloud Native Computing Foundation) and grew into a project adopted across thousands of clusters.

#The Version Journey to 2026

MetalLB's evolution can be seen through its major releases:

• 2019: the first public release, stable for production.
• 2020-2023: the v0.12 and v0.13 series introduced the use of FRR for the BGP implementation and established CRDs as the primary configuration method.
• 2024: v0.14 introduced CRD v1beta2 as the default.
• 2025: v0.15 refined features and observability.
• 2026: v0.16.x became the latest stable release — v0.16.0 and v0.16.1 were released in May 2026, and v0.15 officially entered end of life the same month.

#The Problem Without a Load Balancer

To feel the problem firsthand, create a Service of type LoadBalancer on a cluster without MetalLB:

kubectl get svc nginx

The EXTERNAL-IP column will show <pending> forever. kubectl get svc nginx will never finish assigning an IP because there's no cloud provider present to fill that role.

#From Google to the CNCF

After becoming an open-source project, MetalLB was donated to the CNCF in 2018. The consequences were significant: the project was no longer controlled by a single vendor, but managed by a community with open governance processes. This vendor neutrality is one of the reasons MetalLB is so widely used — teams don't worry about being locked into one company.

Adoption also grew through standardization: almost every serious on-premise Kubernetes distribution includes MetalLB as an installation option, and its documentation has become the primary reference for providing LoadBalancer services in environments without a cloud.

#The Problems MetalLB Solves

#Two Main Tasks

MetalLB solves two problems that are generally the responsibility of a cloud-native load balancer:

• IP Assignment: giving each LoadBalancer Service an external IP from a pool you define, taking the place of a cloud provider.
• Announcement: announcing that IP to the network outside the cluster so external traffic can reach the Service.

For the second task, MetalLB provides the two modes we touched on in episode 0: Layer 2, which uses ARP/NDP, and BGP, which peers with routers.

#A Simple Analogy

Think of a LoadBalancer Service like a phone number that must be published in a directory. A cloud provider supplies the number and runs the advertising automatically. On bare-metal, nobody does either — you have to set up the "directory" yourself. MetalLB is that directory: it holds the list of numbers (the IP pool) and announces them to the network (L2/BGP advertisement).

#MetalLB vs Other Approaches

#Cloud Load Balancers

On AWS, GCP, and Azure, type: LoadBalancer immediately triggers the creation of an ELB/ALB or a regional load balancer. The problem: this mechanism isn't available for clusters outside those clouds. MetalLB doesn't replace cloud load balancers — it fills the gap in environments that don't have one.

#NodePort

NodePort can expose a Service on a specific port on every node. But it has limitations: the port must be a specific number, one Service is hard to distinguish from another, and there's no dedicated IP per Service. externalTrafficPolicy: Local helps, but it's still not a real LoadBalancer replacement.

#kube-vip

kube-vip is an alternative approach that uses the VRRP protocol to provide a VIP (virtual IP) on a node. The concept is different: kube-vip generally provides one VIP per component (for example, for the control plane), whereas MetalLB manages a broad IP pool for many LoadBalancer Services. A deeper comparison will come in episode 22.

kubectl get svc nginx
kubectl apply -f ipaddresspool.yaml
kubectl get svc nginx

The first line shows EXTERNAL-IP <pending>, and after MetalLB is configured, the last line shows the actual external IP. That's the transformation you'll prove yourself starting in episode 3.

#Evolution and Today's Status

#An Active CNCF Project

As of the writing of this series, MetalLB holds Incubating status at the CNCF, with an active community and regular releases. The official documentation at metallb.io, the GitHub repository metallb/metallb, and the release notes are the sources of truth we'll reference throughout this series.

#Why It's Still Relevant in 2026

Amid the proliferation of networking solutions like Cilium, Calico, or managed on-premise Kubernetes services, the question "is MetalLB still needed?" often comes up. The answer: yes, because MetalLB solves one very specific problem — providing external IPs for LoadBalancer Services — in a way that's simple, proven, and runs on almost any cluster regardless of its CNI.

It's also worth noting that many advanced CNI solutions do offer their own load balancer features. But those choices usually lock you into a single CNI vendor. MetalLB, on the other hand, is an independent layer: it can be installed on top of Cilium, Calico, Flannel, or any other CNI without changing how your existing networking works. That flexibility is what keeps MetalLB relevant in a constantly changing landscape.

#Conclusion

Episode 1 gives you the context: MetalLB was born from the needs of bare-metal clusters that lacked a cloud-native load balancer, grew from a project at Google Cloud into a CNCF project, and today sits at the stable v0.16.x release.

Key takeaways:

• MetalLB was created by David Anderson at Google Cloud in 2017, then became a CNCF project.
• Its two main tasks: assigning external IPs and announcing those IPs to the network.
• Without MetalLB, a LoadBalancer Service will show EXTERNAL-IP <pending> forever.
• Cloud LB, NodePort, and kube-vip are different approaches with their own trade-offs.
• v0.16.x is the current stable release; v0.15 has been end of life since May 2026.

In the next episode, episode 2, we'll discuss MetalLB's core concepts and main architecture — how the controller allocates IPs, how the speaker announces IPs on each node, and the role of the four main CRDs that will accompany you throughout this series. Understanding the architecture will make all subsequent configuration far more sensible.