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.
