Have your bare-metal cluster connected to the network cleanly? WZ-IT plans and operates Kubernetes networks: load balancing, control-plane HA, Ingress and Gateway API, DNS and TLS - on Proxmox, bare metal and European infrastructure. See Network & Secure Access
In the cloud, load balancing is a given: a service of type LoadBalancer automatically gets an external IP. On bare metal and Proxmox exactly that is missing - Kubernetes ships no implementation for it. Two projects fill the gap: MetalLB and kube-vip. They overlap but solve different core problems. This comparison places both and answers the question: when to use which. As of July 2026.
Table of contents
- Why bare metal has no load balancing
- MetalLB: LoadBalancer for services
- kube-vip: VIP for control plane and services
- The two compared
- L2 or BGP
- Which solution when
Why bare metal has no load balancing
The core of the problem is stated in the MetalLB documentation: "Kubernetes does not offer an implementation of network load balancers for bare-metal clusters." In the cloud, AWS, Azure or GCP ship this implementation - a type: LoadBalancer service immediately gets an external IP. On bare metal, without an additional solution, only NodePort or the now-deprecated externalIPs remain.
This is exactly where MetalLB and kube-vip come in. Both assign external IPs on your own network so that services "just work" as in the cloud. The difference lies in which task they primarily solve.
MetalLB: LoadBalancer for services
MetalLB is the established load balancer implementation for bare-metal clusters. It assigns external IPv4/IPv6 addresses from a configured pool to services of type LoadBalancer and integrates with standard network equipment in doing so. The project holds CNCF sandbox status.
MetalLB thus solves exactly one task, and does it well: load balancing for application services. It knows two modes - Layer 2 and BGP (with FRR-K8s as the default backend) - compared further below. What MetalLB does not do: it provides no virtual IP for the control plane. For high availability of the API server, another solution is needed.
kube-vip: VIP for control plane and services
kube-vip takes a broader approach. According to the kube-vip documentation it delivers "a virtual IP and load balancer for both the control plane (for building a highly-available cluster) and Kubernetes Services of type LoadBalancer" - without any external hardware or software.
The original and most important use case is the virtual IP for the control plane: in a multi-master cluster the API server needs a single, highly available endpoint. kube-vip provides this VIP and moves it over when a node fails. Beyond that, kube-vip can also handle service load balancing and thus covers both tasks in one tool. Like MetalLB it supports ARP (Layer 2) and BGP, plus routing-table and WireGuard modes.
The two compared
| Dimension | MetalLB | kube-vip |
|---|---|---|
| Control-plane VIP (HA) | No | Yes (core use case) |
| Service load balancer | Yes (core use case) | Yes |
| Modes | Layer 2, BGP | ARP (L2), BGP, routing table, WireGuard |
| External hardware | Not required | Not required |
| Maturity | CNCF sandbox, widely used | Widely used, often in kubeadm setups |
| Typical role | Service LB in bare-metal clusters | Control-plane HA, optionally service LB too |
L2 or BGP
Independent of the tool, the question of the mode arises. In Layer 2 mode (ARP/NDP) a single node answers requests for an IP; if it fails, another takes over. That is simple to set up and works on any network - but the throughput of a single IP hangs on one node, there is no true load spreading across several.
In BGP mode the nodes announce the IPs via a routing protocol to the network infrastructure. This enables true multipath routing (ECMP) across several nodes - more capable and more resilient, but it requires BGP-capable switches or routers. The rule of thumb: L2 for simple setups and homelabs, BGP for data centers with matching network infrastructure.
Which solution when
The short version follows the problem that presses first:
- kube-vip when you need control-plane high availability - the multi-master cluster needs a VIP for the API server. That is the task MetalLB does not solve.
- MetalLB when you want a mature, widely used service load balancing and control-plane HA is covered elsewhere (for example via kube-vip).
- Both together is a common, clean pattern: kube-vip for the control-plane VIP, MetalLB for the application services. Alternatively kube-vip takes on both roles.
Important: load balancing is the foundation, not the HTTP routing. On the external IP the Ingress or Gateway API controller then runs. Anyone still using externalIPs as a stopgap should put the foundation cleanly on type: LoadBalancer first - externalIPs was marked deprecated with Kubernetes 1.36 due to CVE-2020-8554. How the modern HTTP routing is built on top is shown in Gateway API vs. Ingress.
