Vom DNS zum Backend: Der Request-Pfad an der Edge

TL;DR

Ein Request zur Anwendung durchläuft mehrere technische Ebenen: Anycast DNS liefert einen erreichbaren Einstiegspunkt, das Internet routet den Traffic zur Edge, dort erfolgen Loadbalancing, TLS-Termination und Sicherheitsprüfungen. Erst danach wird der Request über Backend-Routing an einen gesunden Service weitergeleitet. Diese Kette muss als zusammenhängender Betriebsprozess geplant werden.

Ein Request-Pfad ist keine lineare Verbindung zwischen Client und Server. Zwischen DNS-Auflösung und Backend liegen Routingentscheidungen, Transport- und Anwendungsebene, Sicherheitsfunktionen sowie Zustands- und Health-Check-Informationen. Werden diese Komponenten isoliert betrachtet, entstehen häufig Fehlannahmen über Ausfälle, Zertifikate, Quell-IP-Adressen oder die tatsächliche Erreichbarkeit eines Backends.

Für Platform Engineers und Architekt:innen ist deshalb entscheidend, den vollständigen Ablauf zu verstehen. Nur so lassen sich Fehlerbilder korrekt eingrenzen, Failover-Szenarien bewerten und die Verantwortungsgrenzen zwischen Edge und Compute sauber definieren.

1. Anycast DNS schafft den öffentlichen Einstiegspunkt

Am Anfang steht die DNS-Auflösung des Hostnamens. Anycast DNS beantwortet die Anfrage über verteilte Netzwerkinfrastruktur und liefert die für den Service vorgesehenen Adressen. Der Client erhält damit keinen direkten Hinweis auf ein konkretes Backend, sondern einen öffentlichen Einstiegspunkt der Edge.

Diese Trennung ist architektonisch relevant: DNS entscheidet, unter welcher Adresse ein Service erreichbar ist. Es verteilt jedoch nicht automatisch jede einzelne HTTP-Anfrage auf einen bestimmten Pod oder Server. Die anschließende Auswahl erfolgt innerhalb der Edge- und Backend-Routing-Logik. Änderungen an DNS-TTLs, Caches und Resolvern beeinflussen daher, wie schnell neue Erreichbarkeitsinformationen bei Clients wirksam werden.

Bei einer Edge-Plattform wie der ayedo Edge Cloud kann Anycast DNS mit dem Anycast-Netzwerk und Multi-Provider-DNS zusammenspielen. Der DNS-Schritt ist damit Teil einer durchgängigen Erreichbarkeitsarchitektur, aber nicht deren einziger Failover-Mechanismus. Für die Betriebsplanung müssen DNS-Verhalten und aktive Traffic-Verteilung getrennt betrachtet werden.

2. Anycast Routing führt den Traffic zur Edge

Nach der DNS-Auflösung baut der Client eine Verbindung zur gelieferten IP-Adresse auf. Anycast-Routing sorgt dafür, dass der Traffic über das Internet zu einem geeigneten Edge-Punkt gelangt. Maßgeblich ist dabei nicht die geografische Entfernung allein, sondern die Routingentscheidung des Netzes. Der Client kennt die interne Topologie und die späteren Backends nicht.

Hier liegt ein wesentlicher Unterschied zu einem klassischen, zentral betriebenen Loadbalancer. Die Edge ist nicht nur ein einzelner Netzwerkendpunkt, sondern eine verteilte Eingangsschicht. Die ayedo Edge Cloud nutzt dafür ein eigenes Autonomous System und eigene Netzwerk-Infrastruktur in einer verteilten Multi-PoP-Architektur. Das Aktiv-Aktiv-Prinzip ermöglicht, Traffic grundsätzlich über mehrere verfügbare Edge-Instanzen zu verarbeiten.

Für den Betrieb bedeutet das: Ein Fehler an einem Backend muss nicht zwangsläufig die öffentliche IP-Adresse unbrauchbar machen. Die Edge kann den Request weiterhin annehmen, den Zustand der Backends bewerten und nur gesunde Ziele verwenden. Das reduziert die Kopplung zwischen öffentlicher Erreichbarkeit und dem Zustand einzelner Compute-Ressourcen.

3. TLS-Termination und Loadbalancing verarbeiten den Request

Erreicht der Traffic die Edge, wird zunächst die Verbindung auf Transport- und gegebenenfalls Anwendungsebene verarbeitet. Bei HTTPS kann die TLS-Termination an der Edge erfolgen. Die Edge nimmt dabei die verschlüsselte Verbindung an, prüft das konfigurierte Zertifikat und verarbeitet anschließend den HTTP-Request. Das Backend muss die öffentliche TLS-Verbindung nicht selbst terminieren.

Diese Entscheidung verändert Verantwortlichkeiten. Zertifikate, unterstützte TLS-Konfigurationen und öffentliche Sicherheitsrichtlinien liegen an einem zentralen Punkt. Gleichzeitig muss klar definiert sein, wie der Traffic zur Anwendung weitergeschützt wird und welche Informationen aus der ursprünglichen Verbindung an das Backend übergeben werden. Für HTTP-/HTTPS-Services können zusätzlich Web Application Firewall und DDoS Protection an der Edge greifen, bevor der Request Compute-Ressourcen erreicht.

Anschließend übernimmt das Loadbalancing die Auswahl eines geeigneten Ziels. Layer-4- und Layer-7-Loadbalancing adressieren dabei unterschiedliche Anforderungen: Auf Layer 4 steht die Transportverbindung im Mittelpunkt, auf Layer 7 können Protokoll- und Requestinformationen für das Routing berücksichtigt werden. Proxy Protocol kann erforderlich sein, wenn nachgelagerte Systeme die ursprünglichen Verbindungsinformationen benötigen.

4. Backend-Routing bestimmt den letzten Abschnitt

Erst nach der Verarbeitung an der Edge wird der Request an ein Backend weitergeleitet. Dieses Backend kann in einem ayedo Managed Kubernetes Cluster, in einem eigenen Kubernetes-Cluster oder bei einem anderen Provider betrieben werden. Die Edge ist damit nicht an eine bestimmte Compute-Plattform gebunden. Entscheidend sind Erreichbarkeit, Routingkonfiguration und der von der Anwendung erwartete Protokollpfad.

Backend Health Checks liefern die Grundlage für diese Auswahl. Sie prüfen, ob ein Ziel nicht nur technisch erreichbar, sondern gemäß der definierten Prüfung verwendbar ist. Bei einem Ausfall kann die Edge den Traffic auf andere gesunde Ziele umleiten. Backend Cloaking verhindert dabei, dass die internen Zieladressen zum öffentlichen Bestandteil der Anwendungstopologie werden.

Für Kubernetes Umgebungen ist die Trennung besonders wichtig. Kubernetes steuert die Ausführung und interne Verteilung von Workloads; die Edge Cloud übernimmt den öffentlichen Traffic-Eingang, Schutz, Termination und die externe Lastverteilung. Diese Verantwortungsgrenze gilt unabhängig davon, ob Compute und Edge beim selben Anbieter betrieben werden. Sie erleichtert Providerwechsel und reduziert die Abhängigkeit vom öffentlichen Netzwerkpfad einzelner Cluster.

Praxisszenario: Fehleranalyse entlang der Kette

Ein HTTPS-Service ist unter api.example.de erreichbar, aber einzelne Requests schlagen fehl. Eine Prüfung beginnt nicht beim Pod, sondern am Anfang des Pfads: Liefert Anycast DNS die erwartete Adresse? Wird der Traffic zur Edge geroutet? Wird die TLS-Verbindung korrekt terminiert? Akzeptiert das Layer-7-Routing den Hostnamen und den Pfad? Sind die Health Checks erfolgreich, und erreicht die Weiterleitung das Backend?

Ein DNS-Fehler, ein abgelaufenes Zertifikat, ein falsches Routingkriterium und ein nicht erreichbarer Service erzeugen unterschiedliche Symptome. Die End-to-End-Sicht verhindert, dass das Betriebsteam vorschnell nur die Compute-Schicht untersucht. Gleichzeitig lässt sich erkennen, an welcher Verantwortungsgrenze die Störung tatsächlich liegt.

FAQ

Ist DNS bereits Loadbalancing?

Nein. DNS liefert Erreichbarkeitsinformationen. Die Auswahl konkreter Backend-Ziele erfolgt typischerweise durch Routing- und Loadbalancing-Logik nach dem Verbindungsaufbau.

Warum TLS an der Edge terminieren?

TLS-Termination zentralisiert die öffentliche Verschlüsselungsschicht. Dadurch können Zertifikate und Sicherheitsrichtlinien an der Edge verarbeitet werden, während Backends von dieser Aufgabe entkoppelt bleiben.

Muss das Backend direkt aus dem Internet erreichbar sein?

Nein. Eine Edge kann als öffentlicher Eingang dienen und Backends abschirmen. Backend Cloaking reduziert dabei die Sichtbarkeit interner Zieladressen; die konkrete private Erreichbarkeit muss zur Netzwerkarchitektur passen.

Fazit

Der Request-Pfad Edge Cloud beginnt mit DNS, endet aber erst nach der erfolgreichen Weiterleitung an ein gesundes Backend. Anycast, Routing, TLS-Termination und Loadbalancing sind keine isolierten Funktionen, sondern aufeinanderfolgende Verarbeitungsschritte mit gemeinsamen Betriebsfolgen. Die ayedo Edge Cloud ordnet diese Aufgaben als öffentliche Eingangsschicht vor unterschiedlichen Compute-Umgebungen ein. Genau diese Trennung schafft eine belastbare Grundlage für Failover, Sicherheitskontrolle und providerunabhängiges Backend-Routing .