MetalLB vs. kube-vip: LoadBalancing auf Bare Metal

Timo Wevelsiep•Aktualisiert: 23.07.2026

Hinweis zum Inhalt: Versionen, Befehle und Preise können sich ändern. Bitte prüfen Sie kritische Schritte vor dem produktiven Einsatz eigenständig. Dieser Leitfaden ersetzt keine individuelle Beratung.

Bare-Metal-Cluster sauber ans Netz bringen lassen? WZ-IT plant und betreibt Kubernetes-Netzwerke: LoadBalancing, Control-Plane-HA, Ingress und Gateway API, DNS und TLS - auf Proxmox, Bare Metal und europäischer Infrastruktur. Netzwerk & Secure Access ansehen

In der Cloud ist LoadBalancing selbstverständlich: Ein Service vom Typ LoadBalancer bekommt automatisch eine externe IP. Auf Bare Metal und Proxmox fehlt genau das - Kubernetes bringt dafür keine Implementierung mit. Zwei Projekte füllen die Lücke: MetalLB und kube-vip. Sie überschneiden sich, lösen aber unterschiedliche Kernprobleme. Dieser Vergleich ordnet beide ein und beantwortet die Frage: wann welches. Stand Juli 2026.

Inhaltsverzeichnis

Warum Bare Metal kein LoadBalancing kennt
MetalLB: LoadBalancer für Services
kube-vip: VIP für Control Plane und Services
Die beiden im Vergleich
L2 oder BGP
Welche Lösung wann

Warum Bare Metal kein LoadBalancing kennt

Der Kern des Problems steht in der MetalLB-Dokumentation: „Kubernetes does not offer an implementation of network load balancers for bare-metal clusters." In der Cloud liefern AWS, Azure oder GCP diese Implementierung mit - ein type: LoadBalancer-Service bekommt sofort eine externe IP. Auf Bare Metal bleibt ohne Zusatzlösung nur NodePort oder das inzwischen abgekündigte externalIPs.

Genau hier setzen MetalLB und kube-vip an. Beide vergeben externe IPs im eigenen Netz, damit Services „einfach funktionieren", wie in der Cloud. Der Unterschied liegt darin, welche Aufgabe sie primär lösen.

MetalLB: LoadBalancer für Services

MetalLB ist die etablierte LoadBalancer-Implementierung für Bare-Metal-Cluster. Es vergibt externe IPv4-/IPv6-Adressen aus einem konfigurierten Pool an Services vom Typ LoadBalancer und integriert sich dabei mit Standard-Netzwerktechnik. Das Projekt hat CNCF-Sandbox-Status.

MetalLB löst damit genau eine Aufgabe, und die gut: das LoadBalancing von Anwendungs-Services. Es kennt zwei Betriebsarten - Layer 2 und BGP (mit FRR-K8s als Standard-Backend) -, die weiter unten verglichen werden. Was MetalLB nicht tut: Es stellt keine virtuelle IP für die Control Plane bereit. Für die Hochverfügbarkeit des API-Servers braucht es eine andere Lösung.

kube-vip: VIP für Control Plane und Services

kube-vip verfolgt einen breiteren Ansatz. Laut kube-vip-Dokumentation liefert es „a virtual IP and load balancer for both the control plane (for building a highly-available cluster) and Kubernetes Services of type LoadBalancer" - ganz ohne externe Hardware oder Software.

Der ursprüngliche und wichtigste Anwendungsfall ist die virtuelle IP für die Control Plane: In einem Multi-Master-Cluster braucht der API-Server einen einzigen, hochverfügbaren Endpunkt. kube-vip stellt diese VIP bereit und schwenkt sie beim Ausfall eines Knotens um. Darüber hinaus kann kube-vip auch das Service-LoadBalancing übernehmen und deckt so beide Aufgaben in einem Werkzeug ab. Wie MetalLB unterstützt es ARP (Layer 2) und BGP, zusätzlich Routing-Table- und WireGuard-Modi.

Die beiden im Vergleich

Dimension	MetalLB	kube-vip
Control-Plane-VIP (HA)	Nein	Ja (Kern-Anwendungsfall)
Service-LoadBalancer	Ja (Kern-Anwendungsfall)	Ja
Modi	Layer 2, BGP	ARP (L2), BGP, Routing-Table, WireGuard
Externe Hardware	Nicht nötig	Nicht nötig
Reifegrad	CNCF Sandbox, weit verbreitet	Weit verbreitet, oft in kubeadm-Setups
Typische Rolle	Service-LB im Bare-Metal-Cluster	Control-Plane-HA, optional auch Service-LB

L2 oder BGP

Unabhängig vom Werkzeug stellt sich die Frage nach dem Modus. Im Layer-2-Modus (ARP/NDP) beantwortet ein einzelner Knoten die Anfragen für eine IP; fällt er aus, übernimmt ein anderer. Das ist einfach einzurichten und funktioniert in jedem Netz - aber der Durchsatz einer einzelnen IP hängt an einem Knoten, es gibt kein echtes Lastverteilen über mehrere.

Im BGP-Modus kündigen die Knoten die IPs per Routing-Protokoll an die Netzwerk-Infrastruktur an. Damit wird echtes Multipath-Routing (ECMP) über mehrere Knoten möglich - leistungsfähiger und ausfallsicherer, aber es setzt BGP-fähige Switches oder Router voraus. Die Faustregel: L2 für einfache Setups und Homelabs, BGP für Rechenzentren mit passender Netzwerk-Infrastruktur.

Welche Lösung wann

Die Kurzfassung richtet sich nach dem Problem, das zuerst drückt:

kube-vip, wenn Sie Control-Plane-Hochverfügbarkeit brauchen - der Multi-Master-Cluster braucht eine VIP für den API-Server. Das ist die Aufgabe, die MetalLB nicht löst.
MetalLB, wenn Sie ein ausgereiftes, weit verbreitetes Service-LoadBalancing wollen und die Control-Plane-HA anderweitig (etwa über kube-vip) abgedeckt ist.
Beides zusammen ist ein gängiges, sauberes Muster: kube-vip für die Control-Plane-VIP, MetalLB für die Anwendungs-Services. Alternativ übernimmt kube-vip beide Rollen.

Wichtig: LoadBalancing ist das Fundament, nicht das HTTP-Routing. Auf der externen IP läuft anschließend der Ingress- oder Gateway-API-Controller. Wer bisher externalIPs als Behelf nutzt, sollte das Fundament vorher sauber auf type: LoadBalancer stellen - externalIPs wurde wegen CVE-2020-8554 mit Kubernetes 1.36 als deprecated markiert. Wie darüber das moderne HTTP-Routing aufgebaut wird, zeigt Gateway API vs. Ingress.

Lieber betreiben lassen?

Sie möchten Kubernetes nicht selbst betreiben? WZ-IT übernimmt Einrichtung, Betrieb und Wartung - DSGVO-konform aus Deutschland.

Managed Kubernetes →

Häufig gestellte Fragen

Antworten auf die wichtigsten Fragen

Kubernetes bringt für Bare-Metal-Cluster keine LoadBalancer-Implementierung mit. In der Cloud liefert der Anbieter automatisch eine externe IP für Services vom Typ LoadBalancer; auf Bare Metal bleibt ohne Zusatzlösung nur NodePort oder das inzwischen abgekündigte externalIPs. MetalLB und kube-vip füllen genau diese Lücke und vergeben externe IPs für Services im eigenen Netz.

MetalLB löst ausschließlich das Service-LoadBalancing: Es vergibt externe IPs an Services vom Typ LoadBalancer. kube-vip kann zusätzlich - und ursprünglich vor allem - eine virtuelle IP für die Control Plane bereitstellen, also einen hochverfügbaren Endpunkt für den API-Server eines Multi-Master-Clusters. kube-vip deckt damit zwei Aufgaben ab, MetalLB eine.

Ja, das ist ein gängiges Muster: kube-vip stellt die virtuelle IP für die Control Plane bereit (Hochverfügbarkeit des API-Servers), MetalLB übernimmt das LoadBalancing der Anwendungs-Services. Alternativ kann kube-vip beide Rollen übernehmen. Die Wahl hängt davon ab, ob Sie primär Control-Plane-HA, Service-LB oder beides brauchen.

Im Layer-2-Modus (ARP/NDP) beantwortet ein einzelner Knoten die Anfragen für eine IP; fällt er aus, übernimmt ein anderer. Das ist einfach, aber der Durchsatz einer IP hängt an einem Knoten. Im BGP-Modus kündigen die Knoten die IPs per Routing-Protokoll an, sodass echtes Multipath-Routing über mehrere Knoten möglich ist - leistungsfähiger, erfordert aber BGP-fähige Netzwerk-Infrastruktur.

Nein, sie liegen darunter. MetalLB und kube-vip vergeben die externe IP für einen Service vom Typ LoadBalancer - auf diesem Fundament läuft dann der Ingress- oder Gateway-API-Controller. Auf Bare Metal setzt man also zuerst das LoadBalancing sauber auf und darüber das HTTP-Routing.

externalIPs galt lange als Poor Man's Load Balancer, wurde aber wegen einer Sicherheitslücke (CVE-2020-8554) mit Kubernetes 1.36 als deprecated markiert. Wer bisher darauf setzt, sollte das LoadBalancing-Fundament sauber auf type: LoadBalancer mit MetalLB oder kube-vip stellen.