Loadbalancer-Provisionierung aus Kubernetes steuern

TL;DR

Kubernetes kann den gewünschten öffentlichen Dienstzustand deklarativ beschreiben, übernimmt aber nicht automatisch die gesamte Netzwerkbereitstellung. Eine Kubernetes-Integration verbindet Ressourcen wie Service mit einer Edge-Plattform, die öffentliche Erreichbarkeit, Routing und Schutz umsetzt. So bleiben Anwendung und Infrastruktur getrennt, während der Betriebsprozess automatisiert wird.

Einleitung

Ein häufiger Architekturfehler besteht darin, Kubernetes-Services und öffentliche Netzwerkplattform gleichzusetzen. Ein Service vom Typ LoadBalancer beschreibt zunächst einen gewünschten Zustand innerhalb des Kubernetes-Modells. Damit daraus ein erreichbarer öffentlicher Endpunkt entsteht, muss eine externe Komponente diese Absicht erkennen, adressieren und die erforderlichen Netzwerkfunktionen bereitstellen. Genau an dieser Stelle trennt sich die deklarative Steuerungsebene von der eigentlichen Edge-Infrastruktur. Für den Betrieb ist diese Trennung entscheidend: Kubernetes bleibt für Workloads und Service-Definitionen zuständig, während die Edge Cloud den öffentlichen Eingang, die Verteilung und den Schutz des Traffics übernimmt.

1. Kubernetes beschreibt den gewünschten Zustand

Kubernetes-Ressourcen sind deklarative Schnittstellen. Ein Team definiert beispielsweise einen Service, legt Ports fest und bestimmt je nach Architektur, ob dieser Dienst intern oder öffentlich erreichbar sein soll. Kubernetes versucht anschließend, den beschriebenen Zustand herzustellen und dauerhaft mit dem tatsächlichen Zustand abzugleichen.

Bei einem Service vom Typ LoadBalancer ist die Absicht klar: Für einen Dienst soll eine externe Erreichbarkeit hergestellt werden. Kubernetes selbst stellt dadurch jedoch nicht automatisch Anycast-Routing, DNS, DDoS-Schutz oder eine globale Traffic-Verteilung bereit. Diese Funktionen liegen außerhalb des Kubernetes-Kerns und benötigen eine Infrastruktur, die den Service-Zustand interpretieren kann.

Die automatische Provisionierung entsteht somit durch das Zusammenspiel mehrerer Komponenten. Eine Kubernetes-native Integration beobachtet relevante Ressourcen, leitet daraus Konfigurationsänderungen ab und übergibt diese an die öffentliche Netzwerkplattform. Änderungen an Ports, Backends oder dem gewünschten Veröffentlichungsstatus können dadurch in einen kontrollierten Bereitstellungsprozess einfließen. Kubernetes bleibt deklarative Quelle der Absicht; die Edge Cloud setzt diese Absicht im öffentlichen Netz um.

2. Die Edge Cloud übernimmt eine andere Verantwortung

Die Edge Cloud ist nicht lediglich ein weiterer Loadbalancer innerhalb des Clusters. Sie bildet den öffentlichen Eingang vor den Anwendungen und APIs. Dort wird eingehender Traffic angenommen, geprüft, geschützt und an geeignete Backends verteilt. Diese Aufgaben liegen bewusst außerhalb der Compute-Infrastruktur.

Für die Provisionierung bedeutet das: Kubernetes liefert Informationen über den bereitzustellenden Dienst und seine Backends. Die Edge Cloud stellt daraus einen öffentlichen Endpunkt her und übernimmt Funktionen wie Anycast-basiertes Layer-4- und Layer-7-Loadbalancing, TLS Termination, Web Application Firewall und DDoS Protection. Backend Health Checks und Failover tragen dazu bei, nicht verfügbare Ziele aus der Verteilung zu nehmen.

Diese Aufgabenteilung reduziert Kopplungen. Ein Cluster muss nicht selbst den gesamten öffentlichen Netzwerkzugang abbilden. Gleichzeitig kann die Edge Cloud vor ayedo Managed Kubernetes, eigenen Kubernetes-Clustern oder Clustern bei anderen Providern eingesetzt werden. Der öffentliche Zugang ist damit nicht an einen bestimmten Compute-Betrieb gebunden. Backend Cloaking kann zusätzlich verhindern, dass interne Zielstrukturen direkt als öffentliche Architektur sichtbar werden.

3. Vom Kubernetes-Service zum öffentlichen Endpunkt

Technisch beginnt der Ablauf mit einer Änderung am gewünschten Zustand: Ein Team legt einen Service an oder verändert dessen Konfiguration. Die Kubernetes-Integration erkennt diese Änderung und prüft, welche öffentliche Bereitstellung daraus entstehen soll. Dazu gehören unter anderem der zu veröffentlichende Port, das Protokoll und die verfügbaren Backends.

Anschließend wird die Edge-Konfiguration aktualisiert. Je nach Anforderung kann der Endpunkt auf Layer 4 oder Layer 7 arbeiten. Bei HTTP- und HTTPS-Diensten lassen sich zusätzlich TLS Termination und WAF-Funktionen an der Edge einordnen. Für die Weiterleitung zum Cluster können technische Mechanismen wie Proxy Protocol relevant sein, wenn der Backend-Dienst Informationen zur ursprünglichen Verbindung benötigt.

Wichtig ist die Rückkopplung in das Kubernetes-Modell. Ein erfolgreicher Bereitstellungsprozess muss den resultierenden Zustand nachvollziehbar machen, etwa durch die am Service sichtbare externe Erreichbarkeit. Fehler dürfen nicht als scheinbar erfolgreicher Zustand enden. Für Betrieb und Fehlersuche müssen deshalb Kubernetes-Ressource, Edge-Konfiguration, DNS-Auflösung und Backend-Gesundheit gemeinsam betrachtet werden. Automatisierung ersetzt keine Zustandskontrolle; sie macht diese erst skalierbar.

4. Deklarative Steuerung braucht klare Betriebsgrenzen

Die technische Automatisierung ist nur dann belastbar, wenn Zuständigkeiten eindeutig definiert sind. Kubernetes-Teams verantworten typischerweise Workloads, Services, Deployments und die gewünschte Veröffentlichung. Die Plattform- oder Netzwerkverantwortlichen definieren dagegen Richtlinien für öffentliche Endpunkte, Schutzfunktionen, Adressierung und Failover. Ohne diese Grenze können Änderungen an einer Kubernetes-Ressource unbeabsichtigt Auswirkungen auf den öffentlichen Netzbetrieb haben.

Auch Sicherheitsentscheidungen sollten nicht ausschließlich aus dem Cluster heraus getroffen werden. Ein öffentlich erreichbarer Service benötigt eine Bewertung von TLS, WAF-Regeln, DDoS-Schutz, Backend-Isolation und Monitoring. Die Edge Cloud bietet dafür eine zusammenhängende Plattform mit eigener Netzwerk-Infrastruktur, eigenem Autonomous System und verteilter Aktiv-Aktiv-Architektur. Diese Eigenschaften sind für die öffentliche Erreichbarkeit relevant, während Kubernetes weiterhin die Anwendungsebene beschreibt.

Wirtschaftlich reduziert eine gemeinsame Provisionierung den manuellen Abstimmungsaufwand zwischen Entwicklung, Plattformbetrieb und Netzwerkteam. Der größere Vorteil liegt jedoch in reproduzierbaren Änderungen und klaren Verantwortungsgrenzen. Ein Service wird nicht zu einem undokumentierten Sonderfall, sondern zu einem standardisierten Eingangspunkt in einem kontrollierten Bereitstellungsprozess.

Praxis- und Betriebsszenario

Ein Unternehmen betreibt einen Kubernetes-Service für eine API. Der Service soll öffentlich erreichbar sein, die Pods bleiben jedoch in privaten Cluster-Netzen. Das Team beschreibt den Service deklarativ in Kubernetes. Die Integration erzeugt daraus einen öffentlichen Endpunkt in der Edge Cloud, während Health Checks die verfügbaren Backends bestimmen.

Bei einer Skalierung der Anwendung verändert sich die Backend-Menge im Cluster. Die Edge-Konfiguration muss deshalb den aktuellen Zustand übernehmen, ohne dass ein Netzwerkadministrator manuell Regeln anpasst. Fällt ein Backend aus, kann die Edge Cloud es aus der Verteilung nehmen. Die Anwendung bleibt dabei unabhängig davon, ob der Cluster von ayedo, im eigenen Rechenzentrum oder bei einem anderen Provider betrieben wird. Kubernetes steuert den gewünschten Dienst; die Edge Cloud verantwortet dessen öffentlichen Netzwerkpfad.

FAQ

Ist ein Kubernetes-Service bereits ein öffentlicher Loadbalancer?

Nein. Ein Service beschreibt den gewünschten Zugriff auf Workloads. Die öffentliche Adresse, das Edge-Routing und Schutzfunktionen benötigen eine externe Loadbalancer- oder Edge-Plattform.

Muss der Kubernetes-Cluster bei ayedo betrieben werden?

Nein. Die Kubernetes-native Integration kann auch mit eigenen Clustern oder Kubernetes-Umgebungen anderer Provider genutzt werden. Die Edge Cloud und die Compute-Infrastruktur bleiben getrennte Verantwortungsbereiche.

Was passiert bei einer Änderung am Service?

Die Integration erkennt den neuen gewünschten Zustand und aktualisiert die zugehörige Edge-Bereitstellung. Für den Betrieb müssen anschließend Status, DNS, Routing und Backend-Gesundheit konsistent geprüft werden.

Fazit

Loadbalancer-Provisionierung aus Kubernetes ist kein einzelner Infrastrukturvorgang, sondern eine Kette aus deklarativer Service-Beschreibung, automatisierter Zustandsübernahme und öffentlicher Traffic-Verarbeitung. Kubernetes steuert, welcher Dienst veröffentlicht werden soll. Die ayedo Edge Cloud übernimmt den öffentlichen Netzwerkpfad, Schutz, Termination und Verteilung. Diese Trennung ermöglicht providerunabhängige Cluster-Architekturen, ohne den Netzwerkbetrieb von der Anwendungskonfiguration zu entkoppeln.