Kubernetes ist nicht Ihr Load Balancer — es ist der Puppenspieler, der die Fäden zieht

Kubernetes ist nicht Ihr Load Balancer — es ist der Puppenspieler, der die Fäden zieht

Es gibt einen Moment, den jeder Netzwerk-Engineer erlebt, wenn er in Kubernetes eintaucht.

Sie haben Jahre damit verbracht, Hardware-Load-Balancer zu tunen. Sie kennen den Rhythmus: Client → Load Balancer → Server. TLS-Terminierung? Kein Problem. Sticky Sessions? Erledigt. 200.000 gleichzeitige TCP-Sitzungen? Immer her damit.

Dann taucht Kubernetes auf, und plötzlich explodiert das Vokabular.

Services. Ingress. API Gateways. Cloud-Load-Balancer. Service Meshes. NodePort. LoadBalancer-Typ. MetalLB. Cilium.

Es fühlt sich an, als hätte jemand ein makellos sauberes Diagramm genommen und Abstraktionen darüber verschüttet.

Was passiert also tatsächlich in der Produktion?

Brechen wir die Illusion.

Kubernetes ersetzt Ihren Load Balancer nicht

Eine der meistgevoteten Antworten in der Diskussion bringt es direkt auf den Punkt:

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

Das ist die Pointe.

Kubernetes ist nicht Ihr F5. Es terminiert nicht auf magische Weise TLS aus dem Nichts. Es verwaltet nicht heimlich 200.000 TCP-Sitzungen in einer Black Box.

Es orchestriert.

Es konfiguriert.

Es weist etwas anderes an, die schwere Arbeit zu übernehmen.

Dieses „etwas anderes" hängt vollständig von Ihrer Umgebung ab.

In Cloud-Setups löst ein Service vom Typ LoadBalancer den Cloud-Controller aus, automatisch einen externen Load Balancer bereitzustellen. In On-Prem- oder Bare-Metal-Umgebungen verwenden Sie vielleicht MetalLB, um Service-IPs über BGP oder ARP anzukündigen. Oder Sie lassen Cilium BGP und die L2/L3-Verteilung übernehmen.

Aber Kubernetes selbst?

Es ist die Control Plane. Das Arbeitstier für den Traffic lebt woanders.

Das ist der entscheidende Perspektivwechsel.

Ingress ist (technisch gesehen) kein Load Balancer

Das hat im Thread ein paar Leute ins Stolpern gebracht, und es lohnt sich, hier langsamer vorzugehen.

Eine Ingress-Ressource ist kein Load Balancer. Sie ist ein Regelwerk. Ein Konfigurationsobjekt.

Die eigentliche Muskelkraft steckt im Ingress-Controller – vielleicht NGINX, vielleicht Traefik, vielleicht HAProxy –, der innerhalb des Clusters läuft.

Ein Engineer erklärte es schlicht: Eine Ingress-Ressource für ingress-nginx wird in eine nginx.conf-Datei übersetzt. Diese Konfiguration übernimmt dann das Routing.

Das bedeutet:

Kubernetes definiert die Absicht.

Der Controller übersetzt sie in eine echte Proxy-Konfiguration.

Der Proxy übernimmt das eigentliche Load Balancing.

Abstraktion auf Abstraktion gestapelt.

Das klingt zunächst chaotisch. Aber sobald man erkennt, dass es einfach Konfigurationsautomatisierung ist, macht es klick.

Wo terminiert TLS also tatsächlich?

Hier fangen Produktions-Setups an, sich zu unterscheiden.

Es gibt nicht die eine „richtige" Antwort. Es gibt Muster.

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

Ein externer Hardware- oder Cloud-Load-Balancer terminiert TLS.

Warum?

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

Mehrere Engineers im Thread bevorzugen das. Lassen Sie das schwere Eisen (oder den Cloud-LB) TLS übernehmen. Halten Sie den Cluster auf das Anwendungs-Routing fokussiert.

Manche Setups verschlüsseln den Traffic sogar erneut, bevor er in den Cluster geht – TLS-Terminierung am Edge, dann eine zweite TLS-Sitzung zum Ingress, gefolgt von mTLS innerhalb des Clusters.

Geschichtete Sicherheit. Saubere Trennung der Verantwortlichkeiten.

Muster 2: Terminierung am Ingress-Controller

Statt es an den Cloud-LB auszulagern, konfigurieren Sie das Zertifikatsmanagement direkt in Kubernetes.

Annotationen an einer Ingress-Ressource können die Zertifikatsbereitstellung über Tools wie cert-manager auslösen. Der Ingress-Controller übernimmt die TLS-Terminierung selbst.

Das funktioniert gut bei:

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

Das vereinfacht die externe Infrastruktur. Aber jetzt muss Ihre Ingress-Schicht entsprechend skalieren.

Muster 3: Auslagerung an ein Service Mesh

Hier wird es interessant.

Mit Istio kann TLS am Gateway oder sogar per Sidecar-Injection in Workloads gehandhabt werden.

Das Mesh kann mTLS zwischen Services automatisch erzwingen.

Das ist mächtig. Es ist aber auch operativ aufwendig.

Das führt man nicht einfach mal so nebenbei ein. Man führt es ein, 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?

Hier kommt der Teil, der die Netzwerk-Engineers im Raum beruhigt:

Wenn Sie vorne einen Hardware-Load-Balancer oder Cloud-LB einsetzen, ist die Performance-Geschichte exakt dieselbe wie schon immer.

Kubernetes macht TCP nicht plötzlich schwächer.

Es verwendet unter der Haube denselben Linux-Netzwerk-Stack, auf den sich viele „traditionelle" Load Balancer ohnehin verlassen.

Ein Kommentator, der schon HPC-Cluster gebaut hat, lange bevor Kubernetes existierte, brachte es unverblümt auf den Punkt:

Es ist derselbe Netzwerk-Stack. Nur anders automatisiert.

Wenn Sie softwarebasiertes Ingress innerhalb des Clusters betreiben, wird Skalierung horizontal.

Mehr Ingress-Pods.

Mehr Nodes.

Mehr Endpoints.

Autoscaler springen an. L2/L3-Balancing verteilt den Traffic. Ab diesem Punkt ist es Kapazitätsplanung, keine Magie.

Kubernetes zählt die Sitzungen nicht selbst. Es delegiert diese Verantwortung an die Infrastrukturschicht, die das Balancing übernimmt.

Bei Bare Metal wird es interessant

Die Cloud macht die Dinge einfach.

Bare Metal? Da kommt die Kreativität ins Spiel.

Manche Engineers betreiben MetalLB mit BGP und kündigen Service-IPs direkt an ihre Router an. Einer erwähnte, es mit einem MikroTik RB5009 zu kombinieren, der die BGP-Routen übernimmt.

Andere betreiben einen klassischen Reverse Proxy außerhalb des Clusters – vielleicht Traefik oder HAProxy – und leiten den Traffic an NodePort-Services innerhalb von Kubernetes weiter.

Und ja, manche integrieren immer noch echte Hardware-Load-Balancer, wobei Kubernetes die Konfiguration dynamisch verwaltet, während die Infra-Teams die Kontrolle über die physischen Geräte behalten.

Dieses Hybridmodell ist verbreiteter, als die Leute zugeben.

Infra verwaltet die Hardware.

App-Teams verwalten die Routing-Regeln.

Jeder bleibt in seiner Spur.

Das echte Produktionsmuster

Entfernt man die Terminologie, sehen die meisten realen Architekturen so aus:

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

Das war's.

Alles andere ist Implementierungsdetail.

Manchmal wird der externe LB cloud-verwaltet.

Manchmal ist es F5 oder Citrix.

Manchmal ist es MetalLB, das VIPs über BGP ankündigt.

Aber Kubernetes sitzt in der Mitte und koordiniert, wie der Traffic fließen soll, sobald er die Cluster-Grenze überschreitet.

Es eliminiert Load Balancer nicht.

Es industrialisiert deren Konfiguration.

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 definieren.

Das ist ebenso sehr ein kultureller wie ein technischer Wandel.

Sie konfigurieren nicht mehr von Hand virtuelle Server auf einem Hardware-Gerät.

Sie schreiben YAML.

Und dieses YAML löst Automatisierung aus, die etwas anderes konfiguriert.

Diese Indirektion kann sich unangenehm anfühlen, wenn man es gewohnt ist, jeden Regler direkt zu sehen.

Aber sie ist mächtig.

Denn jetzt gilt:

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

Und am wichtigsten: Fehlkonfigurationen sind reproduzierbar und versioniert.

Vereinfacht oder verkompliziert Kubernetes Load Balancing?

Ehrlich gesagt?

Beides.

Es vereinfacht die Bereitstellung.

Es verkompliziert das mentale Modell.

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

Aber darunter gelten dieselben Prinzipien:

Layer 4 vs. Layer 7

TLS-Terminierungspunkte

Session-Handling

Health Checks

Routing-Logik

Der Unterschied ist, wer was verwaltet – und wie automatisiert es ist.

Die brutale Wahrheit über Kubernetes-Networking in der Produktion

Kubernetes ersetzt traditionelle Load Balancer nicht auf magische Weise.

Es standardisiert, wie man mit ihnen kommuniziert.

Wenn Sie massiven Durchsatz und hohe TCP-Nebenläufigkeit brauchen, verlassen Sie sich immer noch auf bewährte Infrastruktur – ob das nun Cloud-native LBs, Hardware-Appliances oder Hochleistungs-Software-Proxys sind.

Kubernetes sorgt nur 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

Es erfindet Networking nicht neu.

Es orchestriert es.

Und sobald man aufhört zu erwarten, dass es der Load Balancer ist – und stattdessen anfängt, es als das Automatisierungsgehirn im Hintergrund zu sehen –, ergibt alles Sinn.

Der alte Flow existiert immer noch.

Er hat jetzt einfach eine Control Plane.