Before touching MetalLB, you need to master Kubernetes Services, basic Linux networking (ARP and BGP), as well as the kubectl, helm, and ip CLIs. This episode guides you through preparing a bare-metal cluster, installing kubectl and helm, and planning an IP block for external IPs.

Welcome to the Learn MetalLB series! This series will take you through mastering MetalLB — the CNCF project that provides LoadBalancer Services for Kubernetes clusters running on bare-metal or on-premise — from conceptual foundations all the way to production readiness. There are 23 episodes in total, arranged into six phases.
In the cloud, services like AWS ELB or GCP Load Balancer appear the moment you create a Service of type LoadBalancer. On an on-premise cluster, no such service exists. That is where MetalLB steps in: it assigns an external IP from a pool you define, then announces that IP to the network via Layer 2 (ARP/NDP) or BGP.
Before getting started, there are several foundational skills and software tools you must prepare. Episode 0 is your roadmap: we'll make sure the foundational skills are in place, set up the cluster and tooling, and plan the IP block that will be used throughout the series.
MetalLB works at the Service level, so you need to understand these three Service types:
Also get into the habit of reading the output of kubectl get svc and kubectl describe svc — these two commands will be your main troubleshooting tools in episodes 7 and 19.
kubectl get svc -AIf the output is still empty, that's fine. What matters is that you understand how to read the TYPE, CLUSTER-IP, EXTERNAL-IP, and PORT(S) columns once there is data.
MetalLB announces IPs through two mechanisms, and both require basic understanding:
You don't need to become a network engineer first, but you should be comfortable reading ip addr and ip route output, as well as the concepts of ASN and peering. A simple analogy: ARP is like asking "who owns this IP?" on a single network, while BGP is like telling other routers "the path to this IP is here".
Three main CLIs will be used constantly:
kubectl to manage Kubernetes resources.helm to install MetalLB via its chart.ip and arping to inspect the network when troubleshooting.kubectl get nodes should become your first habit, because every operation in this series starts with making sure the cluster is healthy.
MetalLB needs a Kubernetes cluster running in an environment where you can control the network — kubeadm, k3s, or kind all work. For development, kind is the lightest option:
brew install kind
kind create cluster --name metallb-lab
kubectl get nodesThe kubectl get nodes output should show nodes with status Ready. Important note: for BGP mode (episode 6) and failover testing (episode 15), a multi-node topology is much better than a single node. The kind create cluster --name metallb-lab command above creates a single-node cluster, which is enough to follow the early episodes.
Make sure your kubectl minor version isn't too far behind your cluster version:
kubectl version --client
helm versionhelm version displays the Helm 3 version, which is required because the MetalLB chart only supports Helm 3. If your version is still Helm 2, migrate first.
This is the prerequisite that's most often forgotten. MetalLB assigns IPs from a pool you define, and those IPs must genuinely be unused on your network. The easiest way: choose an IP range on your LAN subnet that isn't announced by DHCP, for example 192.168.1.200 through 192.168.1.250 on the 192.168.1.0/24 subnet.
ip addr show dev eth0
arping -c 3 192.168.1.200arping -c 3 192.168.1.200 sends three ARP requests. If there's no reply, that IP appears to be unused. Repeat for a few IPs in your chosen range.
Before moving on to episode 1, make sure everything is ready with a single set of verification commands:
kubectl version
kubectl get nodes
helm version
ip addr showAll four commands above should run without errors. The cluster should report Ready, kubectl and helm should be installed, and you should have a list of IPs that can be used for the pool.
Info
Write down your chosen IP block somewhere. Starting from episode 3, this block will become your first IPAddressPool, and every hands-on episode in this series will use it over and over.
Here's a recap of the prerequisites you've prepared in episode 0:
ip and arping.Ready.If anything is still missing, complete it before continuing. A strong foundation will make the next 22 episodes feel far lighter.
In episode 0 you've laid the groundwork for the entire series: understanding Kubernetes Services and basic networking, setting up the cluster and CLI tooling, and choosing the IP block that will become your pool.
Key takeaways:
ip, and arping are the main CLIs throughout the series.Ready nodes before installing MetalLB.In the next episode, episode 1, we'll discuss the history, background, and why you need MetalLB — from the project's birth at Google Cloud in 2017, the problem of bare-metal clusters without a cloud-native load balancer, to early comparisons with kube-vip and NodePort. Make sure your environment is ready, because the Learn MetalLB journey has just begun!