MetalLB

What MetalLB Does in a Bare-Metal Cluster

MetalLB solves a practical gap in Kubernetes deployments that do not sit behind a cloud provider’s managed load balancer. It gives Services a stable external address and makes that address reachable on the local network, so the cluster can present applications to users and upstream systems in a way that looks and behaves like a conventional load balancer.

That matters because bare-metal clusters still need a clear ingress path, but they do not get cloud-native networking conveniences automatically. MetalLB becomes part of the cluster’s exposure model, not just a convenience layer, because it determines how traffic enters the environment and which endpoints are publicly or internally reachable.

How MetalLB Advertises Reachability

MetalLB can announce addresses in two main ways. In layer 2 mode, one node answers for the Service IP on the local subnet, which is simple to operate but relies on the surrounding network treating that announcement as authoritative. In BGP mode, MetalLB advertises routes to upstream routers, which is more scalable and better aligned with routed environments, but it also requires coordination with network infrastructure and routing policy.

Those two modes are operationally different even though the user-facing result is similar. Layer 2 is often easier to introduce, while BGP is usually the better fit when organisations want predictable routing, multi-node resilience, or tighter integration with existing network design. The choice affects failure handling, observability, and how much trust the network places in the cluster.

Why External Service IPs Change the Security Model

Assigning external IPs to Kubernetes Services widens the attack surface from inside-the-cluster traffic to network-reachable traffic. That does not make MetalLB inherently unsafe, but it does mean Service exposure, namespace boundaries, NetworkPolicies, and application authentication all matter more because the load balancer can make a workload reachable from places the cluster operator may not fully control.

For teams used to cloud load balancers, the important shift is that the “front door” is now an internal responsibility. The load balancer announces reachability, but it does not replace access control, segmentation, or service hardening. A misconfigured Service or permissive upstream network path can expose workloads directly to hostile traffic just as effectively as any other externally exposed endpoint.

Operational Trade-offs and Failure Modes

MetalLB is lightweight and pragmatic, but its reliability depends on the surrounding network behaving as expected. In layer 2 mode, a bad announcement, node failure, or switching issue can interrupt reachability or create asymmetric paths. In BGP mode, route filtering, peer loss, or inconsistent policy can make services unreachable or send traffic to the wrong place. These are availability and correctness problems as much as they are deployment problems.

Because MetalLB sits at the boundary between Kubernetes and the network, troubleshooting usually requires checking both sides: Service state inside the cluster and advertisement state outside it. Teams should expect failures to present as partial reachability, intermittent traffic loss, or traffic reaching a node that is no longer the intended endpoint.

Risk and Threat Considerations

MetalLB can create meaningful exposure if address advertisement, routing policy, or Service configuration is wrong. An externally reachable Service that was meant to stay internal becomes a direct access path, and a compromised or misbehaving cluster node can affect how traffic is steered across the network.

Failure mechanism: The cluster advertises a Service IP through layer 2 or BGP, but the surrounding network trusts that advertisement without sufficient validation, so reachability and traffic steering depend on configuration correctness and node integrity.

Impact: Attackers or accidental misconfiguration can expose unintended services, disrupt availability, or divert traffic in ways that are hard to distinguish from ordinary routing behaviour.

Practitioner Guidance

Governance implication: Treat MetalLB as part of your network-exposure control plane, not just a Kubernetes add-on. The decision to use layer 2 or BGP should be owned jointly by platform and network teams because it changes who can influence service reachability and how failures are contained.

What to watch for: Review which Services are assigned external addresses, validate that advertisement scope matches the intended audience, and monitor for routing drift or unexpected exposure after cluster changes. In practice, MetalLB works best when its network announcements are deliberately bounded by segmentation and policy rather than assumed safe by default.