Kubernetes-DNS und Edge-Routing über Providergrenzen betreiben

TL;DR

In einer Kubernetes-Multi-Cloud-Umgebung müssen interner Service-DNS, öffentliche DNS-Zonen und Edge-Routing denselben Lebenszyklus abbilden. Werden Records, Endpoints und Routing unabhängig verwaltet, entstehen veraltete Ziele und unklare Failover-Zustände. Ein abgestimmtes Modell trennt Verantwortlichkeiten, zentralisiert den öffentlichen Eingang und macht Änderungen nachvollziehbar.

Einleitung

Kubernetes-DNS und öffentliches Routing sind zwei unterschiedliche Ebenen, werden im Betrieb aber häufig wie ein gemeinsames Problem behandelt. Innerhalb eines Clusters löst Kubernetes-DNS Services und Pods auf. Außerhalb müssen autoritative DNS-Systeme und die Edge den richtigen Cluster erreichen. Liegen diese Cluster bei unterschiedlichen Providern, reicht ein zusätzlicher DNS-Record nicht aus: Der Record muss zum tatsächlichen Zustand des Backends, zur Traffic-Verteilung und zur Failover-Strategie passen.

Der typische Fehler ist eine lose Kopplung zwischen Deployment, DNS-Automatisierung und Edge-Konfiguration. Ein neuer Ingress ist dann zwar im Cluster verfügbar, aber noch nicht korrekt veröffentlicht. Oder ein ausgefallener Provider bleibt wegen gecachter DNS-Antworten weiterhin erreichbar. Kubernetes DNS Routing ist deshalb vor allem eine Frage abgestimmter Kontroll- und Betriebsläufe.

1. Drei DNS-Ebenen sauber trennen

Kubernetes-DNS erfüllt zunächst eine interne Aufgabe. Services erhalten stabile Namen, während sich Pods und deren IP-Adressen ändern können. Diese Auflösung gilt innerhalb des Clusters und sollte nicht mit der öffentlichen Namensauflösung verwechselt werden. Ein Service-Name wie api.namespace.svc ist kein geeignetes Ziel für Clients außerhalb des Clusters.

Für die Veröffentlichung kommen mindestens zwei weitere Ebenen hinzu: autoritative DNS-Zonen für öffentliche Hostnamen und die Routinglogik an der Edge. Der öffentliche DNS-Record kann dabei auf einen stabilen Edge-Einstieg zeigen, während die Edge den Traffic an einen oder mehrere Cluster weiterleitet. Dadurch bleibt der öffentliche Name unabhängig von einzelnen Node-, Pod- oder Provider-Adressen.

Diese Trennung reduziert Kopplung. Kubernetes verwaltet Services und Workloads, DNS veröffentlicht Erreichbarkeit, und die Edge entscheidet über Weiterleitung, Schutz und Backend-Auswahl. Die ayedo Edge Cloud ist in diesem Modell nicht nur ein L4-Loadbalancer: Sie verbindet Anycast DNS, Multi-Provider-DNS, L4- und L7-Loadbalancing sowie Backend Health Checks an einem öffentlichen Eingang.

2. DNS- und Routing-Lebenszyklen synchronisieren

Die zentrale Betriebsfrage lautet nicht nur, welcher Record existiert, sondern wann er gültig sein darf. Ein automatisierter Ablauf sollte beispielsweise zuerst prüfen, ob ein Service erreichbar ist, anschließend die Edge-Konfiguration aktualisieren und erst dann einen öffentlichen DNS-Record aktivieren. Beim Entfernen gilt die umgekehrte Reihenfolge: Traffic stoppen, DNS-Änderung ausrollen und Ressourcen erst nach ausreichender Übergangszeit löschen.

TTL-Werte beeinflussen diesen Ablauf, lösen ihn aber nicht. Niedrige TTLs reduzieren die Zeit veralteter DNS-Caches, erhöhen jedoch Änderungsfrequenz und Abhängigkeit von autoritativen DNS-Systemen. Außerdem entscheiden Resolver nicht ausschließlich nach dem gewünschten TTL. Failover über DNS ist daher grundsätzlich verzögert und nicht mit sofortiger Umschaltung gleichzusetzen.

Für Kubernetes-native Umgebungen braucht es eine eindeutige Quelle für gewünschte Zustände und eine nachvollziehbare Reconciliation. Automatisch erzeugte DNS-Records müssen an Ingress-, Gateway- oder Service-Lebenszyklen gekoppelt sein. Die Edge-Konfiguration muss denselben Zustand kennen. Ohne diese Kopplung können DNS und Routing jeweils für sich korrekt aussehen und gemeinsam dennoch auf ein nicht verfügbares Backend zeigen.

3. Multi-Provider-DNS und Edge-Failover unterscheiden

Multi-Provider-DNS verteilt die Autorität oder Verfügbarkeit der DNS-Auflösung auf mehrere DNS-Anbieter. Das verbessert die Abhängigkeitssituation der Namensauflösung, ersetzt aber kein Anwendungs-Failover. Wenn beide DNS-Provider auf dieselbe ausgefallene Adresse zeigen, bleibt die Anwendung nicht erreichbar. Umgekehrt kann ein funktionierender DNS-Dienst auf eine Edge-Konfiguration verweisen, deren Backends nicht gesund sind.

Deshalb sollte der öffentliche Hostname idealerweise auf einen stabilen, providerunabhängig betriebenen Edge-Einstieg zeigen. Die Edge kann anschließend mehrere Kubernetes-Cluster als Backends kennen und anhand von Health Checks sowie definierter Failover-Logik verteilen. Das vermeidet, dass bei jedem Providerwechsel öffentliche DNS-Zonen geändert werden müssen. DNS Failover bleibt dann eine Infrastrukturmaßnahme; das schnelle Umschalten von Backends erfolgt an der Routing-Ebene.

Bei der ayedo Edge Cloud gehören Anycast DNS und Multi-Provider-DNS ebenso zum Architekturmodell wie Anycast-basiertes Layer-4- und Layer-7-Routing. Durch die eigene Netzwerk-Infrastruktur, das eigene Autonomous System und eine verteilte Aktiv-Aktiv-Architektur liegt der öffentliche Eingang nicht ausschließlich bei einem einzelnen Kubernetes-Provider. Die Cluster können bei ayedo oder bei anderen Providern betrieben werden.

4. Betrieb, Sicherheit und Zuständigkeiten festlegen

Providerübergreifendes Kubernetes-DNS Routing scheitert in der Praxis häufig an fehlenden Zuständigkeiten. Das Plattformteam verwaltet Cluster und Services, das Netzwerkteam DNS-Zonen und Edge-Routing, während Security Vorgaben für TLS, WAF und erlaubte Backends definiert. Ohne gemeinsames Änderungsmodell entstehen manuelle Übergaben und schwer reproduzierbare Zwischenzustände.

Technisch sollten Änderungen deshalb als überprüfbare Zustandsänderungen behandelt werden. Dazu gehören klare Ownership für Hostnamen, definierte Lebenszyklen für Records, Health-Check-Kriterien und ein Verfahren für Rollback. Monitoring muss nicht nur DNS-Antworten messen, sondern auch die Kette bis zum Backend: Auflösung, Edge-Erreichbarkeit, TLS-Termination, Routing und Anwendungsgesundheit.

Die Edge übernimmt dabei zugleich Sicherheits- und Abstraktionsfunktionen. TLS kann am öffentlichen Eingang terminiert werden; Backend Cloaking verhindert, dass interne Zieladressen nach außen sichtbar werden. WAF und DDoS Protection reduzieren die Belastung der Cluster, unabhängig davon, bei welchem Provider sie laufen. Das ist betrieblich relevant, weil Sicherheitsrichtlinien nicht pro Cluster und Provider dupliziert werden müssen.

Betriebsszenario: Zwei Cluster, ein öffentlicher Hostname

Ein Unternehmen betreibt einen Kubernetes-Cluster bei Provider A und einen zweiten bei Provider B. Beide stellen denselben Service bereit, aber mit unterschiedlichen internen Service-Adressen. Der öffentliche Hostname zeigt auf die Edge. Die Edge kennt beide Cluster als Backends und prüft ihre Gesundheit.

Bei einem Release wird der Service zunächst im zweiten Cluster bereitgestellt und getestet. Erst wenn dessen Health Check erfolgreich ist, nimmt die Edge ihn in die Verteilung auf. Fällt Provider A aus, kann die Edge den Traffic auf Provider B lenken, ohne den öffentlichen DNS-Record zu ändern. Multi-Provider-DNS schützt dabei die DNS-Ebene selbst; die eigentliche Backend-Umschaltung findet im Routing statt. Wird ein Cluster dauerhaft entfernt, wird zuerst das Edge-Backend deaktiviert und danach der zugehörige Automatisierungszustand bereinigt.

FAQ

Ist Kubernetes-DNS für öffentliche Anwendungen ausreichend?

Nein. Kubernetes-DNS löst primär interne Services auf. Für öffentliche Anwendungen braucht es autoritative DNS-Zonen und eine Routing-Ebene, die externe Anfragen sicher an erreichbare Backends weiterleitet.

Wann ist DNS Failover sinnvoll?

DNS Failover eignet sich für grobe Standort- oder Providerumschaltungen. Für schnelle Reaktionen auf Backend-Ausfälle sind Health Checks und Failover an der Edge meist besser geeignet, weil DNS-Caches Umschaltungen verzögern.

Muss Kubernetes bei ayedo betrieben werden?

Nein. Die Kubernetes-native Integration der ayedo Edge Cloud kann auch mit eigenen Clustern oder Clustern bei anderen Providern eingesetzt werden. Die Edge bleibt dabei vom Compute-Standort getrennt.

Fazit

Providerübergreifendes Kubernetes-DNS Routing ist kein einzelner Konfigurationsschritt, sondern ein abgestimmter Lebenszyklus aus Service-Veröffentlichung, DNS-Automatisierung, Health Checks und Edge-Routing. Die entscheidende Architekturentscheidung besteht darin, öffentliche Erreichbarkeit von den wechselnden Cluster- und Provideradressen zu entkoppeln. Eine Edge-Plattform wie die ayedo Edge Cloud schafft dafür einen zentralen, providerunabhängigen Eingang, während Kubernetes weiterhin die internen Workloads und Services verwaltet.