Kubernetes als Puppenspieler: Wie es Load Balancer steuert, ohne selbst einer zu sein

Jeder Netzwerk-Engineer, der sich in Kubernetes einarbeitet, erlebt irgendwann denselben Moment.

Sie haben jahrelang Hardware-Load-Balancer getunt und kennen den Ablauf: Client → Load Balancer → Server. TLS-Terminierung ist kein Problem, Sticky Sessions sind erledigt, und 200.000 gleichzeitige TCP-Sitzungen nehmen Sie gern mit.

Dann kommt Kubernetes, und plötzlich explodiert das Vokabular mit Services, Ingress, API Gateways, Cloud-Load-Balancern, Service Meshes, NodePort, dem LoadBalancer-Typ, MetalLB und Cilium. Es fühlt sich an, als hätte jemand über ein makellos sauberes Diagramm einen Eimer Abstraktionen gekippt. Was passiert davon in der Produktion wirklich?

Kubernetes ersetzt Ihren Load Balancer nicht

Eine der meistgevoteten Antworten in der Diskussion kommt direkt zur Sache:

„Nein, es steuert nur Load Balancer … Kubernetes wird nicht mit einem Load Balancer geliefert."

Kubernetes ist also nicht Ihr F5. Es terminiert TLS nicht auf magische Weise aus dem Nichts und verwaltet auch nicht heimlich 200.000 TCP-Sitzungen in einer Black Box. Es orchestriert und konfiguriert und weist eine andere Komponente an, die schwere Arbeit zu erledigen.

Welche Komponente das ist, hängt ganz von Ihrer Umgebung ab. In Cloud-Setups veranlasst ein Service vom Typ LoadBalancer den Cloud-Controller, automatisch einen externen Load Balancer bereitzustellen. On-Prem oder auf Bare Metal kündigen Sie Service-IPs vielleicht mit MetalLB über BGP oder ARP an, oder Sie überlassen Cilium BGP und die L2/L3-Verteilung.

Kubernetes selbst ist dabei die Control Plane, und das Arbeitstier für den Traffic sitzt woanders. Wer das einmal verstanden hat, sieht das ganze Thema mit anderen Augen.

Ingress ist (technisch gesehen) kein Load Balancer

Daran sind im Thread einige gestolpert, deshalb lohnt es sich, hier langsamer zu machen.

Eine Ingress-Ressource ist ein Regelwerk, also ein Konfigurationsobjekt. Die eigentliche Arbeit macht der Ingress-Controller, der im Cluster läuft, etwa NGINX, Traefik oder HAProxy.

Ein Engineer erklärte es ganz schlicht: Eine Ingress-Ressource für ingress-nginx wird in eine nginx.conf-Datei übersetzt, und diese Konfiguration übernimmt dann das Routing. Kubernetes definiert die Absicht, der Controller übersetzt sie in eine echte Proxy-Konfiguration, und der Proxy macht das eigentliche Load Balancing.

Das sind Abstraktionen auf Abstraktionen, und anfangs wirkt das chaotisch. Sobald man es als Konfigurationsautomatisierung begreift, macht es aber klick.

Wo terminiert TLS also tatsächlich?

An dieser Stelle gehen Produktions-Setups auseinander. Eine einzige „richtige" Antwort gibt es nicht, wohl aber wiederkehrende Muster.

Muster 1: Terminierung am Edge (am häufigsten)

Ein externer Hardware- oder Cloud-Load-Balancer terminiert TLS. Das hat mehrere Vorteile:

• Sie können WAF-Prüfungen am Edge durchführen
• Sie reduzieren interne SSL-Handshakes
• Die Zertifikatsverwaltung ist zentralisiert

Mehrere Engineers im Thread bevorzugen diesen Weg. Das schwere Eisen oder der Cloud-LB kümmert sich um TLS, und der Cluster konzentriert sich auf das Routing der Anwendungen.

Manche Setups verschlüsseln den Traffic sogar erneut, bevor er in den Cluster geht. TLS endet dann am Edge, eine zweite TLS-Sitzung läuft bis zum Ingress, und im Cluster folgt mTLS. Das ergibt Sicherheit in mehreren Schichten und eine saubere Trennung der Zuständigkeiten.

Muster 2: Terminierung am Ingress-Controller

Statt TLS an den Cloud-LB auszulagern, konfigurieren Sie das Zertifikatsmanagement direkt in Kubernetes. Annotationen an einer Ingress-Ressource können über Tools wie cert-manager die Bereitstellung von Zertifikaten auslösen, und der Ingress-Controller terminiert TLS selbst.

Das passt gut zu:

• Cloud-nativen Setups
• Kleineren Clustern
• Teams, die volle Kontrolle innerhalb von Kubernetes wollen

Die externe Infrastruktur wird dadurch einfacher, dafür muss Ihre Ingress-Schicht jetzt entsprechend mitskalieren.

Muster 3: Auslagerung an ein Service Mesh

Mit Istio kann TLS am Gateway oder sogar per Sidecar-Injection direkt in den Workloads behandelt werden, und das Mesh erzwingt mTLS zwischen Services automatisch.

Das ist mächtig, im Betrieb aber auch aufwendig. Einführen sollte man es, wenn man Service-zu-Service-Verschlüsselung, Traffic Shaping, Observability und Policy-Kontrolle im großen Maßstab braucht.

Was ist mit 200.000 TCP-Sitzungen?

Dieser Teil dürfte die Netzwerk-Engineers beruhigen. Steht vorne ein Hardware-Load-Balancer oder Cloud-LB, sieht die Performance genauso aus wie immer. Kubernetes macht TCP nicht schwächer, denn es nutzt unter der Haube denselben Linux-Netzwerk-Stack, auf den sich viele „traditionelle" Load Balancer ohnehin stützen.

Ein Kommentator, der schon HPC-Cluster gebaut hat, lange bevor es Kubernetes gab, sagte es unverblümt: Es ist derselbe Netzwerk-Stack, nur anders automatisiert.

Betreiben Sie softwarebasiertes Ingress im Cluster, skalieren Sie horizontal mit mehr Ingress-Pods, mehr Nodes und mehr Endpoints. Autoscaler springen an, und L2/L3-Balancing verteilt den Traffic. Ab da ist das Kapazitätsplanung und keine Magie. Das Zählen der Sitzungen überlässt Kubernetes der Infrastrukturschicht, die das Balancing erledigt.

Bei Bare Metal wird es interessant

In der Cloud ist vieles einfach, auf Bare Metal ist mehr Kreativität gefragt.

Manche Engineers betreiben MetalLB mit BGP und kündigen Service-IPs direkt an ihre Router an. Einer erwähnte, dass bei ihm ein MikroTik RB5009 die BGP-Routen übernimmt. Andere betreiben einen klassischen Reverse Proxy außerhalb des Clusters, etwa Traefik oder HAProxy, und leiten den Traffic an NodePort-Services in Kubernetes weiter.

Und ja, manche binden immer noch echte Hardware-Load-Balancer ein. Kubernetes verwaltet dann die Konfiguration dynamisch, während die Infra-Teams die Kontrolle über die physischen Geräte behalten. Dieses Hybridmodell ist verbreiteter, als viele zugeben: Infra kümmert sich um die Hardware, die App-Teams um die Routing-Regeln, und jeder bleibt in seiner Spur.

Das echte Produktionsmuster

Ohne die ganze Terminologie sehen die meisten realen Architekturen so aus:

Client → externer Load Balancer → Ingress-Controller → Service → Pods

Alles andere ist Implementierungsdetail. Mal ist der externe LB cloud-verwaltet, mal ist es F5 oder Citrix, mal MetalLB, das VIPs über BGP ankündigt. Kubernetes sitzt in der Mitte und koordiniert, wie der Traffic fließt, sobald er die Cluster-Grenze überschreitet. Die Load Balancer bleiben also, nur ihre Konfiguration wird industrialisiert.

Warum sich das so anders anfühlt

In traditionellen Umgebungen haben Netzwerk-Teams den gesamten Traffic-Flow gebaut und verwaltet. In Kubernetes-Umgebungen können Anwendungs-Teams Routing-Regeln deklarativ festlegen, und dieser Wandel ist genauso kulturell wie technisch.

Statt virtuelle Server auf einem Hardware-Gerät von Hand zu konfigurieren, schreiben Sie YAML, und dieses YAML stößt eine Automatisierung an, die wiederum etwas anderes konfiguriert. Wer gewohnt ist, jeden Regler direkt vor sich zu sehen, findet diese Indirektion anfangs unangenehm.

Sie hat aber handfeste Vorteile:

• Entwickler können Services ausliefern, ohne beim Netzwerk-Team ein Ticket aufzumachen
• Infrastruktur kann Guardrails erzwingen
• Skalierung wird API-gesteuert

Am wichtigsten ist, dass Fehlkonfigurationen reproduzierbar und versioniert sind.

Vereinfacht oder verkompliziert Kubernetes Load Balancing?

Beides. Die Bereitstellung wird einfacher, das mentale Modell komplizierter. Statt einer Box mit der Aufschrift „Load Balancer" haben Sie jetzt:

• Service-Objekte
• Ingress-Ressourcen
• Ingress-Controller
• Cloud-Controller-Manager
• Optionale Service Meshes
• Optionale In-Cluster-L2/L3-Load-Balancer

Darunter gelten dieselben Prinzipien wie früher: Layer 4 vs. Layer 7, die Punkte der TLS-Terminierung, Session-Handling, Health Checks und Routing-Logik. Neu ist, wer was verwaltet und wie weit das automatisiert ist.

Kubernetes-Networking in der Produktion

Kubernetes standardisiert, wie man mit traditionellen Load Balancern spricht. Auf magische Weise ersetzt es sie nicht. Wer massiven Durchsatz und viele gleichzeitige TCP-Verbindungen braucht, verlässt sich weiter auf bewährte Infrastruktur, seien es Cloud-native LBs, Hardware-Appliances oder schnelle Software-Proxys.

Kubernetes sorgt dafür, dass:

• Sie konsistent konfiguriert sind
• Sie automatisch bereitgestellt werden
• Sie deklarativen Regeln folgen
• Entwickler globale Traffic-Muster nicht versehentlich kaputt machen können

Kubernetes orchestriert das Networking, die Grundlagen bleiben dieselben. Sobald man es als Automatisierungsgehirn im Hintergrund betrachtet und nicht mehr erwartet, dass es selbst der Load Balancer ist, ergibt alles Sinn. Der alte Flow existiert weiter, er hat jetzt nur eine Control Plane.