Kubernetes-Workloads mit L4 und L7 skalierbar verteilen

TL;DR

Kubernetes Loadbalancing endet nicht am Service-Objekt des Clusters. Für öffentlich erreichbare Anwendungen müssen IP-Verteilung, TLS, Routing, Schutzfunktionen und Backend-Auswahl außerhalb des Clusters zusammenspielen. Eine providerunabhängige Edge-Integration trennt diese Aufgaben vom Clusterbetrieb und unterstützt L4- sowie L7-Szenarien für Services, APIs und Ingress-Architekturen .

Einleitung

Ein Kubernetes-Service kann einen Workload intern erreichbar machen, löst aber nicht automatisch die Anforderungen eines öffentlichen Endpunkts. Externer Traffic benötigt einen stabilen Eingang, eine belastbare Verteilung auf Backends und klare Zuständigkeiten für TLS, Routing und Ausfallsituationen. Häufig wird diese Funktion vollständig an den jeweiligen Kubernetes-Provider oder an einen einzelnen Cluster gebunden. Das vereinfacht den Einstieg, erschwert jedoch spätere Providerwechsel, Multi-Cluster-Architekturen und die zentrale Steuerung sicherheitsrelevanter Funktionen. Kubernetes Loadbalancing sollte deshalb als Zusammenspiel aus Cluster-internem Routing und einer vorgelagerten Edge betrachtet werden. L4 und L7 erfüllen dabei unterschiedliche Aufgaben und müssen passend zum Protokoll und zur Anwendung eingesetzt werden.

1. L4 und L7 adressieren unterschiedliche Verkehrsebenen

L4 Loadbalancing arbeitet auf Transportebene. Verbindungen werden anhand von IP-Adressen und Ports verteilt, ohne den Inhalt der Anwendung auszuwerten. Das eignet sich für TCP- oder UDP-basierte Services, Datenbanken mit öffentlichem Zugriffskonzept, proprietäre Protokolle oder TLS-Verbindungen, die erst im Backend terminiert werden. Die Edge muss in diesen Fällen keine HTTP-Struktur verstehen, sondern Verbindungen zuverlässig an erreichbare Backends weiterleiten.

L7 Loadbalancing arbeitet dagegen auf Anwendungsebene. Bei HTTP- und HTTPS-Services kann nach Hostnamen, Pfaden oder weiteren Request-Eigenschaften geroutet werden. Dadurch lassen sich beispielsweise mehrere APIs und Webanwendungen über eine gemeinsame öffentliche Adresse verteilen. TLS Termination an der Edge entlastet Backends und zentralisiert Zertifikats- und Verbindungslogik. Die Wahl zwischen L4 und L7 ist daher keine reine Produktentscheidung: Sie bestimmt, wo Protokollverständnis, Verschlüsselung und Routingregeln betrieben werden.

2. Kubernetes Ingress braucht einen stabilen öffentlichen Eingang

Kubernetes Ingress beschreibt Regeln für HTTP- und HTTPS-Routing, ist aber selbst kein vollständiger globaler Eingangspunkt. Die konkrete Umsetzung hängt vom verwendeten Ingress-Controller, der Netzwerkanbindung und dem Clusterbetrieb ab. Bei einem L7-Szenario kann die ayedo Edge Cloud den öffentlichen Traffic annehmen, TLS terminieren und Requests anhand definierter Routinginformationen an Kubernetes-Backends weiterleiten. Der Ingress bleibt dabei Teil der Anwendungsarchitektur, während die Edge den vorgelagerten Zugang und die Verteilung übernimmt.

Für reine TCP- oder UDP-Services ist ein Ingress ungeeignet. Hier wird der Service über L4 erreichbar gemacht und auf entsprechende Backend-Endpunkte verteilt. Diese Trennung verhindert, dass ein HTTP-Konzept auf nicht passende Protokolle übertragen wird. Gleichzeitig bleibt der Cluster austauschbar: Die Backends können aus ayedo Managed Kubernetes , einem selbst betriebenen Cluster oder einem Kubernetes-Cluster bei einem anderen Provider stammen.

3. Providerunabhängigkeit reduziert architektonische Kopplung

Wird der öffentliche Zugang ausschließlich über den Mechanismus eines Clusterproviders realisiert, liegen DNS, externe IPs, TLS, Routing und Ausfallverhalten häufig eng an diesem Betrieb. Ein Wechsel des Providers oder die Ergänzung eines zweiten Clusters wird dann zu einer Migrationsaufgabe für den öffentlichen Traffic. Eine separate Edge-Schicht entkoppelt diese Funktionen vom Lebenszyklus einzelner Kubernetes-Cluster.

Die ayedo Edge Cloud nutzt dafür Anycast-basiertes Layer-4- und Layer-7-Loadbalancing, Anycast DNS sowie Multi-Provider-DNS. Backend Cloaking verhindert, dass die eigentlichen Backend-Adressen direkt als öffentlicher Zugang dienen. Health Checks und Failover ermöglichen, nicht erreichbare Backends aus der Verteilung zu nehmen. Das ist besonders relevant für Multi-Cluster- oder hybride Szenarien: Routing und Schutzfunktionen bleiben an der Edge zentral steuerbar, während Workloads zwischen Clustern oder Providern verschoben werden können. Die Edge wird damit zum stabilen Vertrag gegenüber Clients, nicht der einzelne Cluster.

4. Skalierung umfasst Traffic, Workloads und Betrieb

Eine Edge kann eingehende Verbindungen und Requests verteilen, ersetzt aber keine Kubernetes-Mechanismen zur Skalierung von Pods. Horizontal Pod Autoscaling, Rollouts und interne Service-Discovery bleiben Aufgaben des Clusters. Die Edge muss dagegen erkennen, welche Backends erreichbar sind und wohin öffentlicher Traffic weitergeleitet werden darf. Proxy Protocol kann dabei notwendige Informationen zur ursprünglichen Verbindung an kompatible Backends übergeben.

Für den Betrieb ist entscheidend, diese Ebenen getrennt zu beobachten. Traffic- und Usage-Statistiken an der Edge zeigen die Entwicklung des öffentlichen Zugangs; Kubernetes-Metriken zeigen Pod-Auslastung, Replica-Anzahl und interne Fehler. DDoS Protection, Web Application Firewall und TLS Termination gehören zur vorgelagerten Schutz- und Verarbeitungsschicht, nicht zur Pod-Logik. Durch eine verteilte Multi-PoP-Architektur, eigenes Autonomous System und ein Aktiv-Aktiv-Prinzip wird der öffentliche Eingang außerdem unabhängig von der Verfügbarkeit eines einzelnen Clusterstandorts betrachtet.

Praxis- und Architekturszenario

Ein Unternehmen betreibt eine Webanwendung und mehrere APIs in zwei Kubernetes-Clustern bei unterschiedlichen Providern. HTTP- und HTTPS-Anfragen werden an der Edge per L7 nach Hostname und Pfad verteilt. Ein TCP-basierter Service erhält einen separaten L4-Endpunkt. Beide Cluster bleiben für ihre internen Services, Deployments und Autoscaling-Regeln verantwortlich.

Fällt ein Backend aus, entfernen Health Checks dieses aus der aktiven Verteilung. Die öffentlichen DNS- und Routingstrukturen müssen dabei nicht an den jeweiligen Provider angepasst werden. Alternativ könnte jeder Cluster seinen eigenen externen Einstieg betreiben. Das würde jedoch Konfigurationen für TLS, Schutz, Monitoring und Failover mehrfach verteilen und den Providerwechsel stärker in den öffentlichen Betrieb hineinziehen.

FAQ

Ist Kubernetes Ingress dasselbe wie L7 Loadbalancing?

Nein. Ingress definiert typischerweise HTTP- und HTTPS-Routing im Kubernetes-Kontext. L7 Loadbalancing ist die übergeordnete Anwendungsebene, auf der Requests analysiert und verteilt werden.

Wann ist L4 Loadbalancing die bessere Wahl?

Wenn TCP oder UDP transportiert werden soll, der Traffic nicht HTTP-basiert ist oder die TLS-Terminierung bewusst im Backend verbleiben muss. L4 benötigt kein Verständnis der Anwendungsinhalte.

Muss Kubernetes bei ayedo betrieben werden?

Nein. Die ayedo Edge Cloud kann auch vor eigenen Kubernetes-Clustern oder Clustern anderer Provider eingesetzt werden. Die Edge-Funktionen bleiben damit vom gewählten Compute-Betrieb getrennt.

Fazit

Kubernetes Loadbalancing sollte nicht auf die Frage reduziert werden, welcher Service einen Port öffnet. L4 und L7 bilden unterschiedliche Integrationspfade für Protokolle, APIs und Ingress-Architekturen . Eine providerunabhängige Edge trennt öffentlichen Zugang, Schutz und Routing vom eigentlichen Clusterbetrieb. Die ayedo Edge Cloud unterstützt diese Trennung mit Anycast-Verteilung, DNS, Backend-Health-Checks und Failover für Kubernetes-Workloads unabhängig vom gewählten Provider.