The bare-metal LoadBalancer problem

Ask Kubernetes for a Service of type LoadBalancer in the cloud and you get a real load balancer with a real IP, because the cloud provider has a controller watching for exactly that. On bare metal — a home lab — nobody's listening. The service just sits there forever in <pending>, never getting an external IP.

MetalLB is the missing piece. It's the controller that notices LoadBalancer services and hands them an IP from a pool you define, then makes the rest of the network actually route to that IP.

Service (type: LoadBalancer)
   |
   v
MetalLB   --assigns-->  10.100.100.100   (from the pool)
   |
   +-- announces that IP on the LAN so traffic finds the right node

Why we use this: it makes a bare-metal cluster behave like a cloud one for the part that matters — type: LoadBalancer just works. That means manifests written against MetalLB look the same as manifests for EKS/GKE, which is good for learning and good for portability.