Ingress und Gateway: DNS-Records aus Hosts ableiten

TL;DR

Kubernetes-Ressourcen enthalten bereits die fachliche Zuordnung zwischen Hostnamen und Anwendungen. Ein automatisierter DNS-Prozess kann diese Angaben aus Ingress oder Gateway API auswerten, passende Records für die Edge-Adresse erzeugen und Änderungen synchronisieren. Entscheidend sind klare Zuständigkeiten, sichere Löschlogik und die Verbindung von DNS, Edge-Routing und Backend-Zielen.

Einleitung

Ein Hostname in einer Kubernetes-Ressource ist zunächst nur eine Routing-Regel. Er wird erst dann erreichbar, wenn DNS auf einen öffentlichen Einstiegspunkt zeigt und dieser Einstiegspunkt den Hostnamen an das richtige Backend weiterleitet. Genau an dieser Stelle entstehen in vielen Umgebungen Brüche: Teams pflegen Ingress-Regeln, DNS-Records und Edge-Konfiguration getrennt voneinander. Änderungen werden dadurch fehleranfällig, veraltete Records bleiben bestehen und neue Services sind erst nach manuellen Abstimmungen erreichbar. Kubernetes automatische DNS Records lösen dieses Problem nicht allein durch einen weiteren Controller. Erforderlich ist ein belastbarer Lebenszyklus, der Hostnamen aus Ingress- oder Gateway-Ressourcen kontrolliert bis zur erreichbaren Edge-Adresse verfolgt.

1. Der Hostname als verbindliches Architekturartefakt

Bei einem klassischen Kubernetes-Ingress steht der relevante Hostname im Feld spec.rules[].host. Die Regel beschreibt typischerweise, welcher HTTP- oder HTTPS-Pfad zu welchem Service führt. In der Gateway API wird der Hostname an einem Listener oder über eine passende Route definiert. Damit liegt die fachliche Absicht näher an der Anwendungskonfiguration als an der DNS-Verwaltung.

Für die automatische DNS-Erzeugung wird dieser Hostname als gewünschter öffentlicher Name interpretiert. Ein Controller oder eine vergleichbare Integrationslogik beobachtet die Kubernetes-Ressource und leitet daraus einen DNS-Zielwert ab. Dieser Zielwert sollte nicht unmittelbar ein wechselndes Pod- oder Node-Ziel sein, sondern die öffentliche Edge-Adresse des Dienstes.

Damit entsteht eine klare Kette: Die Kubernetes-Ressource definiert den Namen und das Routingverhalten, DNS macht den Namen auflösbar, und die Edge entscheidet anhand des Host-Headers, welches Backend angesprochen wird. Diese Trennung verhindert, dass DNS für Aufgaben verwendet wird, die eigentlich Layer-7-Routing benötigen.

2. Von der Ressource zum Anycast-DNS-Record

Die automatische Ableitung beginnt mit der Erkennung eines neuen oder geänderten Hostnamens. Für Ingress Hostnamen müssen dabei mindestens Regel, Namespace, Ressource und Zielservice zusammen betrachtet werden. Bei Gateway API DNS kommen zusätzlich Listener, erlaubte Routen und die Bindung zwischen Gateway und Route hinzu. Ein Hostname allein reicht nicht, wenn die zugehörige Route nicht akzeptiert oder das Gateway nicht verfügbar ist.

Der DNS-Prozess sollte deshalb einen gewünschten Zustand modellieren: Für app.example.com existiert ein gültiger Edge-Einstiegspunkt, und die Edge kennt die Weiterleitung zum Backend. Erst wenn diese Voraussetzungen erfüllt sind, wird der Record veröffentlicht oder als bereit markiert. Je nach DNS-Zone können dafür A- und AAAA-Records oder ein CNAME verwendet werden. Die konkrete Wahl hängt unter anderem von Zone, Apex-Nutzung und Betriebsmodell ab.

Im Kontext der ayedo Edge Cloud führt dieser Ablauf zu Anycast DNS und einem öffentlichen Edge-Einstiegspunkt. Die Edge Cloud kann den Traffic anschließend per Layer 4 oder Layer 7 verarbeiten und an das konfigurierte Backend weiterleiten. DNS und Routing bleiben dabei logisch gekoppelt, aber technisch getrennte Zustände.

3. Synchronisation, Löschung und Fehlersicherheit

Die schwierigste Phase automatischer DNS Records ist nicht die Erzeugung, sondern die Synchronisation. Wird ein Hostname geändert, muss der alte Record entfernt oder kontrolliert aus dem Verkehr genommen werden. Wird eine Ressource gelöscht, darf daraus nicht automatisch ein unkontrollierter DNS-Ausfall für andere Anwendungen entstehen. Besonders kritisch sind gemeinsam genutzte Zonen, Wildcards und identische Hostnamen in unterschiedlichen Namespaces.

Eine robuste Implementierung benötigt deshalb Ownership-Regeln. Jeder automatisch verwaltete Record muss eindeutig einer Quelle zugeordnet werden können. Außerdem sollte die Integration Konflikte erkennen, statt bestehende manuelle Einträge still zu überschreiben. Für die Löschung ist ein Schutz gegen kurzzeitige Zwischenzustände sinnvoll: Ein Record sollte erst entfernt werden, wenn die Kubernetes-Ressource tatsächlich nicht mehr gewollt ist und keine gültige alternative Route existiert.

Auch DNS-Caching beeinflusst den Betrieb. TTL-Werte bestimmen, wie lange Resolver einen alten Zielwert verwenden. Bei einem Wechsel der Edge-Adresse oder einer kontrollierten Migration muss dieser Zeitversatz eingeplant werden. Health Checks und Failover an der Edge ergänzen DNS, ersetzen es aber nicht: DNS verteilt oder veröffentlicht Ziele, während die Edge den erreichbaren Backend-Zustand bewertet.

4. Edge-Adresse und Backend-Ziel sauber trennen

Ein häufiger Architekturfehler besteht darin, aus einem Ingress-Hostnamen direkt einen Kubernetes-Service, Node oder Pod als DNS-Ziel abzuleiten. Das umgeht die öffentliche Schutz- und Routing-Schicht. Dadurch werden Backend-Adressen sichtbar, Zertifikats- und Routinglogik verteilen sich auf mehrere Ebenen, und ein späterer Wechsel der Compute-Infrastruktur wird unnötig aufwendig.

Sinnvoller ist ein zweistufiges Modell. Der Hostname zeigt auf die öffentliche Edge-Adresse. Die Edge Cloud terminiert bei Bedarf TLS, wendet Schutzfunktionen wie die Web Application Firewall oder DDoS Protection an und nutzt das Hostname-Routing, um ein Backend zu erreichen. Backend Cloaking hält die eigentlichen Ursprungsziele aus der öffentlichen DNS-Sicht heraus.

Das Modell funktioniert unabhängig davon, ob der Cluster mit ayedo Managed Kubernetes, in einer eigenen Umgebung oder bei einem anderen Provider betrieben wird. Kubernetes liefert den gewünschten Host und das Routingmodell; die Edge Cloud bleibt für den öffentlichen Zugang und die Weiterleitung zuständig. Diese Trennung reduziert Abhängigkeiten zwischen DNS, Cluster-Netzwerk und Compute-Plattform.

Praxisszenario: Ein Hostname durch den gesamten Lebenszyklus

Ein Team veröffentlicht payments.example.com zunächst über eine Gateway-Ressource . Der Listener akzeptiert den Hostnamen, eine Route verweist auf den zuständigen Service. Die Integrationslogik erkennt den gewünschten Host, prüft die Gültigkeit der Route und erzeugt den vorgesehenen DNS-Record für den öffentlichen Edge-Einstiegspunkt.

Der Client löst den Namen über Anycast DNS auf und erreicht einen Edge-Punkt. Dort wird TLS beendet, der Hostname ausgewertet und der Traffic an das konfigurierte Backend weitergeleitet. Wird die Anwendung später in einen anderen Kubernetes-Cluster verschoben, bleiben Hostname und öffentlicher Einstiegspunkt unverändert. Nur das Backend-Ziel an der Edge ändert sich. Wird die Gateway-Ressource entfernt, kann der zugehörige DNS-Zustand nach einer definierten Sicherheitsprüfung bereinigt werden.

FAQ

Funktioniert automatische DNS-Erzeugung nur mit Ingress?

Nein. Das Prinzip lässt sich auch auf die Gateway API anwenden. Dort müssen Listener, Routes und deren Akzeptanzzustand berücksichtigt werden, nicht nur ein einzelnes Host-Feld.

Sollte DNS direkt auf einen Kubernetes-Service zeigen?

Für öffentlich erreichbare Anwendungen meist nicht. DNS sollte auf den öffentlichen Edge-Einstiegspunkt zeigen. Die Edge übernimmt danach Schutz, Routing und die Weiterleitung zum Backend.

Was passiert bei mehreren Clustern?

Der Hostname muss eindeutig verwaltet werden. Eine zentrale Ownership- und Konfliktlogik verhindert, dass mehrere Cluster denselben DNS-Record unkontrolliert überschreiben.

Fazit

Kubernetes automatische DNS Records sind vor allem eine Frage sauberer Zustands- und Verantwortungsmodelle. Ingress und Gateway definieren den gewünschten Hostnamen, DNS veröffentlicht die erreichbare Edge-Adresse, und die Edge ordnet den Traffic dem passenden Backend zu. Wer diese Ebenen trennt, erhält reproduzierbare Änderungen, kontrollierte Löschprozesse und weniger Abhängigkeit von konkreten Clustern. Die ayedo Edge Cloud unterstützt dieses Modell als providerunabhängige Schicht für Anycast DNS, öffentliches Routing und Backend-Anbindung.