DNS-Records aus Kubernetes Ingress automatisch verwalten

TL;DR

Kubernetes-Ingress- und Gateway-Konfigurationen enthalten bereits die Hostnamen, unter denen Anwendungen erreichbar sein sollen. External-DNS kann diese deklarativen Angaben in DNS-Records übersetzen. Damit daraus ein konsistenter öffentlicher Endpunkt entsteht, müssen DNS-Zone, Edge-Routing und Backend-Konfiguration denselben gewünschten Zustand abbilden.

Einleitung

Ein Kubernetes-Hostname ist noch kein erreichbarer Service. Ein Ingress oder ein Gateway kann zwar festlegen, dass api.example.com zu einer bestimmten Anwendung gehört, ohne passenden DNS-Record bleibt dieser Host jedoch unsichtbar. Umgekehrt kann ein DNS-Eintrag auf einen öffentlich erreichbaren Endpunkt zeigen, für den im Cluster keine passende Routing-Regel existiert. Diese getrennten Zustände erzeugen schwer erkennbare Fehler: falsche Backends, verwaiste Records oder TLS-Konfigurationen, die nicht zum Host passen. Die zentrale Architekturentscheidung lautet deshalb: Kubernetes-Hosts, DNS-Veröffentlichung und Edge-Endpunkte müssen als zusammenhängende Kette behandelt werden – mit klarer Zuständigkeit für jede Schicht.

1. Kubernetes-Hosts als deklarative Quelle

Ingress-Regeln und Ressourcen der Gateway API beschreiben, unter welchem Host HTTP-Anfragen verarbeitet werden sollen. Der Hostname ist dabei nicht nur ein Routing-Attribut. Er definiert zugleich die erwartete öffentliche Identität eines Services und wird häufig für TLS-Zertifikate, Zugriffskontrollen und Observability verwendet.

Genau hier setzt das Muster hinter External-DNS an: Ein Controller beobachtet relevante Kubernetes-Ressourcen und leitet aus deren Hostdefinitionen gewünschte DNS-Records ab. Änderungen an spec.rules.host oder an Gateway-Listenern können dadurch den DNS-Zustand automatisch anpassen. Entfernt ein Team eine Ressource, kann der zugehörige Record ebenfalls aus der Verwaltung genommen werden – abhängig von den gewählten Schutz- und Ownership-Mechanismen.

Wichtig ist die Abgrenzung: Der Kubernetes-Host ist die deklarative Absicht, nicht automatisch die korrekte Zieladresse. Dafür müssen Zuständigkeit, erlaubte Zonen und die Zuordnung zum öffentlichen Endpunkt eindeutig definiert sein.

2. DNS-Veröffentlichung ist ein kontrollierter Abgleich

Automatisierte DNS-Verwaltung bedeutet nicht, jede erkannte Host-Angabe ungeprüft öffentlich zu publizieren. In produktiven Umgebungen braucht der Abgleich Regeln: Welche Namespaces dürfen Records erzeugen? Welche DNS-Zonen sind erlaubt? Wie werden konkurrierende Ressourcen behandelt? Und wann darf ein Record gelöscht werden?

External-DNS ist in diesem Modell die Verbindung zwischen Kubernetes und einem DNS-Provider. Die gewünschte Konfiguration wird aus Ingress- oder Gateway-Objekten gelesen und mit dem tatsächlich verwalteten DNS-Zustand verglichen. Providerunabhängige Nutzung ist möglich, sofern der eingesetzte Provider unterstützt wird und Ownership sauber geregelt ist. Besonders relevant ist das bei Multi-Cluster- oder Multi-Team-Umgebungen: Ohne eindeutige Zuständigkeit können mehrere Controller denselben Record verändern oder sich gegenseitig überschreiben.

Die DNS-Ebene muss außerdem zwischen öffentlich erreichbaren und internen Anwendungen unterscheiden. Ein Hostname aus einem Entwicklungsnamespace darf nicht allein durch seine Existenz im Cluster in einer öffentlichen Zone landen.

3. Die Edge Cloud als Ziel des öffentlichen Endpunkts

Der DNS-Record sollte in einer Edge-Architektur nicht direkt auf ein verborgenes Backend zeigen. Er verweist stattdessen auf den öffentlichen Endpunkt der Edge Cloud. Dort können Anycast-basiertes Layer-4- und Layer-7-Loadbalancing, TLS Termination, Web Application Firewall, DDoS Protection und Backend Health Checks zentral für den Host wirksam werden.

Die technische Kette lautet damit: Ein Host wird in Kubernetes deklariert, aus dieser Deklaration entsteht ein DNS-Ziel, und dieses Ziel führt zur ayedo Edge Cloud. Die Edge ordnet den Host anschließend dem passenden Routing und Backend zu. Backend Cloaking verhindert dabei, dass die eigentlichen Cluster-Endpunkte als öffentliche DNS-Ziele verwendet werden müssen.

Diese Trennung ist auch für Kubernetes-Cluster außerhalb von ayedo Managed Kubernetes relevant. Ein eigener Cluster oder ein Cluster bei einem anderen Provider kann denselben Edge-Eingang nutzen. Kubernetes bleibt für Workload- und Routingdefinitionen verantwortlich; DNS und öffentlicher Traffic-Eingang werden als eigenständige Plattformbereiche betrieben.

4. Konsistenz braucht Status, Tests und Betriebsregeln

Der kritische Betriebsfall ist nicht die erfolgreiche Veröffentlichung eines neuen Records, sondern eine teilweise aktualisierte Konfiguration. Wird ein Ingress zuerst angelegt, DNS aber verzögert aktualisiert, ist der Service möglicherweise nur über einen temporären oder noch nicht auflösbaren Zustand erreichbar. Wird dagegen DNS entfernt, bevor das Edge-Routing bereinigt ist, bleiben Konfigurationen und Ressourcen unnötig bestehen.

Deshalb sollte der Lebenszyklus beobachtbar sein: Existiert der Host im Kubernetes-Objekt? Wurde der erwartete Record veröffentlicht? Zeigt er auf den vorgesehenen Edge-Endpunkt? Ist der Host an der Edge aktiv und erreicht die Health-Checks ein gültiges Backend? Diese Prüfungen müssen nicht zwingend in einem einzelnen Tool stattfinden, sollten aber als zusammenhängender Betriebsprozess betrachtet werden.

Für Unternehmen reduziert das manuelle DNS-Änderungen und Konfigurationsdrift. Gleichzeitig steigt die Verantwortung für Validierung und Berechtigungen. Ein fehlerhafter Host kann sonst automatisiert veröffentlicht werden. Sinnvoll sind daher Namespaces, Zonen und Ressourcentypen als klare Governance-Grenzen – ergänzt durch Change-Reviews für besonders kritische Domains.

Praxis- und Betriebsszenario

Ein Team veröffentlicht payments.example.com über ein Gateway im eigenen Kubernetes-Cluster . Das Gateway definiert den Host und verweist auf den Zahlungsservice. External-DNS erkennt die deklarierte Hostkonfiguration und aktualisiert den zuständigen DNS-Provider. Der Record zeigt nicht auf eine Node-IP, sondern auf den öffentlichen ayedo-Edge-Endpunkt. Die Edge übernimmt TLS Termination, prüft das Backend und leitet den Traffic an den Cluster weiter.

Wird das Gateway gelöscht, muss der Prozess auch die DNS- und Edge-Zustände berücksichtigen. Ein kontrollierter Abgleich entfernt oder deaktiviert den Host erst dann, wenn Ownership- und Schutzregeln dies zulassen. Ohne diese Regeln kann ein gelöschter Kubernetes-Service als verwaister DNS-Record bestehen bleiben.

FAQ

Ist External-DNS selbst ein DNS-Server?

Nein. External-DNS synchronisiert gewünschte DNS-Records aus Kubernetes-Ressourcen mit einem unterstützten DNS-Provider. Die autoritative DNS-Auflösung bleibt Aufgabe dieses Providers.

Können Gateway-API-Ressourcen statt Ingress verwendet werden?

Ja, sofern die eingesetzte External-DNS-Konfiguration und der Gateway-Controller die relevanten Listener- und Hostdefinitionen auswerten. Die genaue Unterstützung hängt von der jeweiligen Implementierung ab.

Muss der DNS-Record direkt auf den Kubernetes-Cluster zeigen?

Nein. In einer vorgeschalteten Edge-Architektur kann der Record auf den öffentlichen Edge-Endpunkt zeigen. Das Backend bleibt dadurch verborgen und wird nur über die Edge erreicht.

Fazit

Kubernetes DNS Records sind dann belastbar, wenn sie nicht isoliert als DNS-Automatisierung betrachtet werden. Ingress- und Gateway-Hosts beschreiben die gewünschte Anwendungsschnittstelle; External-DNS veröffentlicht diese Absicht; die Edge Cloud stellt den kontrollierten öffentlichen Eingang bereit. Die ayedo Edge Cloud verbindet dafür DNS, Anycast-Erreichbarkeit, Schutz und Backend-Routing – unabhängig davon, wo der Kubernetes-Cluster betrieben wird. Entscheidend bleibt ein überprüfbarer Lebenszyklus über alle Schichten hinweg.