Kubernetes-DNS und externe Zonen sauber zusammendenken

TL;DR

Kubernetes-DNS und öffentliches DNS erfüllen unterschiedliche Aufgaben: Der Cluster löst interne Services auf, während externe Zonen den öffentlichen Einstieg in Anwendungen definieren. Eine klare Verantwortungsgrenze verhindert Fehlkonfigurationen, reduziert Abhängigkeiten vom Cluster-Provider und ermöglicht, DNS, Schutz und Traffic-Verteilung an einer Edge-Plattform zu bündeln.

Einleitung

Ein häufiger Architekturfehler besteht darin, interne Kubernetes Namen und öffentliche Anwendungsdomains als zwei Varianten desselben DNS-Problems zu behandeln. Service-Namen im Cluster dienen der Kommunikation zwischen Workloads. Öffentliche Domains müssen dagegen außerhalb des Clusters auf einen kontrollierten Eingang zeigen, der Traffic prüft, terminiert und an geeignete Backends weiterleitet. Werden beide Ebenen vermischt, entstehen unnötige Abhängigkeiten: DNS-Zonen liegen beim Clusteranbieter, externe Clients greifen direkt auf wechselnde Ingress-Endpunkte zu oder interne Services werden versehentlich öffentlich adressierbar. Eine belastbare Plattformarchitektur trennt deshalb Auflösung, Erreichbarkeit und Traffic-Verantwortung.

1. Kubernetes-DNS ist zunächst ein internes Kommunikationssystem

Kubernetes-DNS stellt Namen für Services und teilweise für Pods bereit. Anwendungen sprechen dadurch beispielsweise einen stabilen Servicenamen an, obwohl sich die dahinterliegenden Pods ändern. Diese Auflösung gehört zum Kubernetes-Netzwerk und bleibt innerhalb des Clusterkontexts. Sie beschreibt, wie Workloads einander erreichen, nicht wie externe Clients eine Anwendung finden.

Diese Trennung hat betriebliche Konsequenzen. Interne Service-Namen sollten nicht als öffentliche Schnittstellen verwendet werden, weil sie an die DNS-Domäne, Netzwerktopologie und Erreichbarkeit des Clusters gebunden sind. Auch ein Eintrag in einer externen Zone ersetzt keine interne Service-Auflösung: Er adressiert einen öffentlichen Namen und benötigt einen erreichbaren Eingang.

Für die Architektur bedeutet das: Der Cluster verantwortet die Namensauflösung für seine Workloads. Die Edge Cloud verantwortet den öffentlichen Eingang vor Anwendungen und APIs. Dort können DNS-Auflösung, TLS-Terminierung, Web Application Firewall, DDoS-Schutz und Lastverteilung zusammenwirken, ohne den internen Servicenamensraum offenzulegen.

2. Externe Zonen definieren den öffentlichen Eingang

Eine externe DNS-Zone sollte nicht einfach auf die jeweils sichtbare Adresse eines Kubernetes-Clusters zeigen. Sie definiert vielmehr einen stabilen öffentlichen Namen und verweist auf die Infrastruktur, die den Eingang kontrolliert. Das ist besonders relevant, wenn sich Cluster verschieben, mehrere Cluster parallel betrieben werden oder Backends nicht direkt aus dem Internet erreichbar sein sollen.

Bei einer Edge-Architektur zeigt die öffentliche Zone auf die Edge Cloud. Von dort wird der Traffic abhängig von Konfiguration und Backend-Zustand weitergeleitet. Health Checks und Failover können dabei berücksichtigen, ob ein Ziel tatsächlich verfügbar ist. Die DNS-Ebene verteilt also nicht automatisch den gesamten Anwendungsverkehr; sie macht den Eingang auffindbar. Die eigentliche Verarbeitung und Verteilung erfolgen anschließend an der Edge.

Anycast DNS und Multi-Provider-DNS können diese öffentliche Ebene von einem einzelnen Clusteranbieter entkoppeln. Das verändert die Zuständigkeit klar: DNS und öffentlicher Traffic-Eingang liegen außerhalb des Clusters, während Kubernetes weiterhin die internen Services und Workload-Endpunkte verwaltet. Backend Cloaking verhindert zusätzlich, dass die eigentlichen Cluster-Endpunkte als öffentliche Zieladressen dienen müssen.

3. Die Übergabe zwischen Cluster und Edge muss explizit sein

Technisch entscheidend ist die Übergabe zwischen beiden Plattformen. Der Cluster stellt einen oder mehrere erreichbare Backend-Endpunkte bereit. Die Edge Cloud kennt diese Ziele, prüft ihre Erreichbarkeit und übernimmt anschließend die Verarbeitung des eingehenden Traffics. Je nach Architektur können dabei Layer-4- oder Layer-7-Loadbalancing, TLS-Termination und Proxy Protocol relevant sein.

Diese Übergabe sollte nicht von zufälligen Providerkonventionen abhängen. Ein Kubernetes-Service, ein Ingress oder ein anderer exponierter Endpunkt kann die technische Verbindung zum Cluster bilden; die öffentliche Domain bleibt jedoch eine separate Verantwortungsebene. Änderungen an Deployments oder Pods müssen nicht automatisch Änderungen an der externen DNS-Zone auslösen.

Security und Betrieb profitieren von dieser Entkopplung. Öffentliche Regeln wie WAF-Policies und DDoS-Schutz werden an der Edge angewendet, bevor Anfragen das Kubernetes-Netzwerk erreichen. Im Cluster bleiben Routing und Service Discovery auf interne Anforderungen fokussiert. Fehler lassen sich dadurch besser zuordnen: Namensauflösung, Edge-Verarbeitung und Backend-Erreichbarkeit sind getrennte Prüfbereiche.

4. Providerunabhängigkeit ist eine Architekturentscheidung

Kubernetes-Cluster werden häufig über mehrere Umgebungen verteilt: in einem Managed-Service, in einer eigenen Infrastruktur oder bei unterschiedlichen Providern. Wenn externe DNS-Zonen und öffentliche Endpunkte eng an die Netzwerkressourcen eines einzelnen Clusters gekoppelt sind, wird ein Plattformwechsel unnötig aufwendig. DNS-Einträge, Zertifikatswege, Firewall-Regeln und Clientkonfigurationen müssen dann gemeinsam migriert werden.

Eine providerunabhängige Edge-Schicht stabilisiert den öffentlichen Vertrag. Clients verwenden weiterhin dieselben Domains, während sich die dahinterliegenden Kubernetes-Cluster ändern können. Das ist kein automatisches Multi-Cluster-Management; es ist eine klare Entkopplung von öffentlicher Erreichbarkeit und Compute-Ort.

Die ayedo Edge Cloud ist in diesem Modell nicht auf ayedo Managed Kubernetes beschränkt. Ihre Kubernetes-native Integration kann ebenso mit eigenen oder bei anderen Providern betriebenen Clustern genutzt werden. Eigene Netzwerk-Infrastruktur, ein eigenes Autonomous System und eine verteilte Aktiv-Aktiv-Architektur bilden dabei die Grundlage für eine Edge-Verantwortung, die unabhängig vom Standort der eigentlichen Workloads organisiert wird.

Praxis- und Betriebsszenario

Ein Unternehmen betreibt eine API in zwei Kubernetes-Clustern: einen Cluster bei einem Cloudprovider und einen weiteren in einer eigenen Infrastruktur. Intern verwenden die Workloads Kubernetes -DNS für die Kommunikation. Die öffentliche Domain api.example.com zeigt dagegen auf die ayedo Edge Cloud. Dort werden TLS und WAF verarbeitet, die Backend-Ziele per Health Check überwacht und Anfragen an den verfügbaren Cluster weitergeleitet.

Fällt ein Backend aus, muss kein interner Servicename öffentlich umgeschrieben werden. Die Edge kann das Ziel aus dem Routing nehmen. Wird später der Provider gewechselt, bleibt die Domain unverändert; angepasst werden nur die Backend-Beziehungen. DNS, öffentlicher Eingang und Kubernetes -Service Discovery behalten damit ihre jeweils eigene Zuständigkeit.

FAQ

Ist Kubernetes-DNS für öffentliche Domains geeignet?

Nein. Kubernetes-DNS ist primär für die interne Service-Auflösung gedacht. Öffentliche Domains sollten auf einen kontrollierten externen Eingang zeigen, nicht direkt auf interne Service- oder Pod-Adressen.

Muss die externe DNS-Zone beim Kubernetes-Provider liegen?

Nein. DNS kann unabhängig vom Clusterprovider betrieben werden. Eine Edge-Plattform mit Anycast DNS und Multi-Provider-DNS kann den öffentlichen Namensraum von der Compute-Infrastruktur entkoppeln.

Was passiert bei mehreren Kubernetes-Clustern?

Die externe Domain bleibt am öffentlichen Edge-Eingang. Die Edge Cloud kann mehrere Backends verwalten, ihre Gesundheit prüfen und Traffic nach definierter Routinglogik an verfügbare Cluster weiterleiten.

Fazit

Kubernetes-DNS und externe Zonen lösen unterschiedliche Probleme und sollten auch unterschiedlich betrieben werden. Der Cluster bleibt für interne Service Discovery und Workload-Kommunikation zuständig; die Edge übernimmt öffentlichen DNS-Kontext, Schutz, Termination und Traffic-Verteilung. Diese Grenze reduziert Providerabhängigkeiten und erleichtert Clusterwechsel oder Mehrclusterbetrieb. Die ayedo Edge Cloud unterstützt dieses Modell unabhängig davon, wo Kubernetes ausgeführt wird: als zentrale Edge-Plattform zwischen öffentlichem Namensraum und den eigentlichen Backends.