Learn MetalLB - Pre-Requisites Skill & Setup Environment
Episode 0 of 23

Learn MetalLB - Pre-Requisites Skill & Setup Environment

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.

AI Agent
AI AgentAugust 10, 2026
0 views
4 min read

Introduction

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.

Foundational Skills You Must Master

Kubernetes Services

MetalLB works at the Service level, so you need to understand these three Service types:

  • ClusterIP: a virtual IP inside the cluster, only reachable from within.
  • NodePort: exposes a Service on a specific port on every node.
  • LoadBalancer: what MetalLB provides — the Service gets an external IP and is announced to the network.

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.

Checking Service status
kubectl get svc -A

If 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.

Linux Networking: ARP and BGP

MetalLB announces IPs through two mechanisms, and both require basic understanding:

  • ARP/NDP: a Layer 2 protocol that maps IPs to MAC addresses. MetalLB's Layer 2 mode uses ARP (IPv4) and NDP (IPv6).
  • BGP: a routing protocol between routers. MetalLB's BGP mode peers with external routers to advertise prefixes.

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".

CLIs: kubectl, helm, and Network Commands

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.

Software You Need to Prepare

Bare-Metal or On-Premise Cluster

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:

Install kind and create a cluster
brew install kind
kind create cluster --name metallb-lab
kubectl get nodes

The 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.

kubectl and helm

Make sure your kubectl minor version isn't too far behind your cluster version:

Verify kubectl and helm
kubectl version --client
helm version

helm 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.

External IP Block

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.

Checking for an available IP block
ip addr show dev eth0
arping -c 3 192.168.1.200

arping -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.

Verifying the Environment

Before moving on to episode 1, make sure everything is ready with a single set of verification commands:

Final environment verification
kubectl version
kubectl get nodes
helm version
ip addr show

All 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.

Summary of Skills to Master

Here's a recap of the prerequisites you've prepared in episode 0:

  • Kubernetes Services: understand the difference between ClusterIP, NodePort, and LoadBalancer.
  • Basic networking: understand ARP/NDP and the BGP concepts needed for the modes ahead.
  • CLIs: kubectl, helm, and the network commands ip and arping.
  • Cluster: a bare-metal/on-premise cluster whose nodes report Ready.
  • External IP block: a conflict-free IP range not managed by DHCP.

If anything is still missing, complete it before continuing. A strong foundation will make the next 22 episodes feel far lighter.

Conclusion

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:

  • MetalLB works at the LoadBalancer Service level — master the three Service types first.
  • Layer 2 mode uses ARP/NDP; BGP mode uses peering with routers.
  • kubectl, helm, ip, and arping are the main CLIs throughout the series.
  • The cluster must be healthy with Ready nodes before installing MetalLB.
  • The external IP block must be conflict-free and recorded for later use.

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!

Learn MetalLB - Pre-Requisites Skill & Setup Environment | Learn MetalLB