MetalLB vs. kube-vip: load balancing on bare metal

Timo Wevelsiep•Updated: 23.07.2026

Editorial note: Versions, commands and prices may change. Please verify critical steps independently before production use. This guide does not replace individual consulting.

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.

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.

Rather have it operated?

You'd rather not run Kubernetes yourself? WZ-IT handles setup, operations and maintenance - GDPR-compliant from Germany.

Managed Kubernetes →

Frequently Asked Questions

Answers to the most important questions

Kubernetes ships no load balancer implementation for bare-metal clusters. In the cloud the provider automatically delivers an external IP for services of type LoadBalancer; on bare metal, without an additional solution, only NodePort or the now-deprecated externalIPs remain. MetalLB and kube-vip fill exactly this gap and assign external IPs for services on your own network.

MetalLB solves service load balancing only: it assigns external IPs to services of type LoadBalancer. kube-vip can additionally - and originally above all - provide a virtual IP for the control plane, that is a highly available endpoint for the API server of a multi-master cluster. kube-vip thus covers two tasks, MetalLB one.

Yes, that is a common pattern: kube-vip provides the virtual IP for the control plane (high availability of the API server), MetalLB handles load balancing for application services. Alternatively kube-vip can take on both roles. The choice depends on whether you primarily need control-plane HA, service LB or both.

In Layer 2 mode (ARP/NDP) a single node answers requests for an IP; if it fails, another takes over. That is simple, but the throughput of one IP hangs on a single node. In BGP mode the nodes announce the IPs via a routing protocol, enabling true multipath routing across several nodes - more capable, but it requires BGP-capable network infrastructure.

No, they sit beneath them. MetalLB and kube-vip assign the external IP for a service of type LoadBalancer - on that foundation the Ingress or Gateway API controller then runs. On bare metal you therefore set up load balancing cleanly first and the HTTP routing on top.

externalIPs was long used as a poor man's load balancer, but was marked deprecated with Kubernetes 1.36 due to a security issue (CVE-2020-8554). Anyone still relying on it should put the load-balancing foundation cleanly on type: LoadBalancer with MetalLB or kube-vip.