{
  "version": "https://jsonfeed.org/version/1.1",
  "title": "ayedo",
  "home_page_url": "https://ayedo.de/",
  "feed_url": "https://ayedo.de/",
  "description": "Bei ayedo finden Sie alle Module für den erfolgreichen Betrieb cloud-nativer Software nach höchsten Sicherheitsstandards. ISO-zertifiziert, DORA-compliant und mit 24/7 Support.",
  "icon": "https://ayedo.de/ayedo-logo-color.png",
  "favicon": "https://ayedo.de/ayedo-logo-color.png",
  "authors": [
    {
      "name": "Fabian Peter",
      "url": "https://www.linkedin.com/in/derfabianpeter/"
    }
  ],
  "language": "de",
  "items": [{
      "id": "https://ayedo.de/posts/ayedo-edge-cloud-die-unterschatzte-architektur-moderner-anwendungen/",
      "url": "https://ayedo.de/posts/ayedo-edge-cloud-die-unterschatzte-architektur-moderner-anwendungen/",
      "title": "ayedo Edge-Cloud: Die unterschätzte Architektur moderner Anwendungen",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/ayedo-edge-cloud-die-unterschatzte-architektur-moderner-anwendungen/ayedo-edge-cloud-die-unterschatzte-architektur-moderner-anwendungen.png\" alt=\"\"\u003e\u003c/p\u003e\n\u003ch2 id=\"moderne-anwendungen-beginnen-nicht-mehr-im-rechenzentrum\"\u003eModerne Anwendungen beginnen nicht mehr im Rechenzentrum\u003c/h2\u003e\n\u003cp\u003eEs gibt einen Gedanken, der sich hartnäckig hält, obwohl moderne Software ihn längst widerlegt hat.\u003c/p\u003e\n\u003cp\u003eWenn wir über den Betrieb einer Anwendung sprechen, denken wir fast automatisch an das Rechenzentrum. An virtuelle Maschinen, \u003ca href=\"/kubernetes/\"\u003eKubernetes-Cluster\u003c/a\u003e\n, Datenbanken, \u003ca href=\"/kubernetes/\"\u003eContainer\u003c/a\u003e\n oder Storage-Systeme. Unsere Architekturdiagramme beginnen häufig genau dort: irgendwo innerhalb einer Cloud-Region, hinter einer Firewall, dort, wo Compute-Ressourcen bereitgestellt und Anwendungen ausgeführt werden.\u003c/p\u003e\n\u003cp\u003eSelbst die Sprache, die wir verwenden, verrät dieses Denken. Wir sprechen davon, Anwendungen \u003cem\u003ezu deployen\u003c/em\u003e, Cluster \u003cem\u003ezu betreiben\u003c/em\u003e oder Plattformen \u003cem\u003ezu skalieren\u003c/em\u003e. Die eigentliche Infrastruktur beginnt für uns in dem Moment, in dem der erste \u003ca href=\"/kubernetes/\"\u003eContainer\u003c/a\u003e\n gestartet wird.\u003c/p\u003e\n\u003cp\u003eDoch genau dort beginnt sie längst nicht mehr.\u003c/p\u003e\n\u003cp\u003eVielleicht hat sie dort nie begonnen.\u003c/p\u003e\n\u003cp\u003eDie Vorstellung, dass eine Anwendung mit ihrem ersten Prozess oder ihrem ersten Pod beginnt, stammt aus einer Zeit, in der Software und Infrastruktur nahezu deckungsgleich waren. Wer einen Webserver betrieb, stellte einen Server ins Rack, installierte ein Betriebssystem, konfigurierte einen Webserver und verband ihn mit dem Internet. Zwischen dem Browser eines Benutzers und der eigentlichen Anwendung lagen vergleichsweise wenige technische Schichten. Routing, Transport und Anwendung bildeten eine Einheit, die sich noch mit einem einzigen Architekturdiagramm erklären ließ.\u003c/p\u003e\n\u003cp\u003eHeute wirkt dieses Bild beinahe naiv.\u003c/p\u003e\n\u003cp\u003eNicht, weil moderne Anwendungen grundsätzlich komplizierter geworden wären, sondern weil sich ihre eigentliche Komplexität verlagert hat.\u003c/p\u003e\n\u003cp\u003eIn den vergangenen anderthalb Jahrzehnten haben wir enorme Fortschritte dabei gemacht, Anwendungen selbst zu abstrahieren. Virtuelle Maschinen lösten physische Server ab. \u003ca href=\"/kubernetes/\"\u003eContainer\u003c/a\u003e\n reduzierten die Unterschiede zwischen Entwicklungs- und Produktionsumgebungen. Kubernetes entkoppelte Anwendungen von einzelnen Hosts und machte Infrastruktur zunehmend deklarativ. GitOps, Infrastructure as Code und automatisierte Deployment-Pipelines sorgten schließlich dafür, dass selbst hochkomplexe Plattformen reproduzierbar aufgebaut und betrieben werden können.\u003c/p\u003e\n\u003cp\u003eEs wäre jedoch ein Irrtum anzunehmen, diese Entwicklung habe Infrastruktur einfacher gemacht.\u003c/p\u003e\n\u003cp\u003eSie hat sie lediglich an einen anderen Ort verschoben.\u003c/p\u003e\n\u003cp\u003eWährend die Komplexität innerhalb unserer Plattformen kontinuierlich reduziert wurde, entstand außerhalb dieser Plattformen eine vollkommen neue Architekturebene, die heute einen erheblichen Teil dessen übernimmt, was früher selbstverständlich Bestandteil eines einzelnen Webservers war.\u003c/p\u003e\n\u003cp\u003eEin Benutzer, der eine Anwendung aufruft, verbindet sich längst nicht mehr direkt mit einem Server.\u003c/p\u003e\n\u003cp\u003eEr erreicht zunächst eine Infrastruktur, deren eigentliche Aufgabe nicht darin besteht, Anwendungen auszuführen, sondern darüber zu entscheiden, \u003cstrong\u003eob\u003c/strong\u003e, \u003cstrong\u003ewo\u003c/strong\u003e und \u003cstrong\u003eunter welchen Bedingungen\u003c/strong\u003e eine Anwendung überhaupt erreicht werden darf.\u003c/p\u003e\n\u003cp\u003eDiese Unterscheidung erscheint zunächst subtil.\u003c/p\u003e\n\u003cp\u003eTatsächlich verändert sie jedoch unseren gesamten Blick auf moderne Systeme.\u003c/p\u003e\n\u003cp\u003eDenn bevor eine einzige Zeile Anwendungscode ausgeführt wird, bevor Kubernetes den passenden Pod auswählt oder ein Service eine Anfrage an das richtige Backend weiterleitet, hat bereits eine Vielzahl von Systemen Entscheidungen getroffen, die den weiteren Verlauf dieser Anfrage maßgeblich beeinflussen.\u003c/p\u003e\n\u003cp\u003eWelcher Netzwerkpfad wird verwendet?\u003c/p\u003e\n\u003cp\u003eAn welchem Standort wird die Verbindung entgegengenommen?\u003c/p\u003e\n\u003cp\u003eWo endet die TLS-Verbindung?\u003c/p\u003e\n\u003cp\u003eIst die Anfrage legitim?\u003c/p\u003e\n\u003cp\u003eIst das Zielsystem überhaupt erreichbar?\u003c/p\u003e\n\u003cp\u003eSoll derselbe Benutzer erneut auf dasselbe Backend geleitet werden?\u003c/p\u003e\n\u003cp\u003eOder muss die Anfrage bereits an dieser Stelle verworfen werden?\u003c/p\u003e\n\u003cp\u003eBemerkenswert ist dabei nicht, dass diese Entscheidungen existieren.\u003c/p\u003e\n\u003cp\u003eBemerkenswert ist, dass sie in den meisten Architekturdiagrammen überhaupt nicht vorkommen.\u003c/p\u003e\n\u003cp\u003eWir zeichnen Anwendungen.\u003c/p\u003e\n\u003cp\u003eWir zeichnen Datenbanken.\u003c/p\u003e\n\u003cp\u003eWir zeichnen \u003ca href=\"/kubernetes/\"\u003eKubernetes-Cluster\u003c/a\u003e\n.\u003c/p\u003e\n\u003cp\u003eMit etwas Glück zeichnen wir noch einen Loadbalancer davor.\u003c/p\u003e\n\u003cp\u003eDer eigentliche Weg, den jede einzelne Anfrage zurücklegt, verschwindet dagegen häufig hinter einer simplen Linie mit der Beschriftung \u003cem\u003eInternet\u003c/em\u003e.\u003c/p\u003e\n\u003cp\u003eVielleicht liegt genau darin eines der größten Missverständnisse moderner Plattformarchitekturen.\u003c/p\u003e\n\u003cp\u003eDas Internet ist keine Wolke.\u003c/p\u003e\n\u003cp\u003eEs ist keine Verbindung zwischen zwei Kästen in einem Diagramm.\u003c/p\u003e\n\u003cp\u003eUnd schon gar kein transparenter Transportkanal, durch den Anfragen einfach hindurchfließen.\u003c/p\u003e\n\u003cp\u003eZwischen einem Benutzer und der eigentlichen Anwendung liegt heute eine eigenständige Infrastruktur, die Routingentscheidungen trifft, kryptographische Verbindungen aufbaut, Sicherheitsrichtlinien durchsetzt, Last verteilt, Angriffe erkennt, den Gesundheitszustand von Backends überwacht und kontinuierlich entscheidet, welcher Teil einer Plattform überhaupt sichtbar wird und welcher verborgen bleibt.\u003c/p\u003e\n\u003cp\u003eJe stärker Anwendungen abstrahiert wurden, desto bedeutender wurde genau diese Schicht.\u003c/p\u003e\n\u003cp\u003eParadoxerweise sprechen wir über sie jedoch deutlich seltener als über [Container]-Orchestrierung, Service Meshes oder Observability.\u003c/p\u003e\n\u003cp\u003eVielleicht, weil sie ihre Aufgabe besonders gut erfüllt.\u003c/p\u003e\n\u003cp\u003eGute Infrastruktur besitzt eine bemerkenswerte Eigenschaft: Sie verschwindet.\u003c/p\u003e\n\u003cp\u003eNiemand denkt über DNS nach, solange sich eine Domain zuverlässig auflösen lässt.\u003c/p\u003e\n\u003cp\u003eNiemand beschäftigt sich mit Routingtabellen, solange Webseiten innerhalb weniger Millisekunden laden.\u003c/p\u003e\n\u003cp\u003eNiemand fragt sich, wie ein TLS-Zertifikat bereitgestellt wurde, solange im Browser das kleine Schlosssymbol erscheint.\u003c/p\u003e\n\u003cp\u003eUnd kaum jemand macht sich Gedanken darüber, welchen Weg eine Anfrage tatsächlich genommen hat, solange die Antwort schnell genug zurückkommt.\u003c/p\u003e\n\u003cp\u003eErst wenn eines dieser Systeme ausfällt, erkennen wir, dass sie niemals bloße Nebendarsteller waren.\u003c/p\u003e\n\u003cp\u003eSie waren von Anfang an die Bühne, auf der sich jede moderne Anwendung bewegt.\u003c/p\u003e\n\u003cp\u003eVielleicht ist es deshalb an der Zeit, unsere Architekturdiagramme an einem anderen Punkt beginnen zu lassen.\u003c/p\u003e\n\u003cp\u003eNicht im Rechenzentrum.\u003c/p\u003e\n\u003cp\u003eSondern dort, wo jede Anwendung tatsächlich ihren Anfang nimmt.\u003c/p\u003e\n\u003cp\u003eAm ersten Request aus dem Internet.\u003c/p\u003e\n\u003ch2 id=\"die-reise-eines-requests\"\u003eDie Reise eines Requests\u003c/h2\u003e\n\u003cp\u003eJede moderne Anwendung beginnt mit einer erstaunlich unspektakulären Handlung.\u003c/p\u003e\n\u003cp\u003eJemand öffnet einen Browser.\u003c/p\u003e\n\u003cp\u003eVielleicht sitzt er im Homeoffice in München. Vielleicht arbeitet er in einem Büro in Hamburg oder ruft unterwegs über ein Mobilfunknetz eine API auf. Für ihn spielt das keine Rolle. Er gibt eine URL ein, drückt die Eingabetaste und erwartet, dass innerhalb weniger Augenblicke eine Anwendung erscheint.\u003c/p\u003e\n\u003cp\u003eDiese Erwartung ist bemerkenswert.\u003c/p\u003e\n\u003cp\u003eDenn sie setzt voraus, dass eine Vielzahl voneinander unabhängiger Systeme innerhalb kürzester Zeit dieselbe Entscheidung treffen: Dieser Request soll genau diese Anwendung erreichen.\u003c/p\u003e\n\u003cp\u003eBeginnen wir also dort, wo jede Anfrage tatsächlich beginnt.\u003c/p\u003e\n\u003cp\u003eNicht im Rechenzentrum.\u003c/p\u003e\n\u003cp\u003eNicht im \u003ca href=\"/kubernetes/\"\u003eKubernetes-Cluster\u003c/a\u003e\n.\u003c/p\u003e\n\u003cp\u003eSondern auf einem Laptop irgendwo im Internet.\u003c/p\u003e\n\u003chr\u003e\n\u003cp\u003eDer Browser kennt zunächst nur einen Namen.\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003ehttps://api.example.de \u003c/code\u003e\u003c/p\u003e\n\u003cp\u003eNicht mehr.\u003c/p\u003e\n\u003cp\u003eKeine IP-Adresse.\u003c/p\u003e\n\u003cp\u003eKeinen Server.\u003c/p\u003e\n\u003cp\u003eKein Rechenzentrum.\u003c/p\u003e\n\u003cp\u003eLediglich einen Namen.\u003c/p\u003e\n\u003cp\u003eDamit aus diesem Namen überhaupt eine Verbindung entstehen kann, muss der Browser zunächst herausfinden, wohin er sich verbinden soll. Er fragt dazu einen rekursiven DNS-Resolver, der wiederum mehrere Nameserver kontaktiert, bis schließlich eine Antwort gefunden wird.\u003c/p\u003e\n\u003cp\u003eAus Sicht des Browsers ist dieser Vorgang denkbar unspektakulär.\u003c/p\u003e\n\u003cp\u003eEr erhält eine IP-Adresse.\u003c/p\u003e\n\u003cp\u003eMehr interessiert ihn nicht.\u003c/p\u003e\n\u003cp\u003eWas der Browser nicht weiß: Diese IP-Adresse existiert nicht nur an einem einzigen Ort.\u003c/p\u003e\n\u003cp\u003eSie wird gleichzeitig an mehreren Standorten veröffentlicht.\u003c/p\u003e\n\u003cp\u003eFür den Client bleibt sie dennoch eine einzige Adresse.\u003c/p\u003e\n\u003cp\u003eImmer dieselbe.\u003c/p\u003e\n\u003cp\u003eUnabhängig davon, ob der Benutzer gerade in Flensburg, Frankfurt oder Freiburg sitzt.\u003c/p\u003e\n\u003cp\u003eAn diesem Punkt beginnt bereits eines der elegantesten Konzepte moderner Netzwerkinfrastruktur.\u003c/p\u003e\n\u003cp\u003eDenn der Browser verbindet sich nicht mit einem bestimmten Rechenzentrum.\u003c/p\u003e\n\u003cp\u003eEr verbindet sich lediglich mit einer Adresse.\u003c/p\u003e\n\u003cp\u003eDas Internet entscheidet anschließend selbst, wo diese Verbindung tatsächlich endet.\u003c/p\u003e\n\u003chr\u003e\n\u003cp\u003eDas erste TCP-Paket verlässt nun den Rechner des Benutzers.\u003c/p\u003e\n\u003cp\u003eEs durchquert den heimischen Router, gelangt zum Internet Service Provider und beginnt eine Reise durch Netze, die verschiedenen Unternehmen gehören und sich dennoch darauf geeinigt haben, Datenpakete gegenseitig weiterzuleiten.\u003c/p\u003e\n\u003cp\u003eDabei existiert kein zentraler Verkehrsleiter.\u003c/p\u003e\n\u003cp\u003eKeine Instanz überwacht den gesamten Datenverkehr.\u003c/p\u003e\n\u003cp\u003eKeine Datenbank kennt den optimalen Weg.\u003c/p\u003e\n\u003cp\u003eStattdessen besitzt jedes Netzwerk nur einen kleinen Ausschnitt des Gesamtbildes und trifft auf dieser Grundlage seine eigenen Entscheidungen.\u003c/p\u003e\n\u003cp\u003eGenau diese Eigenschaft macht das Internet seit Jahrzehnten erstaunlich robust.\u003c/p\u003e\n\u003cp\u003eJeder Netzbetreiber kennt seine direkten Nachbarn.\u003c/p\u003e\n\u003cp\u003eJeder entscheidet selbst, welche Wege bevorzugt werden.\u003c/p\u003e\n\u003cp\u003eAus unzähligen lokalen Entscheidungen entsteht schließlich ein globales Netzwerk.\u003c/p\u003e\n\u003cp\u003eIrgendwann erreicht unser Request ein Netzwerk, das dieselbe öffentliche IP-Adresse an mehreren Standorten gleichzeitig kennt.\u003c/p\u003e\n\u003cp\u003eJetzt passiert etwas Bemerkenswertes.\u003c/p\u003e\n\u003cp\u003eNicht die Anwendung entscheidet, welcher Standort den Benutzer bedient.\u003c/p\u003e\n\u003cp\u003eNicht DNS.\u003c/p\u003e\n\u003cp\u003eNicht irgendeine Geo-Datenbank.\u003c/p\u003e\n\u003cp\u003eSondern das Internet selbst.\u003c/p\u003e\n\u003cp\u003eAus Sicht des Routings ist der Point of Presence in Hamburg möglicherweise der kürzeste Weg.\u003c/p\u003e\n\u003cp\u003eFür einen anderen Benutzer entscheidet sich dieselbe Infrastruktur wenige Millisekunden später für Frankfurt.\u003c/p\u003e\n\u003cp\u003eBeide Benutzer verwenden dieselbe URL.\u003c/p\u003e\n\u003cp\u003eBeide erhalten dieselbe IP-Adresse.\u003c/p\u003e\n\u003cp\u003eUnd dennoch landen ihre Verbindungen an unterschiedlichen Orten.\u003c/p\u003e\n\u003cp\u003eOhne Redirect.\u003c/p\u003e\n\u003cp\u003eOhne neue DNS-Abfrage.\u003c/p\u003e\n\u003cp\u003eOhne dass irgendeine Anwendung davon überhaupt Kenntnis besitzt.\u003c/p\u003e\n\u003cp\u003eVielleicht ist genau das der eigentliche Zauber von Anycast.\u003c/p\u003e\n\u003cp\u003eEs ist kein zusätzlicher Dienst.\u003c/p\u003e\n\u003cp\u003eEs ist eine Eigenschaft des Netzwerks selbst.\u003c/p\u003e\n\u003chr\u003e\n\u003cp\u003eAls die Verbindung schließlich einen Point of Presence erreicht, ist von HTTP noch immer keine Rede.\u003c/p\u003e\n\u003cp\u003eZunächst muss überhaupt eine TCP-Verbindung entstehen.\u003c/p\u003e\n\u003cp\u003eDer klassische Three-Way Handshake sorgt dafür, dass sich beide Kommunikationspartner auf eine Verbindung einigen, Sequenznummern austauschen und einen gemeinsamen Übertragungskanal aufbauen.\u003c/p\u003e\n\u003cp\u003eErst danach beginnt die nächste Schicht.\u003c/p\u003e\n\u003cp\u003eDa heute nahezu jede Anwendung verschlüsselt kommuniziert, folgt unmittelbar der TLS-Handschlag.\u003c/p\u003e\n\u003cp\u003eZertifikate werden überprüft.\u003c/p\u003e\n\u003cp\u003eKryptographische Verfahren ausgehandelt.\u003c/p\u003e\n\u003cp\u003eSchlüssel erzeugt.\u003c/p\u003e\n\u003cp\u003eErst nachdem beide Seiten sicher sind, mit wem sie kommunizieren, beginnt der eigentliche Austausch von Anwendungsdaten.\u003c/p\u003e\n\u003cp\u003eInteressanterweise endet für viele Menschen genau hier bereits das mentale Modell einer HTTPS-Verbindung.\u003c/p\u003e\n\u003cp\u003eDer Browser spricht HTTPS.\u003c/p\u003e\n\u003cp\u003eDer Server antwortet.\u003c/p\u003e\n\u003cp\u003eFertig.\u003c/p\u003e\n\u003cp\u003eTatsächlich beginnt die eigentliche Arbeit jedoch erst jetzt.\u003c/p\u003e\n\u003cp\u003eDenn erstmals liegt der Request entschlüsselt vor.\u003c/p\u003e\n\u003cp\u003eErstmals kann eine Plattform verstehen, was der Benutzer eigentlich möchte.\u003c/p\u003e\n\u003cp\u003eWelcher Host wurde aufgerufen?\u003c/p\u003e\n\u003cp\u003eWelche URL wird angefordert?\u003c/p\u003e\n\u003cp\u003eWelcher HTTP-Header wurde übertragen?\u003c/p\u003e\n\u003cp\u003eWelche Cookies enthält die Anfrage?\u003c/p\u003e\n\u003cp\u003eWelches Backend soll sie bearbeiten?\u003c/p\u003e\n\u003cp\u003eVor allem aber:\u003c/p\u003e\n\u003cp\u003eSoll diese Anfrage überhaupt weitergeleitet werden?\u003c/p\u003e\n\u003cp\u003eDenn nicht jeder Request stammt von einem Browser.\u003c/p\u003e\n\u003cp\u003eNicht jede Anfrage kommt von einem legitimen Benutzer.\u003c/p\u003e\n\u003cp\u003eNicht jede Verbindung verfolgt ein legitimes Ziel.\u003c/p\u003e\n\u003cp\u003eEine moderne Edge-Plattform betrachtet einen HTTP-Request deshalb nicht lediglich als Datenstrom.\u003c/p\u003e\n\u003cp\u003eSie analysiert ihn.\u003c/p\u003e\n\u003cp\u003eSie erkennt bekannte Angriffsmuster.\u003c/p\u003e\n\u003cp\u003eSie bewertet Header.\u003c/p\u003e\n\u003cp\u003eSie prüft Protokollverletzungen.\u003c/p\u003e\n\u003cp\u003eSie vergleicht Anfragen mit Regeln der Web Application Firewall und entscheidet innerhalb weniger Millisekunden, ob der Request seine Reise überhaupt fortsetzen darf.\u003c/p\u003e\n\u003cp\u003eErst jetzt stellt sich eine Frage, die viele fälschlicherweise für die erste halten.\u003c/p\u003e\n\u003cp\u003eWelches Backend verarbeitet diese Anfrage?\u003c/p\u003e\n\u003cp\u003eDiese Entscheidung fällt erstaunlich spät.\u003c/p\u003e\n\u003cp\u003eDenn bevor überhaupt über Lastverteilung gesprochen werden kann, musste bereits entschieden werden,\u003c/p\u003e\n\u003cp\u003eob die Verbindung existieren darf,\u003c/p\u003e\n\u003cp\u003ean welchem Standort sie endet,\u003c/p\u003e\n\u003cp\u003eob sie verschlüsselt wird,\u003c/p\u003e\n\u003cp\u003eob sie legitim ist,\u003c/p\u003e\n\u003cp\u003eund ob das Zielsystem überhaupt erreichbar ist.\u003c/p\u003e\n\u003cp\u003eErst danach beginnt das klassische Loadbalancing.\u003c/p\u003e\n\u003cp\u003eAuf Layer 4 bedeutet dies, eine TCP-Verbindung an ein geeignetes Backend weiterzureichen.\u003c/p\u003e\n\u003cp\u003eAuf Layer 7 dagegen kennt die Plattform bereits den Inhalt der Anfrage. Sie kann unterschiedliche URLs an verschiedene Anwendungen senden, Sessions zusammenhalten oder Anfragen anhand ihrer Header unterschiedlich behandeln.\u003c/p\u003e\n\u003cp\u003eDer Unterschied zwischen Layer 4 und Layer 7 besteht deshalb nicht lediglich in einer höheren Zahl.\u003c/p\u003e\n\u003cp\u003eEr besteht darin, dass die Plattform ab Layer 7 beginnt, das eigentliche Anwendungsprotokoll zu verstehen.\u003c/p\u003e\n\u003cp\u003eErst nachdem all diese Entscheidungen getroffen wurden, erreicht unser Request schließlich den Teil der Infrastruktur, den die meisten Architekturdiagramme als ihren Anfang betrachten.\u003c/p\u003e\n\u003cp\u003eDen Ingress.\u003c/p\u003e\n\u003cp\u003eDen \u003ca href=\"/kubernetes/\"\u003eKubernetes-Service\u003c/a\u003e\n.\u003c/p\u003e\n\u003cp\u003eDen ersten Pod.\u003c/p\u003e\n\u003cp\u003eOder, einfacher gesagt:\u003c/p\u003e\n\u003cp\u003eDie eigentliche Anwendung.\u003c/p\u003e\n\u003cp\u003eVielleicht erklärt gerade diese Reihenfolge, weshalb moderne Plattformen heute anders gedacht werden müssen als noch vor zehn Jahren.\u003c/p\u003e\n\u003cp\u003eDie Anwendung ist längst nicht mehr der erste Teil einer Infrastruktur.\u003c/p\u003e\n\u003cp\u003eSie ist ihr letztes Glied.\u003c/p\u003e\n\u003ch2 id=\"der-öffentliche-eingang-einer-anwendung-ist-heute-komplexer-als-die-anwendung-selbst\"\u003eDer öffentliche Eingang einer Anwendung ist heute komplexer als die Anwendung selbst\u003c/h2\u003e\n\u003cp\u003eBetrachten wir für einen Moment zwei Architekturdiagramme.\u003c/p\u003e\n\u003cp\u003eDas erste könnte aus den frühen 2000er-Jahren stammen.text\u003c/p\u003e\n\u003cp\u003eInternet\n│\nFirewall\n│\nWebserver\n│\nDatenbank\u003c/p\u003e\n\u003cp\u003eDas zweite begegnet uns heute nahezu täglich.text\u003c/p\u003e\n\u003cp\u003eInternet\n│\nDNS\n│\nAnycast\n│\nEdge\n│\nWAF\n│\nLoadbalancer\n│\nIngress\n│\n\u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n\n│\nService\n│\nPod\n│\nDatenbank\u003c/p\u003e\n\u003cp\u003eBeide Diagramme beschreiben im Kern dieselbe Aufgabe.\u003c/p\u003e\n\u003cp\u003eEin Benutzer möchte eine Anwendung erreichen.\u003c/p\u003e\n\u003cp\u003eUnd dennoch unterscheiden sie sich grundlegend.\u003c/p\u003e\n\u003cp\u003eIm ersten Diagramm besteht der eigentliche Aufwand darin, die Anwendung zu entwickeln und zuverlässig auf einem Server auszuführen. Das Netzwerk bildet gewissermaßen den Rahmen, innerhalb dessen diese Anwendung betrieben wird. Es verbindet den Benutzer mit dem Server, übernimmt einige grundlegende Sicherheitsaufgaben und tritt anschließend in den Hintergrund.\u003c/p\u003e\n\u003cp\u003eIm zweiten Diagramm hat sich diese Gewichtung nahezu umgekehrt.\u003c/p\u003e\n\u003cp\u003eNatürlich existiert die Anwendung noch immer.\u003c/p\u003e\n\u003cp\u003eNatürlich müssen \u003ca href=\"/kubernetes/\"\u003eContainer\u003c/a\u003e\n orchestriert, Datenbanken repliziert und Deployments durchgeführt werden.\u003c/p\u003e\n\u003cp\u003eDoch betrachtet man den Weg eines einzelnen Requests, fällt auf, dass ein erheblicher Teil seiner Reise stattfindet, bevor überhaupt eine Zeile Anwendungscode ausgeführt wird.\u003c/p\u003e\n\u003cp\u003eVielleicht ist genau das eine der größten Veränderungen moderner Plattformarchitekturen.\u003c/p\u003e\n\u003cp\u003eDie Anwendung selbst ist längst nicht mehr der komplizierteste Teil des Systems.\u003c/p\u003e\n\u003cp\u003eSie ist zu einem Baustein innerhalb einer wesentlich größeren Architektur geworden.\u003c/p\u003e\n\u003cp\u003eDiese Entwicklung erscheint zunächst paradox.\u003c/p\u003e\n\u003cp\u003eSchließlich investieren wir heute erhebliche Anstrengungen, um Anwendungen einfacher betreiben zu können. Kubernetes abstrahiert Hosts, GitOps\u003c/p\u003e\n",
      "summary": "\nModerne Anwendungen beginnen nicht mehr im Rechenzentrum Es gibt einen Gedanken, der sich hartnäckig hält, obwohl moderne Software ihn längst widerlegt hat.\nWenn wir über den Betrieb einer Anwendung sprechen, denken wir fast automatisch an das Rechenzentrum. An virtuelle Maschinen, Kubernetes-Cluster , Datenbanken, Container oder Storage-Systeme. Unsere Architekturdiagramme beginnen häufig genau dort: irgendwo innerhalb einer Cloud-Region, hinter einer Firewall, dort, wo Compute-Ressourcen bereitgestellt und Anwendungen ausgeführt werden.\nSelbst die Sprache, die wir verwenden, verrät dieses Denken. Wir sprechen davon, Anwendungen zu deployen, Cluster zu betreiben oder Plattformen zu skalieren. Die eigentliche Infrastruktur beginnt für uns in dem Moment, in dem der erste Container gestartet wird.\n",
      "image": "https://ayedo.de/ayedo-edge-cloud-die-unterschatzte-architektur-moderner-anwendungen.png",
      "date_published": "2026-09-07T07:20:24Z",
      "date_modified": "2026-09-07T07:20:24Z",
      "authors": [{"name":"Katrin Peter","url":"https://www.linkedin.com/in/katrinpeter/"}],
      "tags": ["kubernetes","cloud-native","software-delivery","security","cloud"],
      "language": "de"
    },{
      "id": "https://ayedo.de/posts/edge-cloud-als-netzwerkgrenze-fur-verteilte-cluster/",
      "url": "https://ayedo.de/posts/edge-cloud-als-netzwerkgrenze-fur-verteilte-cluster/",
      "title": "Edge Cloud als Netzwerkgrenze für verteilte Cluster",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/edge-cloud-als-netzwerkgrenze-fur-verteilte-cluster/edge-cloud-als-netzwerkgrenze-fur-verteilte-cluster.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eEine verteilte \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n-Landschaft braucht eine klare Grenze zwischen öffentlichem Traffic und interner Compute-Infrastruktur. Eine Edge Cloud übernimmt diese Grenze, bündelt Routing, Schutz und Failover und hält Backends verborgen. Eigenes Autonomous System und eigene Netzwerkinfrastruktur schaffen dabei eine unabhängige Grundlage für Multi-PoP- und Aktiv-Aktiv-Architekturen.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eViele \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n-Architekturen behandeln den öffentlichen Eingang als Bestandteil des Clusters. Das wirkt zunächst einfach, koppelt jedoch Internet-Routing, Schutzfunktionen und Applikationsbetrieb an dieselbe Compute-Ebene. Bei mehreren Clustern, Providern oder Regionen wird diese Kopplung zum Betriebsrisiko: Traffic muss zwischen unterschiedlichen Ingress-Stacks verteilt werden, Failover-Logik liegt an mehreren Stellen und Backends bleiben direkt adressierbar. Eine belastbare \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n-Netzwerkarchitektur trennt deshalb drei Aufgaben: den öffentlichen Traffic-Eingang, die Verarbeitung an der Edge und die Ausführung der Workloads. Die Edge Cloud ist in diesem Modell keine zusätzliche \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n-Komponente, sondern eine eigenständige Netzwerkgrenze vor den Clustern.\u003c/p\u003e\n\u003ch2 id=\"1-edge-und-compute-erfüllen-unterschiedliche-aufgaben\"\u003e1. Edge und Compute erfüllen unterschiedliche Aufgaben\u003c/h2\u003e\n\u003cp\u003e\u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n verwaltet Workloads, Services, Ingress-Routen und die Kommunikation innerhalb oder zwischen Clustern. Diese Funktionen beantworten jedoch nicht automatisch die Frage, wie öffentlicher Traffic über mehrere Cluster, Provider oder Betriebsstandorte verteilt wird. Dafür braucht es eine vorgelagerte Ebene mit eigener Routing- und Ausfalllogik.\u003c/p\u003e\n\u003cp\u003eDie Edge Cloud übernimmt den öffentlichen Eingang vor den Anwendungen und APIs. Anycast-basiertes Layer-4- und Layer-7-Loadbalancing verteilt Verbindungen und HTTP-Anfragen, während Backend Health Checks und Failover die Erreichbarkeit der Compute-Ziele bewerten. TLS Termination, Web Application Firewall und DDoS Protection können ebenfalls an dieser Grenze stattfinden. Dadurch erhalten die Cluster nicht die Aufgabe, jeden externen Traffic selbst zu terminieren, zu prüfen und zu verteilen.\u003c/p\u003e\n\u003cp\u003eDiese Trennung reduziert die Kopplung zwischen Netzwerkzugang und Workload-Lifecycle. Ein Cluster kann ersetzt, skaliert oder zu einem anderen Provider verlagert werden, ohne dass der öffentliche Einstieg vollständig neu modelliert werden muss. Die Edge bleibt dabei die steuernde Schicht für externe Erreichbarkeit; \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n bleibt für die Ausführung und interne Organisation der Anwendungen verantwortlich.\u003c/p\u003e\n\u003ch2 id=\"2-eine-netzwerkgrenze-für-mehrere-cluster\"\u003e2. Eine Netzwerkgrenze für mehrere Cluster\u003c/h2\u003e\n\u003cp\u003eIn einer verteilten Landschaft können mehrere \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n-Cluster parallel dieselbe Anwendung oder unterschiedliche Teile eines Dienstes betreiben. Ohne gemeinsame Edge entstehen häufig separate Ingress-Konfigurationen, individuelle DNS-Mechanismen und providerabhängige Eintrittspunkte. Das erschwert die zentrale Durchsetzung von Routing, Schutz und Failover und vergrößert die Zahl der Betriebsabhängigkeiten.\u003c/p\u003e\n\u003cp\u003eEine Multi-PoP-Architektur mit Aktiv-Aktiv-Prinzip verlagert diese Verantwortung an eine verteilte Edge-Ebene. Anycast DNS und Multi-Provider-DNS unterstützen dabei die Auflösung und Erreichbarkeit, während das Edge-Routing den Traffic zu geeigneten Backends führt. Die Backends können in ayedo Managed \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n, in eigenen Clustern oder bei anderen Providern betrieben werden. [Kubernetes]-native Integration ist damit nicht auf einen einzelnen Compute-Betrieb beschränkt.\u003c/p\u003e\n\u003cp\u003eWichtig ist die Richtung der Abhängigkeit: Die Cluster registrieren beziehungsweise bedienen Backends für die Edge, aber die öffentliche Netzwerkidentität der Anwendung muss nicht aus jedem Cluster separat exponiert werden. Backend Cloaking verhindert, dass interne Zielstrukturen zum öffentlichen Bestandteil der Architektur werden. Das vereinfacht Segmentierung und reduziert die Angriffsfläche, ersetzt aber keine korrekte Absicherung der Cluster selbst.\u003c/p\u003e\n\u003ch2 id=\"3-eigenes-autonomous-system-als-infrastrukturelle-grundlage\"\u003e3. Eigenes Autonomous System als infrastrukturelle Grundlage\u003c/h2\u003e\n\u003cp\u003eEin eigenes Autonomous System ist nicht automatisch ein Sicherheitsmerkmal und keine Garantie für Verfügbarkeit. Es schafft jedoch eine eigenständige Routing- und Identitätsbasis, auf der eine Edge-Plattform ihre Netzwerkinfrastruktur betreiben kann. Für Unternehmen ist das relevant, wenn der öffentliche Zugang nicht vollständig an die Netz- und Exponierungsmodelle einzelner Compute-Provider gebunden sein soll.\u003c/p\u003e\n\u003cp\u003eIn Kombination mit Bring Your Own IP kann die öffentliche Adressierung stärker an die Organisation und ihre Dienste gekoppelt werden. Die Compute-Ziele bleiben dabei hinter der Edge verborgen. Providerwechsel, Cluster-Migrationen oder die parallele Nutzung mehrerer Infrastrukturen müssen dann nicht zwangsläufig zu einem Wechsel des externen Einstiegspunkts führen.\u003c/p\u003e\n\u003cp\u003eDie technische Konsequenz ist eine klarere Zuständigkeit: Das Autonomous System und die eigene Netzwerkinfrastruktur bilden die Grundlage für den externen Pfad; die [Kubernetes]-Cluster verantworten die Anwendungen dahinter. Das reduziert organisatorische Reibung zwischen Netzwerk-, Plattform- und Applikationsteams. Gleichzeitig bleibt die Komplexität bestehen: Routing, IP-Adressmanagement, DNS, Zertifikate und Backend-Zustände müssen als zusammenhängendes Betriebsmodell dokumentiert und getestet werden.\u003c/p\u003e\n\u003ch2 id=\"4-betriebsfolgen-der-entkopplung\"\u003e4. Betriebsfolgen der Entkopplung\u003c/h2\u003e\n\u003cp\u003eDie Netzwerkgrenze wirkt sich direkt auf Incident Response und Änderungen aus. Fällt ein Cluster aus, kann die Edge den Zustand über Health Checks erkennen und Traffic auf verfügbare Backends lenken. Wird ein Cluster aktualisiert, bleibt der externe Zugang grundsätzlich an derselben Edge-Schicht verankert. Das ermöglicht gestaffelte Änderungen, sofern Anwendung und Datenhaltung die notwendige Mehrziel-Fähigkeit unterstützen.\u003c/p\u003e\n\u003cp\u003eAuch die Fehleranalyse wird strukturierter, wenn die Ebenen getrennt betrachtet werden. Ein Fehler kann im DNS, im Edge-Routing, bei TLS, in der WAF, im Backend-Pfad oder im [Kubernetes]-Service liegen. Traffic- und Usage-Statistiken an der Edge liefern dafür eine zusätzliche Sicht auf den öffentlichen Pfad, ersetzen aber keine Beobachtung der Cluster und Anwendungen.\u003c/p\u003e\n\u003cp\u003eDie Entkopplung hat außerdem wirtschaftliche Auswirkungen. Organisationen vermeiden, dass jeder zusätzliche Cluster einen vollständig neuen Internet-Einstieg mit eigenen Sicherheits- und Betriebsprozessen benötigt. Dem steht der Aufwand gegenüber, Edge-Regeln, Health Checks und Backends über mehrere Umgebungen konsistent zu betreiben. Der Vorteil entsteht daher nicht durch eine einzelne Funktion, sondern durch eine kontrollierte zentrale Grenze vor heterogener Compute-Infrastruktur.\u003c/p\u003e\n\u003ch2 id=\"praxis--und-architekturszenario\"\u003ePraxis- und Architekturszenario\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt eine Anwendung in zwei [Kubernetes]-Clustern: einen Cluster in ayedo Managed \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n und einen weiteren bei einem anderen Provider. Beide Cluster stellen dasselbe Backend bereit. In einer clusterzentrierten Architektur besitzt jeder Cluster einen eigenen öffentlichen Ingress, eigene DNS-Einträge und separate Schutzkonfigurationen. Ein Ausfall erfordert Änderungen an mehreren Stellen.\u003c/p\u003e\n\u003cp\u003eMit einer vorgeschalteten ayedo Edge Cloud zeigt der DNS-Eintrag auf die Edge. Dort werden TLS und definierte Schutzfunktionen verarbeitet, Health Checks prüfen beide Backends und das Routing verteilt den Traffic. Die Cluster bleiben über ihre Backend-Anbindung erreichbar, ohne ihre internen Zielstrukturen öffentlich auszustellen. Fällt ein Cluster aus, wird der Traffic an das verbleibende Ziel gelenkt. Die Compute-Ebene bleibt unterschiedlich, der öffentliche Netzwerkpfad jedoch konsistent.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"ist-die-edge-cloud-teil-des-kubernetes-clusters\"\u003eIst die Edge Cloud Teil des [Kubernetes]-Clusters?\u003c/h3\u003e\n\u003cp\u003eNein. Sie liegt als eigenständige Netzwerkgrenze vor den Clustern. [Kubernetes]-native Integration verbindet beide Ebenen, ohne die Edge Cloud auf ayedo Managed \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n zu beschränken.\u003c/p\u003e\n\u003ch3 id=\"ersetzt-edge-routing-das-kubernetes-service-netzwerk\"\u003eErsetzt Edge-Routing das [Kubernetes]-Service-Netzwerk?\u003c/h3\u003e\n\u003cp\u003eNein. Edge-Routing steuert den öffentlichen Eingang und die Verteilung zu Backends. Das [Kubernetes]-Service-Netzwerk organisiert die Kommunikation und Erreichbarkeit innerhalb der Compute-Umgebung.\u003c/p\u003e\n\u003ch3 id=\"warum-ist-backend-cloaking-bei-mehreren-clustern-relevant\"\u003eWarum ist Backend Cloaking bei mehreren Clustern relevant?\u003c/h3\u003e\n\u003cp\u003eEs verhindert, dass interne Backend-Ziele zum öffentlichen Bestandteil des Zugangs werden. Dadurch lassen sich Cluster und Provider hinter einer stabilen Edge-Adresse austauschen oder parallel betreiben.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eEine belastbare [Kubernetes]-Netzwerkarchitektur endet nicht am Ingress eines einzelnen Clusters. Bei verteilten Umgebungen braucht der öffentliche Traffic eine eigene, providerunabhängige Grenze, die Routing, Schutz, Termination und Failover bündelt. Eigenes Autonomous System und eigene Netzwerkinfrastruktur stärken diese Trennung auf der Netzwerkebene. Die ayedo Edge Cloud ordnet sich genau in dieses Modell ein: als verteilte Aktiv-Aktiv-Plattform vor unterschiedlichen [Kubernetes]- und Compute-Umgebungen, nicht als bloßes Add-on eines einzelnen Clusters.\u003c/p\u003e\n",
      "summary": "\nTL;DR Eine verteilte Kubernetes -Landschaft braucht eine klare Grenze zwischen öffentlichem Traffic und interner Compute-Infrastruktur. Eine Edge Cloud übernimmt diese Grenze, bündelt Routing, Schutz und Failover und hält Backends verborgen. Eigenes Autonomous System und eigene Netzwerkinfrastruktur schaffen dabei eine unabhängige Grundlage für Multi-PoP- und Aktiv-Aktiv-Architekturen.\nEinleitung Viele Kubernetes -Architekturen behandeln den öffentlichen Eingang als Bestandteil des Clusters. Das wirkt zunächst einfach, koppelt jedoch Internet-Routing, Schutzfunktionen und Applikationsbetrieb an dieselbe Compute-Ebene. Bei mehreren Clustern, Providern oder Regionen wird diese Kopplung zum Betriebsrisiko: Traffic muss zwischen unterschiedlichen Ingress-Stacks verteilt werden, Failover-Logik liegt an mehreren Stellen und Backends bleiben direkt adressierbar. Eine belastbare Kubernetes -Netzwerkarchitektur trennt deshalb drei Aufgaben: den öffentlichen Traffic-Eingang, die Verarbeitung an der Edge und die Ausführung der Workloads. Die Edge Cloud ist in diesem Modell keine zusätzliche Kubernetes -Komponente, sondern eine eigenständige Netzwerkgrenze vor den Clustern.\n",
      "image": "https://ayedo.de/edge-cloud-als-netzwerkgrenze-fur-verteilte-cluster.png",
      "date_published": "2026-09-02T14:12:29Z",
      "date_modified": "2026-09-02T14:12:29Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["kubernetes","operations","cloud-native","development","cloud"],
      "language": "de"
    },{
      "id": "https://ayedo.de/posts/ingress-und-api-traffic-zentral-an-der-edge-schutzen/",
      "url": "https://ayedo.de/posts/ingress-und-api-traffic-zentral-an-der-edge-schutzen/",
      "title": "Ingress- und API-Traffic zentral an der Edge schützen",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/ingress-und-api-traffic-zentral-an-der-edge-schutzen/ingress-und-api-traffic-zentral-an-der-edge-schutzen.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eKubernetes Ingress Security beginnt nicht erst im Cluster. Werden WAF, DDoS Protection, TLS Termination und Backend Cloaking am öffentlichen Eingang gebündelt, erreichen viele Angriffe und unnötige Verbindungsversuche die Cluster nicht. Eine Edge-Plattform schafft dabei eine zentrale Schutz- und Routingebene vor mehreren Backends.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eEin häufiger Architekturfehler besteht darin, jeden \u003ca href=\"/kubernetes/\"\u003eKubernetes-Service\u003c/a\u003e\n einzeln abzusichern und den öffentlichen Traffic möglichst direkt bis zum Cluster zu führen. Dadurch verteilen sich TLS-Konfiguration, Schutzregeln, Exponierung und Betriebsverantwortung auf viele Ingress-Ressourcen und Teams. Das erhöht die Angriffsfläche und erschwert konsistente Entscheidungen. Security-by-architecture setzt früher an: Eine zentrale Edge nimmt Verbindungen entgegen, prüft und filtert sie und leitet nur zulässigen Traffic an die vorgesehenen Backends weiter. Kubernetes bleibt für die Bereitstellung der Workloads verantwortlich, während der öffentliche Eingang unabhängig davon betrieben werden kann.\u003c/p\u003e\n\u003ch2 id=\"1-kubernetes-ingress-security-beginnt-vor-dem-cluster\"\u003e1. Kubernetes Ingress Security beginnt vor dem Cluster\u003c/h2\u003e\n\u003cp\u003eEin \u003ca href=\"/kubernetes/\"\u003eKubernetes Ingress\u003c/a\u003e\n beschreibt primär, wie HTTP- oder HTTPS-Anfragen innerhalb eines Clusters zu Services gelangen. Er ist deshalb nicht automatisch eine vollständige Sicherheitsarchitektur für den öffentlichen Eingang. Wird ein Ingress direkt aus dem Internet erreicht, muss der Cluster selbst Verbindungen annehmen, TLS verarbeiten, Requests bewerten und mit Überlast umgehen.\u003c/p\u003e\n\u003cp\u003eEine vorgelagerte Edge verschiebt diese Aufgaben an eine dedizierte Eingangsschicht. Dort können Routing und Sicherheitsrichtlinien zentral für mehrere Anwendungen, APIs und Cluster gelten. Das reduziert die Zahl öffentlich erreichbarer Komponenten und entkoppelt Schutzfunktionen von einzelnen Namespace- oder Service-Strukturen.\u003c/p\u003e\n\u003cp\u003eDiese Trennung hat auch organisatorische Folgen: Plattformteams verwalten zentrale Regeln, während Anwendungsteams ihre Services weiterhin über etablierte Kubernetes-Mechanismen bereitstellen. Die ayedo Edge Cloud bildet diesen öffentlichen Eingang vor Anwendungen und APIs. Sie kann mit ayedo Managed Kubernetes, eigenen Clustern oder Kubernetes-Umgebungen anderer Provider genutzt werden.\u003c/p\u003e\n\u003ch2 id=\"2-waf-und-ddos-protection-als-vorgelagerte-kontrollen\"\u003e2. WAF und DDoS Protection als vorgelagerte Kontrollen\u003c/h2\u003e\n\u003cp\u003eWAF und DDoS Protection adressieren unterschiedliche Risiken. Eine Web Application Firewall bewertet HTTP- und HTTPS-Anfragen anhand definierter Regeln. Sie kann beispielsweise auffällige Request-Muster, bestimmte Angriffsversuche oder unerwünschte Zugriffe blockieren, bevor diese einen Ingress oder eine API erreichen. Für APIs ist das besonders relevant, weil standardisierte Endpunkte häufig dauerhaft öffentlich erreichbar sind.\u003c/p\u003e\n\u003cp\u003eDDoS Protection setzt auf einer anderen Ebene an. Ziel ist, volumetrische oder protokollbezogene Überlastung abzufangen und schädlichen Traffic an der Edge zu behandeln. Ohne diese vorgelagerte Ebene müssen Cluster, Ingress-Komponenten und Netzwerkpfade zumindest einen Teil der Last verarbeiten, obwohl sie für legitime Workloads benötigt werden.\u003c/p\u003e\n\u003cp\u003eDie Kombination verbessert nicht nur die Security, sondern auch die Betriebsstabilität. Die ayedo Edge Cloud verbindet DDoS Protection und WAF für HTTP-/HTTPS-Services mit Anycast-basiertem Layer-4- und Layer-7-Loadbalancing. Dadurch wird Security nicht als nachträgliche Regel pro Service modelliert, sondern als Bestandteil des zentralen Traffic-Eingangs.\u003c/p\u003e\n\u003ch2 id=\"3-tls-termination-und-backend-cloaking-reduzieren-exponierung\"\u003e3. TLS Termination und Backend Cloaking reduzieren Exponierung\u003c/h2\u003e\n\u003cp\u003eTLS Termination an der Edge beendet verschlüsselte Verbindungen an einer kontrollierten Eingangsschicht. Dort werden Zertifikate und die erste Verarbeitung des HTTPS-Traffics zentralisiert. Zum Backend kann anschließend eine passend definierte Verbindung aufgebaut werden. Welche Verschlüsselungsstrecke erforderlich ist, bleibt eine Architekturentscheidung und muss zu Schutzbedarf, \u003ca href=\"/compliance/\"\u003eCompliance\u003c/a\u003e\n und Vertrauensgrenzen passen.\u003c/p\u003e\n\u003cp\u003eBackend Cloaking verfolgt ein anderes Ziel: Die eigentlichen Adressen und Strukturen der Backends werden nicht zum öffentlichen Bestandteil der Anwendungskommunikation. Clients kommunizieren mit der Edge, nicht direkt mit den Cluster-Endpunkten. Das erschwert direkte Zugriffe auf Ingress- oder Service-Adressen und verhindert, dass interne Routingstrukturen unnötig nach außen sichtbar werden.\u003c/p\u003e\n\u003cp\u003eCloaking ersetzt keine Authentisierung und keine WAF-Regeln. Es reduziert jedoch die öffentliche Angriffsfläche und schafft eine klare Netzgrenze. In der ayedo Edge Cloud lassen sich TLS Termination und Backend Cloaking mit Health Checks, Failover und zentralem Routing kombinieren. So bleibt der Cluster ein Backend der Plattform, statt selbst den gesamten öffentlichen Eingang abbilden zu müssen.\u003c/p\u003e\n\u003ch2 id=\"4-zentrale-security-über-mehrere-backends-hinweg\"\u003e4. Zentrale Security über mehrere Backends hinweg\u003c/h2\u003e\n\u003cp\u003eBei mehreren Clustern oder getrennten Umgebungen wird eine zentrale Edge besonders relevant. Ohne gemeinsame Eingangsschicht entstehen schnell unterschiedliche Ingress-Konfigurationen, voneinander abweichende WAF-Regeln und separate Verfahren für Failover oder Traffic-Auswertung. Sicherheitsentscheidungen werden dann an Infrastrukturgrenzen wiederholt, obwohl die Schutzanforderungen oft identisch sind.\u003c/p\u003e\n\u003cp\u003eEine Edge-Plattform kann diese Funktionen vor mehreren Backends bündeln und den Traffic anhand von Routing- und Health-Check-Ergebnissen verteilen. Das gilt auch dann, wenn die Backends bei unterschiedlichen Providern betrieben werden. Kubernetes-native Integration erleichtert die Anbindung von Clustern, ohne die Edge Cloud auf ayedo Managed Kubernetes zu begrenzen.\u003c/p\u003e\n\u003cp\u003eDer Trade-off liegt in der zusätzlichen Abstraktion: Teams müssen Routing, Zuständigkeiten, Zertifikate und Fehlerbilder über Edge und Cluster hinweg sauber definieren. Dafür entsteht ein konsistenterer Kontrollpunkt. Die ayedo Edge Cloud nutzt dafür eine verteilte Multi-PoP-Architektur, Anycast und ein Aktiv-Aktiv-Prinzip. Ihre eigene Netzwerk-Infrastruktur und ihr eigenes Autonomous System bilden dabei die Grundlage des öffentlichen Eingangs.\u003c/p\u003e\n\u003ch2 id=\"praxis--und-betriebsszenario\"\u003ePraxis- und Betriebsszenario\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt eine öffentliche API in zwei Kubernetes-Clustern: einen Cluster in der eigenen Infrastruktur und einen weiteren bei einem externen Provider. Beide Ingress-Komponenten bleiben intern erreichbar und veröffentlichen keine direkten Backend-Adressen. Clients greifen auf einen gemeinsamen öffentlichen Endpoint der Edge zu.\u003c/p\u003e\n\u003cp\u003eDie Edge übernimmt TLS Termination, prüft HTTP-Anfragen mit der WAF und behandelt auffälligen Traffic über DDoS Protection. Health Checks erkennen, wenn ein Backend nicht verfügbar ist; anschließend wird der Traffic auf das verbleibende Backend geleitet. Im Vergleich zu zwei unabhängig exponierten Ingresses liegen Schutzregeln, Routing und Failover an einer gemeinsamen Stelle. Dafür müssen Teams die Zuständigkeit zwischen Edge-Konfiguration und Kubernetes-Deployment eindeutig dokumentieren.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"ist-kubernetes-ingress-security-mit-einem-ingress-controller-allein-ausreichend\"\u003eIst Kubernetes Ingress Security mit einem Ingress Controller allein ausreichend?\u003c/h3\u003e\n\u003cp\u003eEin Ingress Controller regelt primär Routing im Cluster. Für öffentlichen Schutz vor DDoS, zentrale WAF-Regeln und die Abschirmung der Backend-Adressen ist eine vorgelagerte Edge-Architektur erforderlich.\u003c/p\u003e\n\u003ch3 id=\"ersetzt-backend-cloaking-eine-waf\"\u003eErsetzt Backend Cloaking eine WAF?\u003c/h3\u003e\n\u003cp\u003eNein. Backend Cloaking reduziert die direkte Exponierung der Backends. Eine WAF bewertet dagegen Requests und blockiert bestimmte Angriffsmuster. Beide Kontrollen adressieren unterschiedliche Risiken.\u003c/p\u003e\n\u003ch3 id=\"muss-kubernetes-bei-ayedo-betrieben-werden\"\u003eMuss Kubernetes bei ayedo betrieben werden?\u003c/h3\u003e\n\u003cp\u003eNein. Die ayedo Edge Cloud kann mit ayedo Managed Kubernetes sowie mit eigenen oder bei anderen Providern betriebenen Kubernetes-Clustern genutzt werden.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eKubernetes Ingress Security sollte als Frage der Systemarchitektur betrachtet werden, nicht nur als Konfiguration einzelner Services. WAF, DDoS Protection, TLS Termination und Backend Cloaking wirken am stärksten, wenn sie vor dem Cluster als zusammenhängende Eingangsschicht eingesetzt werden. Die ayedo Edge Cloud ordnet diese Funktionen vor mehreren Backends ein und trennt öffentlichen Traffic-Eingang von der eigentlichen Compute-Infrastruktur. Dadurch werden Schutz, Routing und Backend-Exponierung unabhängig vom jeweiligen Kubernetes-Provider steuerbar.\u003c/p\u003e\n",
      "summary": "\nTL;DR Kubernetes Ingress Security beginnt nicht erst im Cluster. Werden WAF, DDoS Protection, TLS Termination und Backend Cloaking am öffentlichen Eingang gebündelt, erreichen viele Angriffe und unnötige Verbindungsversuche die Cluster nicht. Eine Edge-Plattform schafft dabei eine zentrale Schutz- und Routingebene vor mehreren Backends.\nEinleitung Ein häufiger Architekturfehler besteht darin, jeden Kubernetes-Service einzeln abzusichern und den öffentlichen Traffic möglichst direkt bis zum Cluster zu führen. Dadurch verteilen sich TLS-Konfiguration, Schutzregeln, Exponierung und Betriebsverantwortung auf viele Ingress-Ressourcen und Teams. Das erhöht die Angriffsfläche und erschwert konsistente Entscheidungen. Security-by-architecture setzt früher an: Eine zentrale Edge nimmt Verbindungen entgegen, prüft und filtert sie und leitet nur zulässigen Traffic an die vorgesehenen Backends weiter. Kubernetes bleibt für die Bereitstellung der Workloads verantwortlich, während der öffentliche Eingang unabhängig davon betrieben werden kann.\n",
      "image": "https://ayedo.de/ingress-und-api-traffic-zentral-an-der-edge-schutzen.png",
      "date_published": "2026-09-02T14:12:29Z",
      "date_modified": "2026-09-02T14:12:29Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["kubernetes","security","platform","cloud-native","development"],
      "language": "de"
    },{
      "id": "https://ayedo.de/posts/kubernetes-mit-eigener-edge-anbindung-produktiv-betreiben/",
      "url": "https://ayedo.de/posts/kubernetes-mit-eigener-edge-anbindung-produktiv-betreiben/",
      "title": "Kubernetes mit eigener Edge-Anbindung produktiv betreiben",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/kubernetes-mit-eigener-edge-anbindung-produktiv-betreiben/kubernetes-mit-eigener-edge-anbindung-produktiv-betreiben.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eKubernetes-Compute und öffentlicher Anwendungseingang müssen nicht beim selben Provider liegen. Eine unabhängige Edge-Schicht übernimmt Anycast, DNS, Loadbalancing, TLS, Schutzfunktionen und Backend-Cloaking, während der Cluster beim gewählten Provider oder im eigenen Rechenzentrum betrieben wird. Entscheidend ist eine klare Rollenverteilung zwischen Edge, Netzwerk und Compute.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eEin \u003ca href=\"/kubernetes/\"\u003eKubernetes-Cluster\u003c/a\u003e\n ist nicht automatisch ein geeigneter öffentlicher Einstiegspunkt für produktive Anwendungen. Wird der Cluster direkt über Provider-Loadbalancer, öffentliche Node-Adressen oder providergebundene DNS-Strukturen exponiert, entstehen enge Kopplungen zwischen Compute, Netzwerk und Security. Ein Wechsel des Providers oder der Aufbau eines zweiten Clusters wird dadurch unnötig komplex.\u003c/p\u003e\n\u003cp\u003eEine belastbare Infrastrukturstrategie trennt deshalb zwei Verantwortungsbereiche: Die Compute-Infrastruktur führt Pods, Services und Anwendungen aus. Eine vorgelagerte Edge-Plattform kontrolliert den öffentlichen Traffic, schützt die Anwendungen und verteilt Anfragen auf erreichbare Backends. Diese Trennung schafft Kubernetes Providerunabhängigkeit, verlangt aber eine sauber geplante Cluster-Anbindung.\u003c/p\u003e\n\u003ch2 id=\"1-rollenverteilung-zwischen-edge-und-kubernetes-compute\"\u003e1. Rollenverteilung zwischen Edge und Kubernetes-Compute\u003c/h2\u003e\n\u003cp\u003eDie Edge Cloud bildet den öffentlichen Eingang vor einer Anwendung. Dort enden öffentliche Verbindungen, werden DNS-Anfragen beantwortet, TLS-Verbindungen terminiert und eingehende Requests über Layer 4 oder Layer 7 an geeignete Backends verteilt. Der \u003ca href=\"/kubernetes/\"\u003eKubernetes-Cluster\u003c/a\u003e\n muss dadurch nicht selbst sämtliche Funktionen für Internetzugang, Traffic-Verteilung und Schutz bereitstellen.\u003c/p\u003e\n\u003cp\u003eDie Compute-Infrastruktur bleibt für Workloads, Services, Skalierung und die interne Kommunikation verantwortlich. Ihre Aufgabe ist, die von der Edge weitergeleiteten Verbindungen zuverlässig entgegenzunehmen. Diese Trennung gilt unabhängig davon, ob der Cluster bei ayedo, einem anderen Cloud-Provider oder auf eigener Infrastruktur betrieben wird.\u003c/p\u003e\n\u003cp\u003eArchitektonisch entsteht damit eine lose Kopplung: Der öffentliche Endpunkt bleibt stabil, während sich Cluster, Nodes oder sogar der Betreiber der Compute-Plattform ändern können. Backend Health Checks und Failover unterstützen dabei, nur erreichbare Ziele in die Weiterleitung einzubeziehen. Voraussetzung ist eine definierte Erreichbarkeit zwischen Edge und Backend sowie eine klare Zuständigkeit für Routing und Betrieb.\u003c/p\u003e\n\u003ch2 id=\"2-öffentlicher-einstiegspunkt-mit-anycast-und-dns\"\u003e2. Öffentlicher Einstiegspunkt mit Anycast und DNS\u003c/h2\u003e\n\u003cp\u003eFür produktive Services reicht es nicht, lediglich eine IP-Adresse vor den Cluster zu setzen. Der öffentliche Einstiegspunkt muss DNS, Routing und Ausfallszenarien berücksichtigen. Anycast kann den Zugriff über eine verteilte Edge-Infrastruktur aufnehmen und an die dafür vorgesehenen Verarbeitungspunkte führen. Das reduziert die Abhängigkeit von einem einzelnen Standort oder einem einzelnen Netzwerkpfad.\u003c/p\u003e\n\u003cp\u003eAnycast DNS und Multi-Provider-DNS adressieren unterschiedliche Ebenen der Verfügbarkeit. Anycast DNS verteilt die Beantwortung von DNS-Anfragen über die Edge. Multi-Provider-DNS kann zusätzlich vermeiden, dass die Namensauflösung vollständig an einen einzelnen DNS-Anbieter gebunden ist. Beide Mechanismen ersetzen jedoch keine Backend-Überwachung: Wenn der Cluster nicht erreichbar ist, muss die Edge dies erkennen und entsprechend reagieren.\u003c/p\u003e\n\u003cp\u003eFür Unternehmen mit eigener Adressierung kann Bring Your Own IP relevant sein. Die öffentlichen IP-Ressourcen bleiben dabei Teil der eigenen Infrastrukturstrategie, während die Verarbeitung und Weiterleitung des Traffics an der Edge erfolgt. Entscheidend ist, dass DNS, IP-Adressierung und Backend-Ziele als getrennte Designentscheidungen betrachtet werden.\u003c/p\u003e\n\u003ch2 id=\"3-security-und-backend-cloaking-an-der-edge\"\u003e3. Security und Backend-Cloaking an der Edge\u003c/h2\u003e\n\u003cp\u003eWird ein \u003ca href=\"/kubernetes/\"\u003eKubernetes-Service\u003c/a\u003e\n direkt öffentlich erreichbar gemacht, sind Backend-Adressen, Portstrukturen und Schutzmechanismen näher am Internet exponiert als nötig. Eine Edge Cloud kann diese Angriffs- und Abhängigkeitspunkte reduzieren, indem sie die öffentlichen Funktionen vor dem Cluster bündelt. Backend Cloaking verhindert, dass die eigentlichen Backend-Ziele zum Bestandteil der externen Zugriffsschnittstelle werden.\u003c/p\u003e\n\u003cp\u003eFür HTTP- und HTTPS-Anwendungen kann die Web Application Firewall schädliche oder unerwünschte Requests vor der Weiterleitung prüfen. DDoS Protection und Scrubbing verlagern die Abwehr volumetrischer Angriffe an die Edge. TLS Termination beendet die öffentliche Verschlüsselung dort, wo auch Routing und Policy-Entscheidungen getroffen werden. Welche Verschlüsselung anschließend zwischen Edge und Backend erforderlich ist, bleibt eine separate Sicherheitsentscheidung.\u003c/p\u003e\n\u003cp\u003eProxy Protocol kann relevante Informationen der ursprünglichen Verbindung an das Backend weitergeben, sofern die nachgelagerte Infrastruktur dies unterstützt. Security endet deshalb nicht an der Edge: Netzwerkzugänge, Firewall-Regeln, Authentifizierung und die Verarbeitung weitergereichter Verbindungsinformationen müssen im Cluster weiterhin kontrolliert werden.\u003c/p\u003e\n\u003ch2 id=\"4-cluster-anbindung-und-betriebsmodell\"\u003e4. Cluster-Anbindung und Betriebsmodell\u003c/h2\u003e\n\u003cp\u003eEine providerunabhängige Edge-Anbindung ist nur dann belastbar, wenn der Übergang zum Cluster betrieblich eindeutig definiert ist. Dazu gehören erreichbare Backend-Endpunkte, Health Checks, Failover-Regeln und die Frage, wie Änderungen an Services oder Ingress-Konfigurationen an die Edge gelangen. Kubernetes-native Integration kann diese Verbindung automatisieren, ohne die Compute-Infrastruktur an ayedo Managed Kubernetes zu binden.\u003c/p\u003e\n\u003cp\u003eDas ist besonders relevant für Organisationen mit mehreren Betriebsmodellen: Ein Cluster kann im eigenen Rechenzentrum laufen, ein zweiter bei einem Cloud-Provider und ein dritter in einer getrennten Umgebung. Die Edge-Funktionen bleiben dabei zentral: öffentlicher DNS, TLS, WAF, DDoS-Schutz, Loadbalancing und Traffic-Statistiken werden nicht pro Cluster neu aufgebaut.\u003c/p\u003e\n\u003cp\u003eDie Betriebsverantwortung verschiebt sich dadurch nicht einfach, sondern wird klarer aufgeteilt. Das Plattformteam verantwortet Cluster und Workloads; das Netzwerk- oder Edge-Team verantwortet öffentliche Erreichbarkeit, Routing und Schutz. Ein eigenes Autonomous System und eigene Netzwerk-Infrastruktur der Edge-Plattform bilden dabei einen eigenständigen Netzwerkkontext zwischen Internet und Compute.\u003c/p\u003e\n\u003ch2 id=\"praxisszenario-clusterwechsel-ohne-änderung-des-öffentlichen-endpunkts\"\u003ePraxisszenario: Clusterwechsel ohne Änderung des öffentlichen Endpunkts\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt eine Webanwendung zunächst in einem \u003ca href=\"/kubernetes/\"\u003eKubernetes-Cluster\u003c/a\u003e\n bei Provider A. Der öffentliche DNS-Name zeigt auf die Edge, nicht direkt auf Nodes oder einen providergebundenen Loadbalancer. Die Edge terminiert TLS, prüft HTTP-Anfragen mit der WAF und leitet den Traffic an die Backends weiter.\u003c/p\u003e\n\u003cp\u003eSpäter wird die Anwendung in einen Cluster im eigenen Rechenzentrum migriert. Während der Übergangsphase prüfen Health Checks beide Backend-Gruppen. Nach erfolgreicher Validierung wird das neue Ziel priorisiert; der öffentliche DNS-Name und die Edge-Policies bleiben unverändert. Der Migrationsaufwand konzentriert sich dadurch auf die Cluster-Anbindung und nicht auf den Austausch sämtlicher Internet-, TLS- und Security-Komponenten.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"ist-eine-edge-cloud-nur-für-ayedo-managed-kubernetes-geeignet\"\u003eIst eine Edge Cloud nur für ayedo Managed Kubernetes geeignet?\u003c/h3\u003e\n\u003cp\u003eNein. Die ayedo Edge Cloud kann auch mit \u003ca href=\"/kubernetes/\"\u003eKubernetes-Clustern\u003c/a\u003e\n auf eigener Infrastruktur oder bei anderen Providern genutzt werden. Edge und Compute bleiben dabei getrennte Verantwortungsbereiche.\u003c/p\u003e\n\u003ch3 id=\"muss-kubernetes-weiterhin-öffentlich-erreichbar-sein\"\u003eMuss Kubernetes weiterhin öffentlich erreichbar sein?\u003c/h3\u003e\n\u003cp\u003eNicht zwingend. Die Edge kann als öffentlicher Eingang dienen und Backend-Ziele verbergen. Die konkrete Erreichbarkeit zwischen Edge und Cluster muss jedoch netzwerkseitig geplant und abgesichert werden.\u003c/p\u003e\n\u003ch3 id=\"welche-rolle-spielt-dns-bei-einer-providerunabhängigen-architektur\"\u003eWelche Rolle spielt DNS bei einer providerunabhängigen Architektur?\u003c/h3\u003e\n\u003cp\u003eDNS veröffentlicht den stabilen Anwendungseinstieg, sollte aber nicht mit Backend-Routing verwechselt werden. Anycast DNS und Multi-Provider-DNS können die Abhängigkeit von einzelnen DNS-Strukturen reduzieren.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eKubernetes Providerunabhängigkeit entsteht nicht allein durch die Wahl eines portablen Cluster-Setups. Sie erfordert eine Entkopplung des öffentlichen Anwendungseingangs von der Compute-Plattform. Eine Edge Cloud übernimmt dabei Routing, DNS, TLS, Schutz und Failover, während \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n auf die Ausführung der Workloads fokussiert bleibt. Die ayedo Edge Cloud unterstützt dieses Modell mit eigener Netzwerk-Infrastruktur, eigenem Autonomous System, Aktiv-Aktiv-Architektur und Kubernetes-Integration über unterschiedliche Betriebsumgebungen hinweg.\u003c/p\u003e\n",
      "summary": "\nTL;DR Kubernetes-Compute und öffentlicher Anwendungseingang müssen nicht beim selben Provider liegen. Eine unabhängige Edge-Schicht übernimmt Anycast, DNS, Loadbalancing, TLS, Schutzfunktionen und Backend-Cloaking, während der Cluster beim gewählten Provider oder im eigenen Rechenzentrum betrieben wird. Entscheidend ist eine klare Rollenverteilung zwischen Edge, Netzwerk und Compute.\nEinleitung Ein Kubernetes-Cluster ist nicht automatisch ein geeigneter öffentlicher Einstiegspunkt für produktive Anwendungen. Wird der Cluster direkt über Provider-Loadbalancer, öffentliche Node-Adressen oder providergebundene DNS-Strukturen exponiert, entstehen enge Kopplungen zwischen Compute, Netzwerk und Security. Ein Wechsel des Providers oder der Aufbau eines zweiten Clusters wird dadurch unnötig komplex.\n",
      "image": "https://ayedo.de/kubernetes-mit-eigener-edge-anbindung-produktiv-betreiben.png",
      "date_published": "2026-09-02T14:12:29Z",
      "date_modified": "2026-09-02T14:12:29Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["kubernetes","security","cloud-native","operations","hosting"],
      "language": "de"
    },{
      "id": "https://ayedo.de/posts/kubernetes-dns-und-edge-routing-uber-providergrenzen-betreiben/",
      "url": "https://ayedo.de/posts/kubernetes-dns-und-edge-routing-uber-providergrenzen-betreiben/",
      "title": "Kubernetes-DNS und Edge-Routing über Providergrenzen betreiben",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/kubernetes-dns-und-edge-routing-uber-providergrenzen-betreiben/kubernetes-dns-und-edge-routing-uber-providergrenzen-betreiben.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eIn einer \u003ca href=\"/kubernetes/\"\u003eKubernetes-Multi-Cloud-Umgebung\u003c/a\u003e\n 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.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003e\u003ca href=\"/kubernetes/\"\u003eKubernetes-DNS\u003c/a\u003e\n 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.\u003c/p\u003e\n\u003cp\u003eDer 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.\u003c/p\u003e\n\u003ch2 id=\"1-drei-dns-ebenen-sauber-trennen\"\u003e1. Drei DNS-Ebenen sauber trennen\u003c/h2\u003e\n\u003cp\u003eKubernetes-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 \u003ccode\u003eapi.namespace.svc\u003c/code\u003e ist kein geeignetes Ziel für Clients außerhalb des Clusters.\u003c/p\u003e\n\u003cp\u003eFü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.\u003c/p\u003e\n\u003cp\u003eDiese 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.\u003c/p\u003e\n\u003ch2 id=\"2-dns--und-routing-lebenszyklen-synchronisieren\"\u003e2. DNS- und Routing-Lebenszyklen synchronisieren\u003c/h2\u003e\n\u003cp\u003eDie 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.\u003c/p\u003e\n\u003cp\u003eTTL-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.\u003c/p\u003e\n\u003cp\u003eFü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.\u003c/p\u003e\n\u003ch2 id=\"3-multi-provider-dns-und-edge-failover-unterscheiden\"\u003e3. Multi-Provider-DNS und Edge-Failover unterscheiden\u003c/h2\u003e\n\u003cp\u003eMulti-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.\u003c/p\u003e\n\u003cp\u003eDeshalb sollte der öffentliche Hostname idealerweise auf einen stabilen, providerunabhängig betriebenen Edge-Einstieg zeigen. Die Edge kann anschließend mehrere \u003ca href=\"/kubernetes/\"\u003eKubernetes-Cluster\u003c/a\u003e\n 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.\u003c/p\u003e\n\u003cp\u003eBei 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.\u003c/p\u003e\n\u003ch2 id=\"4-betrieb-sicherheit-und-zuständigkeiten-festlegen\"\u003e4. Betrieb, Sicherheit und Zuständigkeiten festlegen\u003c/h2\u003e\n\u003cp\u003eProviderü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.\u003c/p\u003e\n\u003cp\u003eTechnisch 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.\u003c/p\u003e\n\u003cp\u003eDie 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.\u003c/p\u003e\n\u003ch2 id=\"betriebsszenario-zwei-cluster-ein-öffentlicher-hostname\"\u003eBetriebsszenario: Zwei Cluster, ein öffentlicher Hostname\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt einen \u003ca href=\"/kubernetes/\"\u003eKubernetes-Cluster\u003c/a\u003e\n 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.\u003c/p\u003e\n\u003cp\u003eBei 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.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"ist-kubernetes-dns-für-öffentliche-anwendungen-ausreichend\"\u003eIst Kubernetes-DNS für öffentliche Anwendungen ausreichend?\u003c/h3\u003e\n\u003cp\u003eNein. 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.\u003c/p\u003e\n\u003ch3 id=\"wann-ist-dns-failover-sinnvoll\"\u003eWann ist DNS Failover sinnvoll?\u003c/h3\u003e\n\u003cp\u003eDNS 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.\u003c/p\u003e\n\u003ch3 id=\"muss-kubernetes-bei-ayedo-betrieben-werden\"\u003eMuss Kubernetes bei ayedo betrieben werden?\u003c/h3\u003e\n\u003cp\u003eNein. 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.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eProviderübergreifendes \u003ca href=\"/kubernetes/\"\u003eKubernetes-DNS\u003c/a\u003e\n 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.\u003c/p\u003e\n",
      "summary": "\nTL;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.\nEinleitung 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.\n",
      "image": "https://ayedo.de/kubernetes-dns-und-edge-routing-uber-providergrenzen-betreiben.png",
      "date_published": "2026-09-02T14:12:29Z",
      "date_modified": "2026-09-02T14:12:29Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["kubernetes","cloud-native","automation","cloud","software-delivery"],
      "language": "de"
    },{
      "id": "https://ayedo.de/posts/kubernetes-failover-fur-ingress-und-api-server-planen/",
      "url": "https://ayedo.de/posts/kubernetes-failover-fur-ingress-und-api-server-planen/",
      "title": "Kubernetes-Failover für Ingress und API Server planen",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/kubernetes-failover-fur-ingress-und-api-server-planen/kubernetes-failover-fur-ingress-und-api-server-planen.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eEin belastbares \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n Ingress Failover beginnt nicht beim DNS, sondern bei klar definierten Fehlerbildern und aussagekräftigen Backend Health Checks. Aktiv-Aktiv-Architekturen verkürzen Ausfallzeiten, lösen aber weder fehlerhafte Anwendungen noch unklare Zuständigkeiten. Die Edge muss Status, Routing und Failover unabhängig von einzelnen Clustern bewerten.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eKubernetes-Hochverfügbarkeit scheitert häufig an einer falschen Annahme: Wenn mehrere Cluster existieren, ist der Dienst automatisch ausfallsicher. Tatsächlich kann ein Cluster erreichbar sein, während der Ingress keine Anfragen mehr verarbeitet, ein Netzwerkpfad gestört ist oder der \u003ca href=\"/kubernetes/\"\u003eKubernetes API Server\u003c/a\u003e\n nicht antwortet. Für Kubernetes Ingress Failover müssen deshalb drei Ebenen getrennt betrachtet werden: der öffentliche Zugang, die Erreichbarkeit des Backends und die Funktionsfähigkeit des Dienstes. Erst daraus lässt sich ableiten, wann Traffic umgelenkt werden darf und wann ein Failover lediglich einen bereits bestehenden Fehler weiterverteilt.\u003c/p\u003e\n\u003ch2 id=\"1-fehlerbilder-vor-dem-failover-definieren\"\u003e1. Fehlerbilder vor dem Failover definieren\u003c/h2\u003e\n\u003cp\u003eEin Cluster-Ausfall ist nur eines von mehreren relevanten Szenarien. Ein kompletter Verlust eines Clusters ist vergleichsweise eindeutig: Der externe Endpunkt antwortet nicht, und ein alternatives Backend kann den Traffic übernehmen. Schwieriger sind partielle Fehler. Dazu gehören nicht erreichbare Nodes, ein ausgefallener Ingress, blockierte Netzwerkpfade oder ein Backend, das TCP-Verbindungen annimmt, aber HTTP-Anfragen nicht korrekt verarbeitet.\u003c/p\u003e\n\u003cp\u003eFür die Planung ist deshalb eine Fehler-Matrix sinnvoll. Sie ordnet jedem Fehlerbild eine Erkennung, eine Aktion und eine Rückkehrstrategie zu. Ein Health Check auf Portebene erkennt beispielsweise keine fehlerhafte Anwendungsschicht. Ein HTTP-Check kann dagegen einen definierten Pfad und Statuscode prüfen. Für den Kubernetes API Server gelten andere Kriterien als für eine veröffentlichte Anwendung: Er muss über den vorgesehenen Endpoint erreichbar sein und eine für den Betriebsfall ausreichende Antwort liefern.\u003c/p\u003e\n\u003cp\u003eDiese Unterscheidung verhindert, dass ein scheinbar gesundes, aber funktionsloses Backend weiterhin Traffic erhält.\u003c/p\u003e\n\u003ch2 id=\"2-backend-health-checks-müssen-zum-dienst-passen\"\u003e2. Backend Health Checks müssen zum Dienst passen\u003c/h2\u003e\n\u003cp\u003eBackend Health Checks sind kein rein technisches Detail, sondern eine Routing-Entscheidung mit direkten Betriebsfolgen. Für einen Ingress sollte der Check möglichst die relevante Anwendungskette abbilden: TLS beziehungsweise HTTP-Erreichbarkeit, Routing zum Service und ein definierter Health-Endpunkt. Dabei darf der Prüfpfad nicht von einer Funktion abhängen, die bei hoher Last absichtlich deaktiviert wird. Ebenso sollten Checks keine schreibenden Operationen auslösen.\u003c/p\u003e\n\u003cp\u003eBei API-Servern steht dagegen die Erreichbarkeit des Control-Plane-Endpunkts im Vordergrund. Ein Check muss zwischen temporärer Überlastung, Netzwerkfehler und dauerhaftem Ausfall unterscheiden können. Zu aggressive Schwellenwerte erzeugen unnötiges Failover und Flapping; zu großzügige Werte verlängern die Störung.\u003c/p\u003e\n\u003cp\u003eDie ayedo Edge Cloud kann Backends über Health Checks überwachen und bei Ausfall Failover auslösen. Entscheidend bleibt die korrekte Definition des Prüfmodells: Die Edge bewertet die Erreichbarkeit des veröffentlichten Backends, nicht automatisch den Zustand aller Kubernetes-Ressourcen dahinter.\u003c/p\u003e\n\u003ch2 id=\"3-aktiv-aktiv-mit-mehreren-clustern-entwerfen\"\u003e3. Aktiv-Aktiv mit mehreren Clustern entwerfen\u003c/h2\u003e\n\u003cp\u003eEine Aktiv-Aktiv-Architektur verteilt Anfragen gleichzeitig auf mehrere gesunde Backends. Das reduziert die Abhängigkeit von einem einzelnen Cluster und erlaubt, Kapazität sowie Wartungsarbeiten über mehrere Standorte oder Provider zu verteilen. Gleichzeitig steigen die Anforderungen an Zustandsdaten, Datenbankzugriffe, Sessions und konsistente Konfigurationen. Stateless HTTP-Services eignen sich typischerweise besser als zustandsgebundene Anwendungen.\u003c/p\u003e\n\u003cp\u003eBei Kubernetes Ingress Failover muss außerdem geklärt sein, ob beide Cluster denselben Hostnamen, dieselben Zertifikatsannahmen und kompatible API-Verträge bedienen. Andernfalls kann ein technisch erreichbares Backend fachlich ungeeignete Antworten liefern. Für den API Server ist die Situation noch sensibler: Mehrere Cluster sind keine gemeinsame Control Plane. Jeder Endpoint repräsentiert einen eigenen Cluster mit eigener Ressourcensicht und eigenen Berechtigungen.\u003c/p\u003e\n\u003cp\u003eDie Edge Cloud kann mehrere Backends providerunabhängig veröffentlichen und zwischen ihnen verteilen. Aktiv-Aktiv entsteht jedoch erst durch die Kombination aus Edge-Routing, kompatiblen Workloads und einem konsistenten Betriebsmodell.\u003c/p\u003e\n\u003ch2 id=\"4-failover-braucht-rückfall--und-betriebsregeln\"\u003e4. Failover braucht Rückfall- und Betriebsregeln\u003c/h2\u003e\n\u003cp\u003eFailover endet nicht mit der Umschaltung. Sobald ein Backend wieder erreichbar ist, muss geregelt sein, wann es erneut Traffic erhält. Ein sofortiger Rückfall kann eine instabile Umgebung erneut belasten. Sinnvoll sind daher getrennte Kriterien für Ausfall und Wiederaufnahme, ergänzt durch Beobachtung der Traffic- und Usage-Statistiken. Diese zeigen, ob die Umschaltung tatsächlich den erwarteten Entlastungseffekt erzielt.\u003c/p\u003e\n\u003cp\u003eAuch die Fehlerdomäne der Edge ist relevant. Wenn DNS, Routing und Backendzugang an dieselbe Infrastruktur gekoppelt sind, kann ein einzelner Ausfall mehrere Funktionen gleichzeitig beeinträchtigen. Anycast DNS und Multi-Provider-DNS adressieren unterschiedliche Teile dieses Risikos; sie ersetzen aber keine gesunden Backends. Die ayedo Edge Cloud verbindet Anycast-basiertes Layer-4- und Layer-7-Loadbalancing mit Backend Health Checks, Failover und einer verteilten Aktiv-Aktiv-Architektur. Dadurch liegt die Entscheidung über den öffentlichen Traffic-Eingang vor den Clustern und kann unabhängig von ayedo Managed Kubernetes genutzt werden.\u003c/p\u003e\n\u003ch2 id=\"praxis--und-betriebsszenario\"\u003ePraxis- und Betriebsszenario\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt einen Ingress in zwei Kubernetes-Clustern bei unterschiedlichen Providern. Beide Backends sind zunächst aktiv. Der Health Check prüft einen dedizierten HTTP-Endpunkt, der zentrale Abhängigkeiten berücksichtigt, aber keine schreibende Aktion ausführt.\u003c/p\u003e\n\u003cp\u003eFällt ein Cluster vollständig aus, entfernt die Edge das Backend aus der Verteilung. Ist nur der Netzwerkpfad zu einem Cluster gestört, führt dasselbe Verhalten zu einer kontrollierten Umschaltung. Antwortet der Ingress zwar, liefert die Anwendung aber Fehler, muss der HTTP-Check diesen Zustand erkennen. Beim API Server wird ein separater Backend-Pool verwendet, weil seine Erreichbarkeit und Betriebslogik nicht mit dem Ingress identisch sind. Nach der Wiederherstellung bleibt das Backend zunächst außerhalb des aktiven Routings und wird erst nach stabilen Checks wieder aufgenommen.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"ist-dns-failover-allein-ausreichend\"\u003eIst DNS-Failover allein ausreichend?\u003c/h3\u003e\n\u003cp\u003eNein. DNS kann Clients zu einem anderen Endpoint lenken, erkennt aber nicht zuverlässig jede Anwendungsschichtstörung. Health Checks und Routing an der Edge ermöglichen eine kontrolliertere Reaktion.\u003c/p\u003e\n\u003ch3 id=\"muss-kubernetes-ingress-failover-immer-aktiv-aktiv-sein\"\u003eMuss Kubernetes Ingress Failover immer Aktiv-Aktiv sein?\u003c/h3\u003e\n\u003cp\u003eNein. Aktiv-Passiv kann für zustandsbehaftete Systeme einfacher sein. Aktiv-Aktiv reduziert jedoch ungenutzte Kapazität und eignet sich für kompatible, ausreichend entkoppelte Workloads.\u003c/p\u003e\n\u003ch3 id=\"sollte-der-api-server-wie-ein-normaler-ingress-behandelt-werden\"\u003eSollte der API Server wie ein normaler Ingress behandelt werden?\u003c/h3\u003e\n\u003cp\u003eNein. Der API Server ist ein Control-Plane-Endpunkt mit eigener Sicherheits- und Betriebslogik. Health Checks, Zugriffsregeln und Failover müssen separat geplant werden.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eKubernetes-Failover ist eine Frage des Fehler- und Zustandsmodells, nicht nur der Anzahl vorhandener Cluster. Backend Health Checks müssen zum jeweiligen Dienst passen, Failover-Regeln müssen Netzwerk- und Anwendungsausfälle unterscheiden, und Aktiv-Aktiv setzt kompatible Betriebsprozesse voraus. Eine Edge-Plattform wie die ayedo Edge Cloud schafft dafür eine providerunabhängige Routing- und Schutzebene vor Ingresses und API-Servern, ohne Edge und Compute miteinander zu vermischen.\u003c/p\u003e\n",
      "summary": "\nTL;DR Ein belastbares Kubernetes Ingress Failover beginnt nicht beim DNS, sondern bei klar definierten Fehlerbildern und aussagekräftigen Backend Health Checks. Aktiv-Aktiv-Architekturen verkürzen Ausfallzeiten, lösen aber weder fehlerhafte Anwendungen noch unklare Zuständigkeiten. Die Edge muss Status, Routing und Failover unabhängig von einzelnen Clustern bewerten.\nEinleitung Kubernetes-Hochverfügbarkeit scheitert häufig an einer falschen Annahme: Wenn mehrere Cluster existieren, ist der Dienst automatisch ausfallsicher. Tatsächlich kann ein Cluster erreichbar sein, während der Ingress keine Anfragen mehr verarbeitet, ein Netzwerkpfad gestört ist oder der Kubernetes API Server nicht antwortet. Für Kubernetes Ingress Failover müssen deshalb drei Ebenen getrennt betrachtet werden: der öffentliche Zugang, die Erreichbarkeit des Backends und die Funktionsfähigkeit des Dienstes. Erst daraus lässt sich ableiten, wann Traffic umgelenkt werden darf und wann ein Failover lediglich einen bereits bestehenden Fehler weiterverteilt.\n",
      "image": "https://ayedo.de/kubernetes-failover-fur-ingress-und-api-server-planen.png",
      "date_published": "2026-09-02T14:12:29Z",
      "date_modified": "2026-09-02T14:12:29Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["kubernetes","development","cloud-native","digital-sovereignty","software-delivery"],
      "language": "de"
    },{
      "id": "https://ayedo.de/posts/acme-dns-challenge-mit-der-edge-cloud-in-kubernetes/",
      "url": "https://ayedo.de/posts/acme-dns-challenge-mit-der-edge-cloud-in-kubernetes/",
      "title": "ACME-DNS-Challenge mit der Edge Cloud in Kubernetes",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/acme-dns-challenge-mit-der-edge-cloud-in-kubernetes/acme-dns-challenge-mit-der-edge-cloud-in-kubernetes.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eDie ACME DNS-01 Challenge ermöglicht TLS-Zertifikate für \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n-Services, ohne das Backend aus dem Internet erreichbar zu machen. Entscheidend sind getrennte DNS-Berechtigungen, eine eindeutige Domainzuordnung und die Frage, wo TLS terminiert. Hinter der ayedo Edge Cloud liegt dieser Terminierungspunkt an der öffentlichen Edge, nicht zwingend im Cluster.\u003c/p\u003e\n\u003cp\u003eEin TLS-Zertifikat wird häufig als Kubernetes-Problem betrachtet, obwohl bei einer vorgelagerten Edge-Architektur mehrere Systeme beteiligt sind: die ACME-Client-Komponente, die autoritative DNS-Zone, die Edge-Konfiguration und das Kubernetes-Backend. Werden diese Zuständigkeiten vermischt, entstehen unnötige Berechtigungen, unklare Betriebsprozesse und im Fehlerfall schwer nachvollziehbare Ausfälle.\u003c/p\u003e\n\u003cp\u003eDie zentrale Architekturentscheidung lautet daher nicht nur, wie ein Zertifikat ausgestellt wird. Es muss ebenso festgelegt werden, welche Komponente die Domain kontrolliert, wo der Nachweis für die Domaininhaberschaft abgelegt wird und an welchem Punkt die verschlüsselte Verbindung beendet wird.\u003c/p\u003e\n\u003ch2 id=\"1-dns-01-statt-öffentlicher-erreichbarkeit\"\u003e1. DNS-01 statt öffentlicher Erreichbarkeit\u003c/h2\u003e\n\u003cp\u003eBei der ACME DNS Challenge weist ein ACME-Client die Kontrolle über eine Domain durch einen TXT-Record unterhalb von \u003ccode\u003e_acme-challenge\u003c/code\u003e nach. Die Zertifizierungsstelle fragt diesen Record über DNS ab. Anders als bei HTTP-01 muss dafür kein Webserver im Kubernetes-Cluster aus dem Internet erreichbar sein.\u003c/p\u003e\n\u003cp\u003eDas ist für interne oder abgeschirmte Backends relevant. Ein Service kann ausschließlich über die ayedo Edge Cloud veröffentlicht werden, während seine eigentliche Kubernetes-Adresse nicht öffentlich geroutet wird. Die Edge übernimmt den öffentlichen Eingang und leitet erfolgreichen Traffic an das Backend weiter. Das reduziert die Angriffsfläche und verhindert, dass die Zertifikatsausstellung selbst eine direkte Internetverbindung zum Cluster voraussetzt.\u003c/p\u003e\n\u003cp\u003eDNS-01 verschiebt die Sicherheitsanforderung jedoch auf die DNS-Ebene. Wer TXT-Records in der zuständigen Zone verändern darf, kann grundsätzlich Domainvalidierungen beeinflussen. Diese Berechtigung sollte deshalb nicht pauschal für das gesamte DNS-Konto vergeben werden. Besser sind auf die benötigte Zone oder einen kontrollierten Namensbereich begrenzte Rechte.\u003c/p\u003e\n\u003ch2 id=\"2-dns-berechtigungen-sauber-begrenzen\"\u003e2. DNS-Berechtigungen sauber begrenzen\u003c/h2\u003e\n\u003cp\u003eFür die Ausstellung von TLS Zertifikaten in \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n benötigt der ACME-Client Zugriff auf die DNS-Verwaltung. Dieser Zugriff sollte von den übrigen Zugangsdaten des Unternehmens getrennt werden. Insbesondere darf eine Zertifikatskomponente nicht automatisch Nameserver, MX-Records oder produktive Routing-Einträge verändern können, wenn ausschließlich \u003ccode\u003e_acme-challenge\u003c/code\u003e benötigt wird.\u003c/p\u003e\n\u003cp\u003ePraktisch bedeutet das eine klare Trennung von Verantwortlichkeiten: Der ACME-Client darf den Validierungs-Record setzen und wieder entfernen. Die Zuordnung der öffentlichen Domain zur Edge Cloud bleibt davon getrennt. Ebenso sollten Zugangsdaten nicht als ungeschützte Konfigurationswerte in Manifests oder Versionskontrolle landen. In Kubernetes gehören solche Credentials in geeignete Secret-Mechanismen mit begrenztem Zugriff und nachvollziehbarer Rotation.\u003c/p\u003e\n\u003cp\u003eAuch organisatorisch ist die Trennung wichtig. DNS-Verantwortliche müssen nicht zwangsläufig Cluster-Administrationsrechte erhalten, und das Plattformteam sollte nicht automatisch vollständige Kontrolle über alle Unternehmensdomains benötigen. Ein begrenztes Berechtigungsmodell senkt das Risiko fehlerhafter Änderungen und erleichtert Audits, Incident Response sowie die Übergabe zwischen Netzwerk-, Security- und Plattformteams.\u003c/p\u003e\n\u003ch2 id=\"3-domainzuordnung-zwischen-dns-edge-und-cluster\"\u003e3. Domainzuordnung zwischen DNS, Edge und Cluster\u003c/h2\u003e\n\u003cp\u003eDie DNS-01 Challenge bestätigt lediglich die Kontrolle über die Domain. Sie definiert nicht automatisch, welcher Kubernetes-Service später erreichbar ist. Dafür braucht es eine konsistente Zuordnung zwischen Hostname, Edge-Konfiguration und Backend.\u003c/p\u003e\n\u003cp\u003eEin typischer Pfad ist: \u003ccode\u003eapi.example.de\u003c/code\u003e zeigt öffentlich auf die ayedo Edge Cloud. Dort ist ein Service für diesen Hostnamen konfiguriert, inklusive Backend-Ziel und Health Checks. Das Backend kann dabei unter einer nicht öffentlichen Adresse liegen. Die Edge Cloud bildet damit den kontrollierten öffentlichen Eingang, während Backend Cloaking verhindert, dass die interne Erreichbarkeit aus dem öffentlichen DNS- und Traffic-Modell abgeleitet wird.\u003c/p\u003e\n\u003cp\u003eFür den Betrieb müssen außerdem Wildcards und einzelne Hostnamen bewusst unterschieden werden. Ein Zertifikat für \u003ccode\u003e*.example.de\u003c/code\u003e deckt nicht automatisch die Apex-Domain \u003ccode\u003eexample.de\u003c/code\u003e ab. Werden Domains zwischen mehreren Clustern, Providern oder Umgebungen verteilt, muss klar sein, welche Plattform die jeweilige Zone beziehungsweise den Validierungsnamensraum verwaltet. Sonst kann ein gültiger DNS-Nachweis entstehen, obwohl der Traffic an die falsche Edge- oder Backend-Konfiguration gelangt.\u003c/p\u003e\n\u003ch2 id=\"4-tls-termination-an-der-edge-planen\"\u003e4. TLS Termination an der Edge planen\u003c/h2\u003e\n\u003cp\u003eDie DNS-01 Challenge beantwortet die Frage, wie die Zertifizierungsstelle die Domaininhaberschaft prüft. TLS Termination beantwortet dagegen, wo die verschlüsselte Clientverbindung endet. Bei einer Edge-Architektur liegt dieser Punkt häufig vor dem Kubernetes-Cluster. Die ayedo Edge Cloud kann TLS an der Edge terminieren und den entschlüsselten Traffic anschließend an das konfigurierte Backend weiterleiten.\u003c/p\u003e\n\u003cp\u003eDaraus folgt eine wichtige Betriebsregel: Das ausgestellte Zertifikat muss an dem Terminierungspunkt verfügbar sein. Ein Zertifikat, das lediglich als Kubernetes Secret im Cluster liegt, schützt nicht automatisch die Verbindung zwischen Client und Edge. Ausstellung, Speicherung, Erneuerung und Bereitstellung des Zertifikats müssen deshalb als zusammenhängender Prozess betrachtet werden.\u003c/p\u003e\n\u003cp\u003eDie Verbindung zwischen Edge und Backend ist davon getrennt zu bewerten. Je nach Schutzbedarf kann dort erneut TLS eingesetzt werden; das ist eine Architekturentscheidung und keine automatische Folge der DNS-01 Challenge. Entscheidend ist, die Vertrauensgrenzen ausdrücklich zu dokumentieren: Client zur Edge, Edge zum Backend sowie ACME-Client zur DNS-Verwaltung. So lassen sich Ablauf, Verantwortlichkeiten und Fehlerbilder eindeutig zuordnen.\u003c/p\u003e\n\u003ch2 id=\"praxisszenario-kubernetes-service-ohne-öffentliches-backend\"\u003ePraxisszenario: Kubernetes-Service ohne öffentliches Backend\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt \u003ccode\u003eapi.example.de\u003c/code\u003e in einem eigenen \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n-Cluster bei einem beliebigen Provider. Das Backend besitzt keine öffentliche IP und akzeptiert Traffic nur von der Edge. Die Domain zeigt auf die ayedo Edge Cloud; dort sind Hostname, TLS-Terminierung, Backend-Ziel und Health Checks konfiguriert.\u003c/p\u003e\n\u003cp\u003eFür die Zertifikatsausstellung führt eine ACME-Komponente die DNS-01 Challenge aus. Sie erhält ausschließlich die Berechtigung, den erforderlichen \u003ccode\u003e_acme-challenge\u003c/code\u003e-Record zu verwalten. Nach erfolgreicher Validierung wird das Zertifikat an den vorgesehenen TLS-Terminierungspunkt bereitgestellt. Fällt das Backend aus, kann die Edge den Zustand über Health Checks erkennen und entsprechend Failover-Verhalten anwenden. Die Zertifikatsprüfung bleibt dabei unabhängig von der direkten Erreichbarkeit des Clusters.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"benötigt-acme-dns-01-einen-öffentlich-erreichbaren-kubernetes-service\"\u003eBenötigt ACME DNS-01 einen öffentlich erreichbaren Kubernetes-Service?\u003c/h3\u003e\n\u003cp\u003eNein. Die Zertifizierungsstelle prüft den TXT-Record im DNS. Der Kubernetes-Service muss dafür nicht direkt aus dem Internet erreichbar sein.\u003c/p\u003e\n\u003ch3 id=\"wo-muss-das-tls-zertifikat-gespeichert-werden\"\u003eWo muss das TLS-Zertifikat gespeichert werden?\u003c/h3\u003e\n\u003cp\u003eDort, wo TLS terminiert. Bei TLS Termination an der Edge muss das Zertifikat für die Edge verfügbar sein; ein Kubernetes Secret allein reicht dafür nicht automatisch aus.\u003c/p\u003e\n\u003ch3 id=\"kann-dns-01-für-mehrere-kubernetes-cluster-verwendet-werden\"\u003eKann DNS-01 für mehrere Kubernetes-Cluster verwendet werden?\u003c/h3\u003e\n\u003cp\u003eJa, sofern Domainzuordnung und Zuständigkeiten eindeutig geregelt sind. Besonders bei gemeinsamen DNS-Zonen müssen Validierungsrechte und Hostnamen je Umgebung sauber getrennt werden.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eACME DNS Challenge und \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n bilden nur einen Teil der Zertifikatsarchitektur. Für abgeschirmte Backends ist DNS-01 geeignet, weil die Domainvalidierung ohne direkten Internetzugriff auf den Cluster funktioniert. Der eigentliche Betriebsaufwand liegt in begrenzten DNS-Rechten, konsistenter Domainzuordnung und der Bereitstellung des Zertifikats an der richtigen TLS-Terminierung. Die ayedo Edge Cloud ist dabei der öffentliche, zentral kontrollierte Terminierungspunkt vor den Backends – unabhängig davon, wo Kubernetes betrieben wird.\u003c/p\u003e\n",
      "summary": "\nTL;DR Die ACME DNS-01 Challenge ermöglicht TLS-Zertifikate für Kubernetes -Services, ohne das Backend aus dem Internet erreichbar zu machen. Entscheidend sind getrennte DNS-Berechtigungen, eine eindeutige Domainzuordnung und die Frage, wo TLS terminiert. Hinter der ayedo Edge Cloud liegt dieser Terminierungspunkt an der öffentlichen Edge, nicht zwingend im Cluster.\nEin TLS-Zertifikat wird häufig als Kubernetes-Problem betrachtet, obwohl bei einer vorgelagerten Edge-Architektur mehrere Systeme beteiligt sind: die ACME-Client-Komponente, die autoritative DNS-Zone, die Edge-Konfiguration und das Kubernetes-Backend. Werden diese Zuständigkeiten vermischt, entstehen unnötige Berechtigungen, unklare Betriebsprozesse und im Fehlerfall schwer nachvollziehbare Ausfälle.\n",
      "image": "https://ayedo.de/acme-dns-challenge-mit-der-edge-cloud-in-kubernetes.png",
      "date_published": "2026-09-02T14:12:28Z",
      "date_modified": "2026-09-02T14:12:28Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["kubernetes","cloud-native","cloud","security","digital-sovereignty"],
      "language": "de"
    },{
      "id": "https://ayedo.de/posts/ingress-und-gateway-dns-records-aus-hosts-ableiten/",
      "url": "https://ayedo.de/posts/ingress-und-gateway-dns-records-aus-hosts-ableiten/",
      "title": "Ingress und Gateway: DNS-Records aus Hosts ableiten",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/ingress-und-gateway-dns-records-aus-hosts-ableiten/ingress-und-gateway-dns-records-aus-hosts-ableiten.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eKubernetes-Ressourcen enthalten bereits die fachliche Zuordnung zwischen Hostnamen und Anwendungen. Ein automatisierter DNS-Prozess kann diese Angaben aus Ingress oder \u003ca href=\"/kubernetes/\"\u003eGateway API\u003c/a\u003e\n 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.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eEin Hostname in einer \u003ca href=\"/kubernetes/\"\u003eKubernetes-Ressource\u003c/a\u003e\n 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.\u003c/p\u003e\n\u003ch2 id=\"1-der-hostname-als-verbindliches-architekturartefakt\"\u003e1. Der Hostname als verbindliches Architekturartefakt\u003c/h2\u003e\n\u003cp\u003eBei einem klassischen Kubernetes-Ingress steht der relevante Hostname im Feld \u003ccode\u003espec.rules[].host\u003c/code\u003e. Die Regel beschreibt typischerweise, welcher HTTP- oder HTTPS-Pfad zu welchem Service führt. In der \u003ca href=\"/kubernetes/\"\u003eGateway API\u003c/a\u003e\n 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.\u003c/p\u003e\n\u003cp\u003eFü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.\u003c/p\u003e\n\u003cp\u003eDamit 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.\u003c/p\u003e\n\u003ch2 id=\"2-von-der-ressource-zum-anycast-dns-record\"\u003e2. Von der Ressource zum Anycast-DNS-Record\u003c/h2\u003e\n\u003cp\u003eDie 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 \u003ca href=\"/kubernetes/\"\u003eGateway API\u003c/a\u003e\n 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.\u003c/p\u003e\n\u003cp\u003eDer DNS-Prozess sollte deshalb einen gewünschten Zustand modellieren: Für \u003ccode\u003eapp.example.com\u003c/code\u003e 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.\u003c/p\u003e\n\u003cp\u003eIm 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.\u003c/p\u003e\n\u003ch2 id=\"3-synchronisation-löschung-und-fehlersicherheit\"\u003e3. Synchronisation, Löschung und Fehlersicherheit\u003c/h2\u003e\n\u003cp\u003eDie 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.\u003c/p\u003e\n\u003cp\u003eEine 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.\u003c/p\u003e\n\u003cp\u003eAuch 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.\u003c/p\u003e\n\u003ch2 id=\"4-edge-adresse-und-backend-ziel-sauber-trennen\"\u003e4. Edge-Adresse und Backend-Ziel sauber trennen\u003c/h2\u003e\n\u003cp\u003eEin 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.\u003c/p\u003e\n\u003cp\u003eSinnvoller 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.\u003c/p\u003e\n\u003cp\u003eDas 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.\u003c/p\u003e\n\u003ch2 id=\"praxisszenario-ein-hostname-durch-den-gesamten-lebenszyklus\"\u003ePraxisszenario: Ein Hostname durch den gesamten Lebenszyklus\u003c/h2\u003e\n\u003cp\u003eEin Team veröffentlicht \u003ccode\u003epayments.example.com\u003c/code\u003e zunächst über eine \u003ca href=\"/kubernetes/\"\u003eGateway-Ressource\u003c/a\u003e\n. 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.\u003c/p\u003e\n\u003cp\u003eDer 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.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"funktioniert-automatische-dns-erzeugung-nur-mit-ingress\"\u003eFunktioniert automatische DNS-Erzeugung nur mit Ingress?\u003c/h3\u003e\n\u003cp\u003eNein. Das Prinzip lässt sich auch auf die \u003ca href=\"/kubernetes/\"\u003eGateway API\u003c/a\u003e\n anwenden. Dort müssen Listener, Routes und deren Akzeptanzzustand berücksichtigt werden, nicht nur ein einzelnes Host-Feld.\u003c/p\u003e\n\u003ch3 id=\"sollte-dns-direkt-auf-einen-kubernetes-service-zeigen\"\u003eSollte DNS direkt auf einen Kubernetes-Service zeigen?\u003c/h3\u003e\n\u003cp\u003eFü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.\u003c/p\u003e\n\u003ch3 id=\"was-passiert-bei-mehreren-clustern\"\u003eWas passiert bei mehreren Clustern?\u003c/h3\u003e\n\u003cp\u003eDer Hostname muss eindeutig verwaltet werden. Eine zentrale Ownership- und Konfliktlogik verhindert, dass mehrere Cluster denselben DNS-Record unkontrolliert überschreiben.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eKubernetes automatische DNS Records sind vor allem eine Frage sauberer Zustands- und Verantwortungsmodelle. Ingress und \u003ca href=\"/kubernetes/\"\u003eGateway\u003c/a\u003e\n 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.\u003c/p\u003e\n",
      "summary": "\nTL;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.\nEinleitung 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.\n",
      "image": "https://ayedo.de/ingress-und-gateway-dns-records-aus-hosts-ableiten.png",
      "date_published": "2026-09-02T14:12:28Z",
      "date_modified": "2026-09-02T14:12:28Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["kubernetes","automation","development","cloud-native","digital-sovereignty"],
      "language": "de"
    },{
      "id": "https://ayedo.de/posts/kubernetes-gateway-providerubergreifend-an-die-edge-anbinden/",
      "url": "https://ayedo.de/posts/kubernetes-gateway-providerubergreifend-an-die-edge-anbinden/",
      "title": "Kubernetes-Gateway providerübergreifend an die Edge anbinden",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/kubernetes-gateway-providerubergreifend-an-die-edge-anbinden/kubernetes-gateway-providerubergreifend-an-die-edge-anbinden.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eDie \u003ca href=\"https://kubernetes.io/docs/concepts/services-networking/gateway-api/\" target=\"_blank\" rel=\"noopener\"\u003eKubernetes Gateway API\u003c/a\u003e\n kann eine portable Schnittstelle zwischen Anwendungen und öffentlichem Traffic bilden. Wird sie mit einer providerunabhängigen Edge-Schicht verbunden, bleiben Routing, TLS, Schutz und Backend-Abschirmung vom Netzwerk- und Cloud-Stack des Clusters getrennt. Das vereinfacht Multi-Cloud-Szenarien, erhöht die Ausfallsicherheit und reduziert infrastrukturelle Abhängigkeiten.\u003c/p\u003e\n\u003cp\u003eEin Kubernetes Gateway wird häufig als rein clusterinterne Komponente betrachtet. Diese Perspektive greift zu kurz, sobald Anwendungen über mehrere Provider betrieben, migriert oder geografisch verteilt werden. Dann entscheidet nicht allein die Konfiguration von Routes und Backends über die Erreichbarkeit. Entscheidend ist auch, wo Anycast-Routing, DNS, TLS-Terminierung, DDoS-Schutz und der öffentliche Einstiegspunkt betrieben werden.\u003c/p\u003e\n\u003cp\u003eDie \u003ca href=\"https://kubernetes.io/docs/concepts/services-networking/gateway-api/\" target=\"_blank\" rel=\"noopener\"\u003eKubernetes Gateway API\u003c/a\u003e\n bietet dafür ein portables Modell: Anwendungen und Plattformteams beschreiben, welcher Traffic zu welchen Backends gelangen soll. Die konkrete Netzwerk- und Provider-Infrastruktur bleibt davon getrennt. Diese Trennung funktioniert jedoch nur, wenn das Gateway nicht implizit an den Loadbalancer, das CNI oder die Ingress-Implementierung eines einzelnen Cloud-Stacks gekoppelt wird.\u003c/p\u003e\n\u003cp\u003eEine externe Edge-Plattform verschiebt den öffentlichen Traffic-Eingang bewusst aus dem Cluster heraus. Das ist keine zusätzliche Schicht ohne Zweck, sondern eine klare Aufteilung von Verantwortlichkeiten: Die Edge verarbeitet und schützt eingehenden Traffic, während Kubernetes die Workloads und deren interne Erreichbarkeit steuert.\u003c/p\u003e\n\u003ch2 id=\"1-die-gateway-api-als-portable-verkehrsschicht\"\u003e1. Die Gateway API als portable Verkehrsschicht\u003c/h2\u003e\n\u003cp\u003eDie \u003ca href=\"https://kubernetes.io/docs/concepts/services-networking/gateway-api/\" target=\"_blank\" rel=\"noopener\"\u003eKubernetes Gateway API\u003c/a\u003e\n trennt die Beschreibung von Traffic-Regeln stärker von der konkreten Implementierung als klassische, controllerabhängige Ingress-Konfigurationen. Konzepte wie Listener, Routen und Backends bilden einen deklarativen Vertrag zwischen Anwendung, Plattform und Infrastruktur. Dadurch kann dieselbe fachliche Routing-Absicht in unterschiedlichen Clustern und Betriebsmodellen verwendet werden.\u003c/p\u003e\n\u003cp\u003ePortabilität entsteht allerdings nicht automatisch durch ein standardisiertes API-Modell. Wenn ein Gateway direkt an einen cloudproviderspezifischen Loadbalancer, eine feste IP-Zuweisung oder ein bestimmtes Netzwerkmodell gebunden ist, bleibt die Architektur faktisch providerabhängig. Ein Clusterwechsel verändert dann nicht nur Compute und Storage, sondern auch den öffentlichen Einstiegspunkt.\u003c/p\u003e\n\u003cp\u003eDie ayedo Edge Cloud kann in diesem Modell als vorgelagerte, providerunabhängige Traffic-Schicht genutzt werden. Kubernetes-Cluster können bei ayedo Managed Kubernetes, im eigenen Rechenzentrum oder bei anderen Providern betrieben werden. Die Gateway-Konfiguration beschreibt den Traffic im Clusterkontext; die Edge übernimmt den öffentlichen Zugang und verteilt Anfragen an erreichbare Backends.\u003c/p\u003e\n\u003ch2 id=\"2-routing-und-schutz-außerhalb-des-clusters\"\u003e2. Routing und Schutz außerhalb des Clusters\u003c/h2\u003e\n\u003cp\u003eProviderübergreifendes Routing ist mehr als die Verteilung von HTTP-Anfragen auf Pods. Der öffentliche Traffic muss zunächst über DNS und Netzwerkrouting einen geeigneten Edge-Einstiegspunkt erreichen. Danach folgen je nach Anwendung TLS-Terminierung, Layer-7-Routing, Sicherheitsprüfungen und die Weiterleitung an ein Backend.\u003c/p\u003e\n\u003cp\u003eDiese Funktionen im Cluster zu bündeln, vergrößert dessen externe Abhängigkeiten. Ein Fehler im Cluster, ein Fehlrouting oder eine Überlastung kann dann nicht nur die Anwendung, sondern auch den Zugang zu Schutz- und Routingfunktionen beeinträchtigen. Für DDoS-Schutz und Web Application Firewall ist es außerdem sinnvoll, schädlichen oder unerwünschten Traffic möglichst vor dem Backend zu verarbeiten.\u003c/p\u003e\n\u003cp\u003eDie ayedo Edge Cloud verbindet Anycast-basiertes Layer-4- und Layer-7-Loadbalancing mit Anycast DNS, Multi-Provider-DNS, DDoS Protection und WAF-Funktionen. TLS kann an der Edge terminiert werden. Backend Cloaking verhindert, dass die eigentlichen Backend-Adressen zum öffentlichen Bestandteil der Architektur werden. Das entkoppelt Edge Security und Routing von der jeweiligen Clusterplattform.\u003c/p\u003e\n\u003ch2 id=\"3-backend-anbindung-und-failover-über-providergrenzen\"\u003e3. Backend-Anbindung und Failover über Providergrenzen\u003c/h2\u003e\n\u003cp\u003eDie zentrale Frage einer providerübergreifenden Gateway-Architektur lautet: Wie erreicht die Edge die Backends, ohne die internen Netzwerkannahmen eines Providers zu übernehmen? Das Backend kann in einem Kubernetes-Cluster bei einem Cloudanbieter, in einer eigenen Umgebung oder in einem ayedo Managed Kubernetes Cluster liegen. Die Edge benötigt dafür eine kontrollierte und überprüfbare Erreichbarkeit, nicht zwingend einen gemeinsamen Netzwerk- oder Cloud-Stack.\u003c/p\u003e\n\u003cp\u003eBackend Health Checks sind dabei eine betriebliche Grundlage. Sie ermöglichen, nicht verfügbare Ziele aus der Verteilung zu nehmen und Traffic auf andere Backends oder Cluster zu lenken. Failover wird damit zu einer expliziten Eigenschaft der Traffic-Schicht statt zu einer impliziten Nebenwirkung des jeweiligen Kubernetes-Netzwerks.\u003c/p\u003e\n\u003cp\u003eProxy Protocol kann zusätzliche Informationen zur ursprünglichen Verbindung bis zum Backend transportieren, wenn die nachgelagerte Verarbeitung diese benötigt. Zusammen mit TLS-Termination und Backend Cloaking lässt sich der externe Zugang zentral steuern, während die Anwendung weiterhin in ihrem jeweiligen Cluster betrieben wird. Das reduziert Migrationsaufwand und verhindert, dass jeder Provider eigene Edge-Mechanismen erzwingt.\u003c/p\u003e\n\u003ch2 id=\"4-betriebsmodell-zuständigkeiten-und-digitale-souveränität\"\u003e4. Betriebsmodell, Zuständigkeiten und digitale Souveränität\u003c/h2\u003e\n\u003cp\u003eEine portable Gateway-Architektur braucht klare Zuständigkeiten. Plattformteams verantworten Gateway-Ressourcen, Routingabsichten und die Verbindung zu Services. Das Edge-Team betreibt öffentlichen DNS, Schutzfunktionen, Termination, Verteilung und die Erreichbarkeit der Backends. Ohne diese Trennung entstehen widersprüchliche Konfigurationen: etwa Sicherheitsregeln im Cluster, DNS außerhalb der Plattform und Failover in manuellen Runbooks.\u003c/p\u003e\n\u003cp\u003eFür Organisationen mit mehreren Providern ist diese Aufteilung auch wirtschaftlich relevant. Ein Providerwechsel muss nicht automatisch eine Neugestaltung des öffentlichen Zugangs, der Sicherheitskontrollen und der DNS-Struktur auslösen. Investitionen in Routing- und Schutzkonfigurationen bleiben auf der Edge-Ebene nutzbar, während Compute-Entscheidungen unabhängig getroffen werden können.\u003c/p\u003e\n\u003cp\u003eDigitale Souveränität zeigt sich hier nicht als pauschale Abgrenzung, sondern als Kontrolle über kritische Architekturentscheidungen. Die ayedo Edge Cloud basiert auf eigener Netzwerk-Infrastruktur und einem eigenen Autonomous System. In einer verteilten Multi-PoP-Aktiv-Aktiv-Architektur werden zentrale Edge-Funktionen von den einzelnen Kubernetes-Providern getrennt betrieben. Das schafft eine klarere technische Abhängigkeitssituation.\u003c/p\u003e\n\u003ch2 id=\"praxis--und-betriebsszenario\"\u003ePraxis- und Betriebsszenario\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt eine API zunächst in einem \u003ca href=\"https://kubernetes.io/\" target=\"_blank\" rel=\"noopener\"\u003eKubernetes-Cluster\u003c/a\u003e\n bei Provider A und plant parallel einen zweiten Cluster bei Provider B. Beide Umgebungen sollen denselben öffentlichen Dienst bereitstellen. Bei einem providergebundenen Gateway müsste der öffentliche Loadbalancer je Cluster separat aufgebaut, abgesichert und über DNS gesteuert werden.\u003c/p\u003e\n\u003cp\u003eMit der \u003ca href=\"https://kubernetes.io/docs/concepts/services-networking/gateway-api/\" target=\"_blank\" rel=\"noopener\"\u003eKubernetes Gateway API\u003c/a\u003e\n werden Routingregeln und Backend-Zuordnungen in den Clustern als Plattformkonfiguration verwaltet. Die ayedo Edge Cloud bleibt der gemeinsame öffentliche Einstiegspunkt. Sie übernimmt Anycast DNS, TLS-Terminierung, WAF und DDoS-Schutz und prüft die Backend-Gesundheit. Fällt ein Cluster aus, kann der Traffic auf das andere Backend gelenkt werden, ohne den externen Zugang neu zu entwerfen.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"ist-die-kubernetes-gateway-api-an-einen-cloudprovider-gebunden\"\u003eIst die Kubernetes Gateway API an einen Cloudprovider gebunden?\u003c/h3\u003e\n\u003cp\u003eNein. Das API-Modell ist portabel. Providerabhängigkeit entsteht erst durch die konkrete Gateway-Implementierung, Netzwerkintegration oder die Bindung an einen proprietären Loadbalancer.\u003c/p\u003e\n\u003ch3 id=\"ersetzt-die-edge-cloud-das-gateway-im-kubernetes-cluster\"\u003eErsetzt die Edge Cloud das Gateway im Kubernetes-Cluster?\u003c/h3\u003e\n\u003cp\u003eNein. Beide Ebenen haben unterschiedliche Aufgaben. Kubernetes beschreibt und steuert den Anwendungs-Traffic; die Edge übernimmt den öffentlichen Eingang, Schutz, Termination und die Verteilung zu Backends.\u003c/p\u003e\n\u003ch3 id=\"funktioniert-das-nur-mit-ayedo-managed-kubernetes\"\u003eFunktioniert das nur mit ayedo Managed Kubernetes?\u003c/h3\u003e\n\u003cp\u003eNein. Die Kubernetes-native Integration kann auch mit eigenen Clustern oder Kubernetes-Umgebungen anderer Provider genutzt werden. Dadurch bleibt die Edge-Schicht vom Compute-Betriebsmodell getrennt.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eDie \u003ca href=\"https://kubernetes.io/docs/concepts/services-networking/gateway-api/\" target=\"_blank\" rel=\"noopener\"\u003eKubernetes Gateway API\u003c/a\u003e\n wird besonders wertvoll, wenn sie nicht als Synonym für den providergebundenen externen Loadbalancer verstanden wird. Als deklarative Routing-Schnittstelle kann sie Teil einer portablen Traffic-Architektur sein, während öffentliche Erreichbarkeit, Edge Security und Failover außerhalb des Clusters organisiert werden. Die ayedo Edge Cloud unterstützt dieses Modell mit providerübergreifender Kubernetes-Nutzung, eigener Netzwerk-Infrastruktur und zentralen Edge-Funktionen.\u003c/p\u003e\n",
      "summary": "\nTL;DR Die Kubernetes Gateway API kann eine portable Schnittstelle zwischen Anwendungen und öffentlichem Traffic bilden. Wird sie mit einer providerunabhängigen Edge-Schicht verbunden, bleiben Routing, TLS, Schutz und Backend-Abschirmung vom Netzwerk- und Cloud-Stack des Clusters getrennt. Das vereinfacht Multi-Cloud-Szenarien, erhöht die Ausfallsicherheit und reduziert infrastrukturelle Abhängigkeiten.\nEin Kubernetes Gateway wird häufig als rein clusterinterne Komponente betrachtet. Diese Perspektive greift zu kurz, sobald Anwendungen über mehrere Provider betrieben, migriert oder geografisch verteilt werden. Dann entscheidet nicht allein die Konfiguration von Routes und Backends über die Erreichbarkeit. Entscheidend ist auch, wo Anycast-Routing, DNS, TLS-Terminierung, DDoS-Schutz und der öffentliche Einstiegspunkt betrieben werden.\n",
      "image": "https://ayedo.de/kubernetes-gateway-providerubergreifend-an-die-edge-anbinden.png",
      "date_published": "2026-09-02T14:12:28Z",
      "date_modified": "2026-09-02T14:12:28Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["kubernetes","cloud-native","security","cloud","development"],
      "language": "de"
    },{
      "id": "https://ayedo.de/posts/kubernetes-zertifikate-per-dns-challenge-ausstellen/",
      "url": "https://ayedo.de/posts/kubernetes-zertifikate-per-dns-challenge-ausstellen/",
      "title": "Kubernetes-Zertifikate per DNS-Challenge ausstellen",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/kubernetes-zertifikate-per-dns-challenge-ausstellen/kubernetes-zertifikate-per-dns-challenge-ausstellen.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eDie DNS-01-Challenge validiert eine Domain über einen TXT-Record und benötigt keine öffentlich erreichbare HTTP-Anwendung. Das ist besonders relevant, wenn die ayedo Edge Cloud den öffentlichen Traffic entgegennimmt und TLS terminiert, während der \u003ca href=\"/kubernetes/\"\u003eKubernetes-Cluster\u003c/a\u003e\n abgeschirmt bleibt. Entscheidend sind klare Zuständigkeiten für DNS, Zertifikate und TLS.\u003c/p\u003e\n\u003cp\u003eEin Zertifikat für einen Kubernetes-Service wird nicht deshalb erfolgreich ausgestellt, weil ein Ingress intern erreichbar ist. ACME-Verfahren prüfen eine Domain nach einem festgelegten Netzwerkpfad. Bei HTTP-01 muss der Validierungsdienst die Anwendung über Port 80 erreichen. Bei DNS-01 genügt ein korrekt gesetzter TXT-Record unter \u003ccode\u003e_acme-challenge\u003c/code\u003e. Damit ändern sich die Anforderungen an Netzwerktopologie, Firewall-Regeln und Verantwortungsgrenzen zwischen Cluster und Edge grundlegend.\u003c/p\u003e\n\u003ch2 id=\"http-01-und-dns-01-prüfen-unterschiedliche-pfade\"\u003eHTTP-01 und DNS-01 prüfen unterschiedliche Pfade\u003c/h2\u003e\n\u003cp\u003eBei HTTP-01 legt der ACME-Client eine zufällige Challenge unter \u003ccode\u003e/.well-known/acme-challenge/\u003c/code\u003e ab. Die Zertifizierungsstelle ruft diese URL über die zu validierende Domain auf. Dafür muss die Domain öffentlich auf einen erreichbaren HTTP-Endpunkt zeigen. Ein Ingress oder Gateway muss den Request korrekt routen, Port 80 darf nicht blockiert sein, und vorgeschaltete Komponenten dürfen den Challenge-Pfad nicht verändern oder abweisen.\u003c/p\u003e\n\u003cp\u003eDNS-01 verwendet dagegen einen TXT-Record unter \u003ccode\u003e_acme-challenge.\u0026lt;domain\u0026gt;\u003c/code\u003e. Die Zertifizierungsstelle fragt diesen Record über DNS ab. Der eigentliche HTTP-Service muss während der Validierung nicht erreichbar sein. Das eignet sich für interne Backends, abgeschottete Cluster, Wildcard-Zertifikate und Umgebungen, in denen Port 80 bewusst nicht veröffentlicht wird.\u003c/p\u003e\n\u003cp\u003eDer Unterschied ist architektonisch relevant: HTTP-01 koppelt die Ausstellung an den Datenpfad der Anwendung. DNS-01 koppelt sie an die Kontrolle über die autoritative DNS-Zone. Ein Netzwerkpfad zum Ingress ist bei DNS-01 nicht erforderlich, dafür müssen DNS-Änderungen automatisiert und sicher möglich sein.\u003c/p\u003e\n\u003ch2 id=\"dns-validierung-verschiebt-die-verantwortungsgrenze\"\u003eDNS-Validierung verschiebt die Verantwortungsgrenze\u003c/h2\u003e\n\u003cp\u003eFür DNS-01 benötigt der ACME-Client Zugriff auf die DNS-Zone, in der der TXT-Record angelegt wird. In \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n erfolgt das typischerweise über einen Zertifikats-Controller oder einen separaten ACME-Client. Diese Komponente muss nicht zwingend im gleichen Verantwortungsbereich wie die autoritativen Nameserver liegen. Sie braucht jedoch eine kontrollierte Möglichkeit, den erforderlichen Record zu setzen und nach der Validierung wieder zu entfernen.\u003c/p\u003e\n\u003cp\u003eDas erzeugt eine andere Sicherheitsanforderung als bei HTTP-01. Statt einen öffentlichen HTTP-Endpunkt für die Challenge bereitzustellen, erhält eine Komponente Schreibrechte auf DNS. Diese Rechte sollten auf die notwendigen Zonen oder Record-Typen begrenzt werden. Fehlerhafte Berechtigungen können weitreichendere Auswirkungen haben als ein falsch gerouteter Challenge-Pfad, weil DNS Änderungen für mehrere Services oder Domains beeinflussen können.\u003c/p\u003e\n\u003cp\u003eAuch die Verteilung von DNS spielt eine Rolle. Bei Anycast DNS oder Multi-Provider-DNS muss der TXT-Record über die tatsächlich autoritativen Systeme sichtbar werden. Der Client darf nicht nur einen einzelnen Resolver oder eine lokale Sicht prüfen. Verzögerungen bei der Replikation können dazu führen, dass die Zertifizierungsstelle den Record noch nicht sieht, obwohl er aus einer internen Perspektive bereits vorhanden ist.\u003c/p\u003e\n\u003ch2 id=\"edge-tls-terminierung-und-kubernetes-sind-getrennte-ebenen\"\u003eEdge, TLS-Terminierung und Kubernetes sind getrennte Ebenen\u003c/h2\u003e\n\u003cp\u003eZeigt eine öffentliche Domain auf die ayedo Edge Cloud, liegt der öffentliche Einstiegspunkt vor dem \u003ca href=\"/kubernetes/\"\u003eKubernetes-Cluster\u003c/a\u003e\n. Die Edge verarbeitet den eingehenden Traffic und kann TLS terminieren, bevor Requests über das Netzwerk zum Backend weitergeleitet werden. Das Zertifikat für den öffentlichen Hostnamen muss dann an der TLS-Terminierung verfügbar sein. Es reicht nicht, nur im Kubernetes-Ingress ein Zertifikat zu hinterlegen, wenn die Verbindung bereits an der Edge endet.\u003c/p\u003e\n\u003cp\u003eDNS-01 ist in diesem Modell unabhängig davon, ob das Backend öffentlich erreichbar ist. Die Domain kann auf die Edge zeigen, während der ACME-Client im Cluster oder in einem separaten Betriebsbereich den DNS-Challenge-Record verwaltet. Die Edge benötigt für die TLS-Terminierung anschließend das ausgestellte Zertifikat – entweder über einen definierten Zertifikatsprozess oder durch eine entsprechende Verwaltung außerhalb des Clusters. Welche Komponente diesen Transfer ausführt, ist eine Betriebsentscheidung und sollte nicht implizit angenommen werden.\u003c/p\u003e\n\u003cp\u003eDie ayedo Edge Cloud ist dabei nicht auf den Kubernetes-Cluster beschränkt. Sie kann auch vor Clustern anderer Provider oder vor eigener Infrastruktur eingesetzt werden. Dadurch bleiben DNS-Validierung, öffentlicher Einstieg und Compute-Betrieb als getrennte Verantwortungsbereiche modellierbar.\u003c/p\u003e\n\u003ch2 id=\"anforderungen-an-domains-ingress-und-gateway\"\u003eAnforderungen an Domains, Ingress und Gateway\u003c/h2\u003e\n\u003cp\u003eEine Zertifikatsanforderung muss exakt zu den DNS-Namen passen, unter denen ein Service erreichbar sein soll. Verweist \u003ccode\u003eapi.example.org\u003c/code\u003e auf einen Ingress- oder Gateway-Host, muss dieser Hostname sowohl im Zertifikat als auch in der TLS-Konfiguration berücksichtigt werden. Ein Zertifikat für \u003ccode\u003eexample.org\u003c/code\u003e deckt nicht automatisch \u003ccode\u003eapi.example.org\u003c/code\u003e ab. Wildcard-Zertifikate können mehrere Subdomains abdecken, benötigen bei ACME jedoch DNS-01.\u003c/p\u003e\n\u003cp\u003eBei HTTP-01 muss der Hostname während der Validierung tatsächlich bis zum zuständigen Ingress oder Gateway routen. Eine ayedo Edge Cloud davor kann den Request terminieren oder weiterleiten; Routing, TLS-Konfiguration und Challenge-Pfad müssen zusammenpassen. Ein Backend Cloaking oder eine restriktive Firewall ist mit HTTP-01 nicht grundsätzlich unvereinbar, kann die Validierung aber verhindern, wenn der ACME-Request den erwarteten Pfad nicht erreicht.\u003c/p\u003e\n\u003cp\u003eBei DNS-01 genügt die korrekte Delegation der Domain und die Veröffentlichung des TXT-Records. Der A- oder AAAA-Record muss nicht auf einen öffentlich erreichbaren Cluster zeigen. Trotzdem sollte die endgültige Datenroute bereits konsistent geplant sein: Zertifikatsausstellung, TLS-Terminierung an der Edge und Weiterleitung zum Gateway sind getrennte Schritte, die denselben Hostnamen verwenden müssen.\u003c/p\u003e\n\u003ch2 id=\"praxisszenario-öffentliche-edge-privater-cluster\"\u003ePraxisszenario: Öffentliche Edge, privater Cluster\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt \u003ccode\u003eshop.example.org\u003c/code\u003e in einem \u003ca href=\"/kubernetes/\"\u003eKubernetes-Cluster\u003c/a\u003e\n ohne direkte Internet-Erreichbarkeit. Die Domain zeigt auf die ayedo Edge Cloud. Dort wird TLS terminiert, DDoS-Schutz und WAF werden angewendet, anschließend wird der Traffic an das Gateway im privaten Cluster weitergeleitet.\u003c/p\u003e\n\u003cp\u003eHTTP-01 wäre in dieser Topologie nur möglich, wenn die Edge den Challenge-Pfad korrekt bis zum Gateway transportiert und der Cluster während der Validierung erreichbar bleibt. DNS-01 reduziert diese Kopplung: Der ACME-Client setzt den TXT-Record, ohne dass Port 80 oder das Backend öffentlich geöffnet werden müssen. Das Zertifikat wird anschließend für die TLS-Terminierung an der Edge bereitgestellt. Soll die Verbindung zwischen Edge und Backend ebenfalls verschlüsselt werden, ist zusätzlich ein Zertifikats- und Vertrauenskonzept für diese Verbindung erforderlich.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"ist-dns-01-für-jedes-kubernetes-zertifikat-notwendig\"\u003eIst DNS-01 für jedes Kubernetes-Zertifikat notwendig?\u003c/h3\u003e\n\u003cp\u003eNein. HTTP-01 reicht für öffentlich erreichbare Hostnamen ohne Wildcard-Anforderung. DNS-01 ist sinnvoll, wenn der Cluster abgeschirmt ist oder Wildcard-Zertifikate benötigt werden.\u003c/p\u003e\n\u003ch3 id=\"muss-der-dns-01-client-im-cluster-laufen\"\u003eMuss der DNS-01-Client im Cluster laufen?\u003c/h3\u003e\n\u003cp\u003eNein. Er kann im Cluster, in einer zentralen \u003ca href=\"/platform/\"\u003ePlattform\u003c/a\u003e\n oder in einem separaten Betriebsprozess laufen. Entscheidend sind sichere Schreibrechte auf die autoritative DNS-Zone.\u003c/p\u003e\n\u003ch3 id=\"wo-liegt-das-zertifikat-bei-tls-terminierung-an-der-edge\"\u003eWo liegt das Zertifikat bei TLS-Terminierung an der Edge?\u003c/h3\u003e\n\u003cp\u003eEs muss dort verfügbar sein, wo die TLS-Verbindung endet. Bei Terminierung in der Edge ist das die Edge-Ebene; ein Zertifikat ausschließlich im Kubernetes-Gateway reicht dann nicht aus.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eDNS-01 ist kein alternativer Schalter für HTTP-01, sondern ein anderes Validierungsmodell mit anderen Verantwortungs- und Sicherheitsgrenzen. Es entkoppelt die Zertifikatsausstellung von der öffentlichen Erreichbarkeit des Ingress oder Gateways, verlangt aber kontrollierten DNS-Zugriff. In einer Architektur mit der ayedo Edge Cloud lassen sich öffentlicher Einstieg, TLS-Terminierung und Kubernetes-Compute dadurch klar trennen. Entscheidend ist, diese Ebenen gemeinsam zu planen, aber operativ nicht zu vermischen.\u003c/p\u003e\n",
      "summary": "\nTL;DR Die DNS-01-Challenge validiert eine Domain über einen TXT-Record und benötigt keine öffentlich erreichbare HTTP-Anwendung. Das ist besonders relevant, wenn die ayedo Edge Cloud den öffentlichen Traffic entgegennimmt und TLS terminiert, während der Kubernetes-Cluster abgeschirmt bleibt. Entscheidend sind klare Zuständigkeiten für DNS, Zertifikate und TLS.\nEin Zertifikat für einen Kubernetes-Service wird nicht deshalb erfolgreich ausgestellt, weil ein Ingress intern erreichbar ist. ACME-Verfahren prüfen eine Domain nach einem festgelegten Netzwerkpfad. Bei HTTP-01 muss der Validierungsdienst die Anwendung über Port 80 erreichen. Bei DNS-01 genügt ein korrekt gesetzter TXT-Record unter _acme-challenge. Damit ändern sich die Anforderungen an Netzwerktopologie, Firewall-Regeln und Verantwortungsgrenzen zwischen Cluster und Edge grundlegend.\n",
      "image": "https://ayedo.de/kubernetes-zertifikate-per-dns-challenge-ausstellen.png",
      "date_published": "2026-09-02T14:12:28Z",
      "date_modified": "2026-09-02T14:12:28Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["kubernetes","security","cloud-native","digital-sovereignty","software-delivery"],
      "language": "de"
    },{
      "id": "https://ayedo.de/posts/kubernetes-ingress-providerunabhangig-mit-der-edge-cloud/",
      "url": "https://ayedo.de/posts/kubernetes-ingress-providerunabhangig-mit-der-edge-cloud/",
      "title": "Kubernetes-Ingress providerunabhängig mit der Edge Cloud",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/kubernetes-ingress-providerunabhangig-mit-der-edge-cloud/kubernetes-ingress-providerunabhangig-mit-der-edge-cloud.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eEin \u003ca href=\"/kubernetes/\"\u003eKubernetes-Ingress\u003c/a\u003e\n muss nicht direkt an den Loadbalancer eines Cloudproviders gekoppelt sein. Eine zentrale Edge-Schicht kann mehrere Kubernetes-Cluster über einheitliche öffentliche IPs, TLS-Terminierung, Schutzfunktionen und Health Checks anbinden. Die ayedo Edge Cloud ermöglicht dieses Modell für ayedo Managed Kubernetes, eigene Cluster und Kubernetes-Umgebungen bei anderen Providern.\u003c/p\u003e\n\u003cp\u003eDie Wahl des Loadbalancers vor einem Kubernetes-Ingress ist eine Architekturentscheidung mit langfristigen Folgen. Wird der Ingress unmittelbar über den jeweiligen Cloudprovider veröffentlicht, entstehen enge Abhängigkeiten zwischen Cluster, Netzwerk und Provider. Das kann für einen einzelnen Cluster sinnvoll sein, erschwert aber den Wechsel des Betriebsmodells, Multi-Cloud-Szenarien und eine konsistente Absicherung mehrerer Umgebungen.\u003c/p\u003e\n\u003cp\u003eEin providerunabhängiger Kubernetes Ingress Loadbalancer trennt den öffentlichen Traffic-Eingang vom Compute-Standort. Diese Trennung schafft eine eigene Verantwortungsgrenze: Die Edge verarbeitet und schützt eingehende Verbindungen, während Kubernetes die Anwendungen und Ingresses im jeweiligen Cluster betreibt. Genau diese Entkopplung ist der Kern einer belastbaren Ingress Architektur.\u003c/p\u003e\n\u003ch2 id=\"1-providergebundener-ingress-einfach-im-start-eng-in-der-architektur\"\u003e1. Providergebundener Ingress: einfach im Start, eng in der Architektur\u003c/h2\u003e\n\u003cp\u003eIn vielen Kubernetes-Umgebungen erzeugt ein Service vom Typ \u003ccode\u003eLoadBalancer\u003c/code\u003e oder ein Ingress-Controller direkt eine providerabhängige öffentliche Anbindung. Der Cloudprovider stellt dabei die externe IP, das Loadbalancing und häufig weitere Netzwerkfunktionen bereit. Der Ingress im Cluster bleibt der zentrale Einstiegspunkt für HTTP- und HTTPS-Routing.\u003c/p\u003e\n\u003cp\u003eDieses Modell reduziert zunächst den Integrationsaufwand. Cluster und Loadbalancer liegen in derselben Providerumgebung, Netzwerkanbindung und Provisionierung sind aufeinander abgestimmt. Die Kehrseite zeigt sich bei Veränderungen: Ein Clusterwechsel kann neue IPs, DNS-Anpassungen, Zertifikatsprozesse und abweichende Sicherheitskonfigurationen erfordern. Auch mehrere Provider führen schnell zu unterschiedlichen Betriebsmodellen.\u003c/p\u003e\n\u003cp\u003eProblematisch ist außerdem, wenn Security- und Routingregeln an mehreren Stellen gepflegt werden. DDoS-Schutz, TLS-Terminierung oder globale Failover-Entscheidungen sind dann eng an einzelne Cluster gekoppelt. Der providergebundene Ingress ist deshalb kein falscher Ansatz, aber eine bewusste Entscheidung für Kopplung statt zentraler Steuerung.\u003c/p\u003e\n\u003ch2 id=\"2-die-edge-als-vorgelagerte-providerunabhängige-schicht\"\u003e2. Die Edge als vorgelagerte, providerunabhängige Schicht\u003c/h2\u003e\n\u003cp\u003eBei einer zentralen Edge-Anbindung endet der öffentliche Traffic nicht direkt am Kubernetes-Cluster. Die ayedo Edge Cloud übernimmt den öffentlichen Eingang und verteilt Verbindungen anschließend an die Ingresses der angebundenen Cluster. Dabei können Anycast-basiertes Layer-4- und Layer-7-Loadbalancing, TLS Termination, Web Application Firewall und DDoS Protection an der Edge zusammenwirken.\u003c/p\u003e\n\u003cp\u003eDer entscheidende Architekturpunkt ist die Trennung von Edge und Compute. Kubernetes bleibt für Ingress-Ressourcen, Services und die Anwendungsbereitstellung verantwortlich. Die Edge Cloud übernimmt dagegen die Erreichbarkeit, Schutzfunktionen, Verteilung und das Failover vor diesen Komponenten. Backend Cloaking verhindert dabei, dass die eigentlichen Backend-Endpunkte zum öffentlichen Adressierungsmodell werden müssen.\u003c/p\u003e\n\u003cp\u003eDurch Anycast DNS oder Multi-Provider-DNS lässt sich die DNS-Ebene ebenfalls unabhängig von einem einzelnen Computeprovider organisieren. Die ayedo Edge Cloud nutzt dafür eigene Netzwerk-Infrastruktur und ein eigenes Autonomous System. Damit wird die öffentliche Anbindung als eigenständige Plattform betrieben, während Cluster weiterhin dort laufen können, wo es aus technischen, organisatorischen oder wirtschaftlichen Gründen sinnvoll ist.\u003c/p\u003e\n\u003ch2 id=\"3-ein-gemeinsames-modell-für-unterschiedliche-kubernetes-cluster\"\u003e3. Ein gemeinsames Modell für unterschiedliche Kubernetes-Cluster\u003c/h2\u003e\n\u003cp\u003eDer praktische Vorteil entsteht, wenn nicht nur ein Cluster, sondern mehrere Betriebsmodelle über dieselbe Edge-Schicht erreichbar sind. Ein ayedo Managed Kubernetes Cluster kann dabei genauso angebunden werden wie ein selbst betriebener Cluster oder eine Kubernetes-Umgebung bei einem anderen Provider. Der Ingress bleibt jeweils im Cluster; die Edge stellt die gemeinsame äußere Anbindung bereit.\u003c/p\u003e\n\u003cp\u003eFür Anwendungen kann dieses Modell ein konsistentes Namens- und Sicherheitskonzept ermöglichen, obwohl sich die Cluster intern unterscheiden. Ein Service kann beispielsweise über dieselbe öffentliche Domain erreichbar bleiben, während sein Backend zwischen Clustern verschoben oder parallel betrieben wird. Backend Health Checks und Failover unterstützen dabei die Entscheidung, nur funktionsfähige Ziele in die Verteilung einzubeziehen.\u003c/p\u003e\n\u003cp\u003eProviderunabhängigkeit bedeutet nicht, dass alle Cluster technisch identisch sein müssen. Sie bedeutet, dass die öffentliche Traffic-Steuerung nicht an die Lebensdauer oder die spezifischen Netzwerkmechanismen eines einzelnen Providers gebunden ist. \u003ca href=\"/kubernetes/\"\u003eKubernetes-native Integration\u003c/a\u003e\n reduziert den manuellen Konfigurationsaufwand, ohne die Nutzung auf ayedo Managed Kubernetes zu beschränken.\u003c/p\u003e\n\u003ch2 id=\"4-betriebsfolgen-zentrale-kontrolle-neue-verantwortungsgrenzen\"\u003e4. Betriebsfolgen: zentrale Kontrolle, neue Verantwortungsgrenzen\u003c/h2\u003e\n\u003cp\u003eEine zentrale Edge-Schicht vereinheitlicht den Betrieb dort, wo mehrere Cluster sonst getrennt behandelt würden. Routing, TLS, Schutzfunktionen und Traffic-Statistiken können an einer gemeinsamen Stelle betrachtet werden. Das erleichtert die Analyse von Fehlern vor dem Cluster und unterstützt eine klare Zuordnung: Ist ein Problem am öffentlichen Eingang, auf dem Transportweg, im Ingress oder im Backend entstanden?\u003c/p\u003e\n\u003cp\u003eDiese Zentralisierung schafft allerdings auch eine zusätzliche Plattformverantwortung. Teams müssen Zuständigkeiten für DNS, Zertifikate, Backend-Ziele, Health Checks und Änderungen an der Edge definieren. Ein fehlerhaftes zentrales Routing kann mehrere Anwendungen betreffen. Deshalb gehören Änderungsprozesse, Testumgebungen und nachvollziehbare Konfigurationen zur Architektur, nicht nur die technische Verbindung zwischen Edge und Ingress.\u003c/p\u003e\n\u003cp\u003eFür Unternehmen ist der wirtschaftliche Effekt vor allem bei mehreren Umgebungen relevant. Ein providergebundener Loadbalancer kann pro Cluster effizient sein, erzeugt aber bei Migrationen, Multi-Cloud und standardisierten Security-Anforderungen wiederkehrende Integrationsarbeit. Eine gemeinsame Edge-Anbindung verschiebt Investitionen in eine zentrale Plattform und reduziert dafür Abhängigkeiten in den einzelnen Compute-Umgebungen.\u003c/p\u003e\n\u003ch2 id=\"praxisszenario-ein-dienst-drei-cluster\"\u003ePraxisszenario: Ein Dienst, drei Cluster\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt eine Anwendung zunächst in ayedo Managed Kubernetes. Später kommt ein selbst verwalteter Cluster für eine getrennte Betriebsumgebung hinzu; ein weiterer Cluster läuft bei einem anderen Provider. Beim providergebundenen Modell hätte jeder Cluster seinen eigenen externen Loadbalancer, eigene öffentliche Endpunkte und abweichende Betriebsprozesse.\u003c/p\u003e\n\u003cp\u003eMit einer zentralen ayedo Edge Cloud zeigen alle drei Umgebungen über eine gemeinsame Edge-Anbindung nach außen. Die Edge terminiert TLS, prüft die Erreichbarkeit der Backends und verteilt den Traffic an die jeweiligen Kubernetes-Ingresses. Für eine Migration kann der Anteil eines Clusters schrittweise verändert werden, ohne das öffentliche Adressierungsmodell vollständig neu aufzubauen. Die Cluster bleiben dabei unabhängig voneinander betreibbar.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"ist-die-ayedo-edge-cloud-ein-ersatz-für-den-kubernetes-ingress\"\u003eIst die ayedo Edge Cloud ein Ersatz für den Kubernetes-Ingress?\u003c/h3\u003e\n\u003cp\u003eNein. Der Ingress bleibt für Routing innerhalb der Kubernetes-Umgebung zuständig. Die Edge Cloud übernimmt die vorgelagerte öffentliche Anbindung, Schutzfunktionen, Termination und Verteilung zum Ingress.\u003c/p\u003e\n\u003ch3 id=\"funktioniert-das-auch-mit-kubernetes-außerhalb-von-ayedo\"\u003eFunktioniert das auch mit Kubernetes außerhalb von ayedo?\u003c/h3\u003e\n\u003cp\u003eJa. Die Edge Cloud kann ayedo Managed Kubernetes, eigene Cluster und Kubernetes-Cluster bei anderen Providern über dieselbe Edge-Schicht anbinden.\u003c/p\u003e\n\u003ch3 id=\"welche-rolle-spielt-backend-cloaking\"\u003eWelche Rolle spielt Backend Cloaking?\u003c/h3\u003e\n\u003cp\u003eBackend Cloaking hält die eigentlichen Backend-Endpunkte aus dem öffentlichen Adressierungsmodell heraus. Öffentlich sichtbar ist die Edge, während die Kubernetes-Ingresses als nachgelagerte Ziele betrieben werden.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eEin Kubernetes Ingress Loadbalancer ist nicht nur eine technische Komfortfunktion, sondern legt fest, wo öffentliche Erreichbarkeit und Verantwortung verankert sind. Die direkte Provideranbindung ist für einzelne Cluster pragmatisch, bindet jedoch Netzwerk- und Betriebsentscheidungen an den jeweiligen Provider. Die ayedo Edge Cloud ermöglicht dagegen eine getrennte, providerunabhängige Edge-Schicht vor ayedo Managed Kubernetes, eigenen Clustern und extern betriebenen Kubernetes-Umgebungen. Damit werden Migrationen, Multi-Cluster-Betrieb und einheitliche Edge-Kontrolle architektonisch besser beherrschbar.\u003c/p\u003e\n",
      "summary": "\nTL;DR Ein Kubernetes-Ingress muss nicht direkt an den Loadbalancer eines Cloudproviders gekoppelt sein. Eine zentrale Edge-Schicht kann mehrere Kubernetes-Cluster über einheitliche öffentliche IPs, TLS-Terminierung, Schutzfunktionen und Health Checks anbinden. Die ayedo Edge Cloud ermöglicht dieses Modell für ayedo Managed Kubernetes, eigene Cluster und Kubernetes-Umgebungen bei anderen Providern.\nDie Wahl des Loadbalancers vor einem Kubernetes-Ingress ist eine Architekturentscheidung mit langfristigen Folgen. Wird der Ingress unmittelbar über den jeweiligen Cloudprovider veröffentlicht, entstehen enge Abhängigkeiten zwischen Cluster, Netzwerk und Provider. Das kann für einen einzelnen Cluster sinnvoll sein, erschwert aber den Wechsel des Betriebsmodells, Multi-Cloud-Szenarien und eine konsistente Absicherung mehrerer Umgebungen.\n",
      "image": "https://ayedo.de/kubernetes-ingress-providerunabhangig-mit-der-edge-cloud.png",
      "date_published": "2026-09-02T14:12:27Z",
      "date_modified": "2026-09-02T14:12:27Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["kubernetes","cloud-native","cloud","hosting","digital-sovereignty"],
      "language": "de"
    },{
      "id": "https://ayedo.de/posts/loadbalancer-aus-kubernetes-automatisch-provisionieren/",
      "url": "https://ayedo.de/posts/loadbalancer-aus-kubernetes-automatisch-provisionieren/",
      "title": "Loadbalancer aus Kubernetes automatisch provisionieren",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/loadbalancer-aus-kubernetes-automatisch-provisionieren/loadbalancer-aus-kubernetes-automatisch-provisionieren.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eKubernetes kann die Bereitstellung eines öffentlichen Loadbalancers als deklarativen Prozess auslösen. Ein \u003ca href=\"https://kubernetes.io/docs/concepts/services-networking/service/\" target=\"_blank\" rel=\"noopener\"\u003eKubernetes Service\u003c/a\u003e\n beschreibt dabei den gewünschten Zugang zur Anwendung, während die ayedo Edge Cloud öffentliche Erreichbarkeit, Routing und Schutz übernimmt. Das reduziert manuelle Netzwerkkonfiguration und trennt Workload- sowie Edge-Verantwortung sauber.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eEin häufiger Betriebsfehler besteht darin, Kubernetes-Workloads und öffentliche Netzwerkkonfiguration als zwei voneinander getrennte Änderungsprozesse zu behandeln. Ein Team legt einen \u003ca href=\"https://kubernetes.io/docs/concepts/services-networking/service/\" target=\"_blank\" rel=\"noopener\"\u003eKubernetes Service\u003c/a\u003e\n an, ein anderes konfiguriert anschließend manuell einen Cloud Loadbalancer, DNS-Einträge oder Backend-Ziele. Dadurch entstehen Wartezeiten, Medienbrüche und potenziell abweichende Zustände. Ein Kubernetes-nativer Bereitstellungsprozess verfolgt einen anderen Ansatz: Die gewünschte Erreichbarkeit wird als Ressource beschrieben und automatisiert umgesetzt. Entscheidend ist dabei die klare Trennung zwischen Cluster-Workload und Edge-Konfiguration. Kubernetes verwaltet die Anwendung und ihre Service-Abstraktion; die ayedo Edge Cloud übernimmt den öffentlichen Eingang, Routing, Schutz und die Verteilung des Traffics.\u003c/p\u003e\n\u003ch2 id=\"1-kubernetes-ressourcen-als-auslöser-der-provisionierung\"\u003e1. Kubernetes-Ressourcen als Auslöser der Provisionierung\u003c/h2\u003e\n\u003cp\u003eKubernetes arbeitet mit einem deklarativen Modell. Nicht einzelne Konfigurationsschritte stehen im Mittelpunkt, sondern der gewünschte Zustand: Eine Anwendung soll über einen bestimmten Service erreichbar sein, dieser Service benötigt Backends, und der externe Traffic soll diese Backends erreichen. Eine Kubernetes-native Integration kann diese Absicht erkennen und daraus die erforderliche Edge-Konfiguration ableiten.\u003c/p\u003e\n\u003cp\u003eFür den Betrieb bedeutet das: Die Bereitstellung eines Loadbalancers wird Teil des bestehenden Deployment-Prozesses. Änderungen an Ports, Backends oder dem gewünschten Zugang lassen sich gemeinsam mit der Anwendung versionieren und ausrollen. Der manuelle Wechsel zwischen Kubernetes-Konfiguration, Netzwerkportal und separaten Tickets entfällt weitgehend.\u003c/p\u003e\n\u003cp\u003eDabei wird nicht einfach ein beliebiger Loadbalancer im Cluster erzeugt. Die Edge Cloud bildet den öffentlichen Eintrittspunkt außerhalb der eigentlichen Compute-Infrastruktur. Sie kann eingehenden Traffic annehmen, verteilen und abhängig von der Konfiguration auf Kubernetes-Backends weiterleiten. Der \u003ca href=\"https://kubernetes.io/docs/concepts/services-networking/service/\" target=\"_blank\" rel=\"noopener\"\u003eKubernetes Service\u003c/a\u003e\n bleibt die Abstraktion für die Anwendung; die Edge Cloud stellt die öffentliche Erreichbarkeit bereit.\u003c/p\u003e\n\u003ch2 id=\"2-workload-und-edge-konfiguration-getrennt-betreiben\"\u003e2. Workload und Edge-Konfiguration getrennt betreiben\u003c/h2\u003e\n\u003cp\u003eDie Automatisierung funktioniert nur zuverlässig, wenn Verantwortungsbereiche nicht vermischt werden. Im Cluster liegen Deployments, Pods und interne Service-Ziele. Dort werden Replikas skaliert, \u003ca href=\"https://kubernetes.io/docs/concepts/containers/\" target=\"_blank\" rel=\"noopener\"\u003eContainer\u003c/a\u003e\n ersetzt und Anwendungen aktualisiert. Die Edge Cloud kennt dagegen den öffentlichen Endpoint und verarbeitet den Traffic, bevor er das Backend erreicht.\u003c/p\u003e\n\u003cp\u003eDiese Trennung ist technisch relevant, weil sich die Lebenszyklen unterscheiden. Ein Pod kann jederzeit neu erstellt werden, ohne dass sich der öffentliche Zugang ändern soll. Umgekehrt können TLS Termination, Web Application Firewall, DDoS Protection oder Backend Cloaking an der Edge angepasst werden, ohne die Anwendung neu zu deployen. Die Edge-Konfiguration bleibt damit eine eigenständige Schicht, auch wenn Kubernetes ihre Bereitstellung auslöst.\u003c/p\u003e\n\u003cp\u003eFür Platform-Teams entsteht ein klareres Betriebsmodell: Kubernetes beschreibt die Verbindung zur Anwendung, die Edge-Plattform setzt daraus den öffentlichen Datenpfad um. Zuständigkeiten, Berechtigungen und Änderungen lassen sich dadurch besser dokumentieren. Gleichzeitig muss festgelegt werden, welche Edge-Eigenschaften über Kubernetes verwaltet werden und welche zentralen Plattformvorgaben unterliegen.\u003c/p\u003e\n\u003ch2 id=\"3-managed-kubernetes-und-externe-cluster\"\u003e3. Managed Kubernetes und externe Cluster\u003c/h2\u003e\n\u003cp\u003eEin Kubernetes-nativer Cloud Loadbalancer ist nicht an einen bestimmten Clusterbetrieb gebunden. Die gleiche Architektur kann mit ayedo Managed Kubernetes sowie mit einem eigenen oder bei einem anderen Provider betriebenen Kubernetes-Cluster eingesetzt werden. Damit bleibt die Bereitstellung des öffentlichen Zugangs von der Frage getrennt, wo die Workloads laufen.\u003c/p\u003e\n\u003cp\u003eDas ist für Multi-Cloud- und Hybrid-Architekturen relevant. Unternehmen können ihre Compute-Infrastruktur nach fachlichen, regulatorischen oder betrieblichen Kriterien wählen, während die Edge-Funktionen zentral über eine eigene Netzwerk-Infrastruktur und ein eigenes Autonomous System bereitgestellt werden. Die ayedo Edge Cloud arbeitet dabei als verteilte Multi-PoP-Plattform im Aktiv-Aktiv-Prinzip und ist nicht lediglich ein lokaler Bestandteil eines Managed-Kubernetes-Angebots.\u003c/p\u003e\n\u003cp\u003eFür den Betrieb reduziert diese Entkopplung die Abhängigkeit von einem einzelnen Provider. Ein Clusterwechsel muss nicht zwangsläufig eine neue öffentliche Zugangsarchitektur erfordern. Entscheidend bleiben die Erreichbarkeit der Backends, die Zuständigkeiten für Änderungen und die technische Integration zwischen Kubernetes und Edge-Plattform. Diese Punkte sollten vor der Automatisierung eindeutig definiert werden.\u003c/p\u003e\n\u003ch2 id=\"4-betriebsfolgen-weniger-handarbeit-mehr-zustandsdisziplin\"\u003e4. Betriebsfolgen: weniger Handarbeit, mehr Zustandsdisziplin\u003c/h2\u003e\n\u003cp\u003eAutomatisierung beseitigt keine Betriebsverantwortung; sie verlagert sie. Statt manuelle Konfigurationsschritte auszuführen, müssen Teams den gewünschten Zustand, Berechtigungen und Lebenszyklus der Ressourcen sauber festlegen. Wird ein Service entfernt, sollte auch der zugehörige öffentliche Zugang kontrolliert verschwinden. Bleibt eine alte Edge-Konfiguration bestehen, entstehen unnötige Angriffsflächen und Kosten.\u003c/p\u003e\n\u003cp\u003eBackend Health Checks und Failover helfen dabei, nicht verfügbare Ziele aus dem Trafficpfad zu nehmen. Traffic- und Usage-Statistiken schaffen zusätzlich eine Grundlage für die Betriebsanalyse. Diese Funktionen ersetzen jedoch kein Monitoring der Anwendung: Die Edge erkennt die Erreichbarkeit eines Backends, aber nicht automatisch jede fachliche Fehlfunktion.\u003c/p\u003e\n\u003cp\u003eSecurity-seitig ist wichtig, dass öffentliche Endpunkte nicht versehentlich direkt auf interne Strukturen zeigen. Backend Cloaking kann die eigentliche Backend-Topologie gegenüber externen Clients verbergen. TLS Termination und eine Web Application Firewall lassen sich an der Edge verankern. Dadurch werden Sicherheits- und Routingfunktionen zentral betrieben, während die Anwendungsteams ihren \u003ca href=\"https://kubernetes.io/docs/concepts/services-networking/service/\" target=\"_blank\" rel=\"noopener\"\u003eKubernetes-Service\u003c/a\u003e\n deklarativ verwalten.\u003c/p\u003e\n\u003ch2 id=\"praxis--und-betriebsszenario\"\u003ePraxis- und Betriebsszenario\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt eine Webanwendung in einem Kubernetes-Cluster bei einem externen Provider. Das Team erstellt einen \u003ca href=\"https://kubernetes.io/docs/concepts/services-networking/service/\" target=\"_blank\" rel=\"noopener\"\u003eKubernetes Service\u003c/a\u003e\n für den HTTP-Zugang und beschreibt den gewünschten öffentlichen Endpoint. Die Kubernetes-Integration löst daraufhin die Bereitstellung der passenden Edge-Konfiguration aus. Die Anwendung bleibt im Cluster, während die ayedo Edge Cloud den öffentlichen Traffic entgegennimmt und an die verfügbaren Backends verteilt.\u003c/p\u003e\n\u003cp\u003eBei einem manuellen Modell müssten Netzwerkverantwortliche Endpoint, Backend-Ziele und Schutzfunktionen separat einrichten. Bei einem deklarativen Modell werden Änderungen am Service gemeinsam mit dem Anwendungscode ausgerollt. Ein späterer Wechsel zu ayedo Managed Kubernetes verändert den öffentlichen Bereitstellungsprozess nicht grundsätzlich. Die Compute-Schicht wechselt, die Edge-Verantwortung bleibt davon getrennt.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"muss-der-kubernetes-cluster-bei-ayedo-betrieben-werden\"\u003eMuss der Kubernetes-Cluster bei ayedo betrieben werden?\u003c/h3\u003e\n\u003cp\u003eNein. Die Kubernetes-native Integration kann mit ayedo Managed Kubernetes sowie mit eigenen oder bei anderen Providern betriebenen Kubernetes-Clustern genutzt werden.\u003c/p\u003e\n\u003ch3 id=\"ersetzt-ein-kubernetes-service-die-gesamte-edge-konfiguration\"\u003eErsetzt ein Kubernetes Service die gesamte Edge-Konfiguration?\u003c/h3\u003e\n\u003cp\u003eNein. Der Service beschreibt den Zugang zur Workload. Öffentliche Routing-, Schutz- und Termination-Funktionen gehören zur Edge-Schicht und werden dort entsprechend umgesetzt.\u003c/p\u003e\n\u003ch3 id=\"was-passiert-bei-einer-änderung-der-anwendung\"\u003eWas passiert bei einer Änderung der Anwendung?\u003c/h3\u003e\n\u003cp\u003eDer deklarierte Zustand wird erneut verarbeitet. Änderungen an Backends oder Services können dadurch in den öffentlichen Datenpfad übernommen werden, ohne jeden Netzwerkschritt manuell auszuführen.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eKubernetes Loadbalancer Provisionierung ist vor allem eine Frage des Betriebsmodells: Öffentliche Erreichbarkeit wird als gewünschter Zustand beschrieben, statt sie über separate manuelle Netzwerkschritte zu pflegen. Die notwendige Voraussetzung ist eine saubere Trennung von Workload und Edge. Die ayedo Edge Cloud unterstützt dieses Modell providerunabhängig und verbindet Kubernetes-native Bereitstellung mit zentralem Routing, Schutz und Traffic-Verteilung an der öffentlichen Netzgrenze.\u003c/p\u003e\n",
      "summary": "\nTL;DR Kubernetes kann die Bereitstellung eines öffentlichen Loadbalancers als deklarativen Prozess auslösen. Ein Kubernetes Service beschreibt dabei den gewünschten Zugang zur Anwendung, während die ayedo Edge Cloud öffentliche Erreichbarkeit, Routing und Schutz übernimmt. Das reduziert manuelle Netzwerkkonfiguration und trennt Workload- sowie Edge-Verantwortung sauber.\nEinleitung Ein häufiger Betriebsfehler besteht darin, Kubernetes-Workloads und öffentliche Netzwerkkonfiguration als zwei voneinander getrennte Änderungsprozesse zu behandeln. Ein Team legt einen Kubernetes Service an, ein anderes konfiguriert anschließend manuell einen Cloud Loadbalancer, DNS-Einträge oder Backend-Ziele. Dadurch entstehen Wartezeiten, Medienbrüche und potenziell abweichende Zustände. Ein Kubernetes-nativer Bereitstellungsprozess verfolgt einen anderen Ansatz: Die gewünschte Erreichbarkeit wird als Ressource beschrieben und automatisiert umgesetzt. Entscheidend ist dabei die klare Trennung zwischen Cluster-Workload und Edge-Konfiguration. Kubernetes verwaltet die Anwendung und ihre Service-Abstraktion; die ayedo Edge Cloud übernimmt den öffentlichen Eingang, Routing, Schutz und die Verteilung des Traffics.\n",
      "image": "https://ayedo.de/loadbalancer-aus-kubernetes-automatisch-provisionieren.png",
      "date_published": "2026-09-02T14:12:27Z",
      "date_modified": "2026-09-02T14:12:27Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["kubernetes","automation","software-delivery","cloud-native","digital-sovereignty"],
      "language": "de"
    },{
      "id": "https://ayedo.de/posts/providerunabhangige-loadbalancer-fur-kubernetes-apis/",
      "url": "https://ayedo.de/posts/providerunabhangige-loadbalancer-fur-kubernetes-apis/",
      "title": "Providerunabhängige Loadbalancer für Kubernetes-APIs",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/providerunabhangige-loadbalancer-fur-kubernetes-apis/providerunabhangige-loadbalancer-fur-kubernetes-apis.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eDer \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n API Server ist kein gewöhnliches Ingress-Ziel, sondern der zentrale Steuerungspunkt eines Clusters. Ein Kubernetes API Server Loadbalancer muss deshalb Erreichbarkeit, Failover und Zugriffsschutz zusammenführen. Die ayedo Edge Cloud veröffentlicht Kubernetes-APIs providerunabhängig über Anycast Layer 4 und schützt die Backend-Adressen durch \u003ca href=\"/kubernetes/\"\u003eBackend Cloaking\u003c/a\u003e\n.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eDer Kubernetes API Server wird in vielen Architekturen wie ein weiterer öffentlicher Service behandelt. Das ist ein Fehler: Über seine API werden Workloads verändert, Secrets verwaltet und Clusterzustände gesteuert. Ein öffentlich erreichbarer Control-Plane-Endpunkt braucht daher eine andere Schutz- und Betriebsstrategie als ein gewöhnlicher Ingress. Gleichzeitig müssen Administratoren, CI/CD-Systeme und Cluster-Komponenten einen stabilen Endpoint erreichen, auch wenn sich die Compute-Infrastruktur oder der Provider ändert. Ein Kubernetes API Server Loadbalancer ist damit nicht nur eine Verteilungsfunktion. Er bildet die kontrollierte öffentliche Grenze zwischen Kubernetes Control Plane und den zugreifenden Clients.\u003c/p\u003e\n\u003ch2 id=\"1-der-api-server-ist-ein-besonders-schützenswerter-endpoint\"\u003e1. Der API Server ist ein besonders schützenswerter Endpoint\u003c/h2\u003e\n\u003cp\u003eDer Kubernetes API Server ist die zentrale Verwaltungsschnittstelle eines Clusters. Jeder erfolgreiche Zugriff kann direkte Auswirkungen auf Deployments, Berechtigungen, Netzwerkregeln oder gespeicherte Konfigurationen haben. Ein Ausfall verhindert zudem viele Betriebsaktionen: Rollouts, Skalierung, Node-Verwaltung und automatisierte Controller-Prozesse können beeinträchtigt werden.\u003c/p\u003e\n\u003cp\u003eDas unterscheidet den API Server von einem typischen HTTP-Service hinter einem Ingress. Bei einem Ingress steht häufig die Anwendungserreichbarkeit im Vordergrund. Beim Control Plane Endpoint geht es zusätzlich um administrative Vertrauensgrenzen und die Verfügbarkeit des gesamten Clusters. Deshalb sollte der API Server nicht unnötig mit seiner tatsächlichen Backend-Adresse im Internet sichtbar sein.\u003c/p\u003e\n\u003cp\u003eDie öffentliche Adresse kann stattdessen an einer Edge-Schicht terminieren, während die eigentlichen API-Server-Backends verborgen bleiben. Diese Trennung reduziert die direkte Angriffsfläche und schafft einen kontrollierten Übergang für eingehende Verbindungen. Zugriffskontrolle, Authentisierung und Autorisierung bleiben dabei Aufgaben der Kubernetes- und Identitätsarchitektur; der Loadbalancer ersetzt diese Mechanismen nicht.\u003c/p\u003e\n\u003ch2 id=\"2-anycast-layer-4-für-stabile-control-plane-erreichbarkeit\"\u003e2. Anycast Layer 4 für stabile Control-Plane-Erreichbarkeit\u003c/h2\u003e\n\u003cp\u003eFür den Kubernetes API Server ist Layer-4-Weiterleitung häufig die passende Abstraktion. Der Loadbalancer muss TCP-Verbindungen zuverlässig zu verfügbaren API-Server-Backends verteilen, ohne die Kubernetes-Kommunikation als gewöhnlichen HTTP-Anwendungsverkehr interpretieren zu müssen. Das ist besonders relevant, wenn TLS zwischen Client und API Server durchgängig erhalten bleiben soll.\u003c/p\u003e\n\u003cp\u003eAnycast Loadbalancing stellt dabei eine global annoncierte Zieladresse bereit. Zugriffe werden an einen geeigneten Edge-Standort geführt, statt dass Clients eine einzelne Infrastrukturadresse oder einen providergebundenen Einstiegspunkt verwenden müssen. In Verbindung mit Backend Health Checks und Failover kann die Edge-Schicht nicht verfügbare Backends aus der Verteilung nehmen.\u003c/p\u003e\n\u003cp\u003eFür den Betrieb bedeutet das: Der kubeconfig-Endpoint, Automatisierungsjobs und externe Verwaltungszugriffe müssen bei Änderungen an der Compute-Infrastruktur nicht zwangsläufig angepasst werden. Die tatsächliche Topologie der Control Plane bleibt hinter dem stabilen Zugangspunkt verborgen. Anycast ersetzt jedoch keine redundante Kubernetes Control Plane. Es verbessert den Zugang zu verfügbaren Backends, kann aber keine fehlerhaften oder falsch konfigurierten API-Server reparieren.\u003c/p\u003e\n\u003ch2 id=\"3-backend-cloaking-trennt-endpoint-und-control-plane\"\u003e3. Backend Cloaking trennt Endpoint und Control Plane\u003c/h2\u003e\n\u003cp\u003eEin zentraler Sicherheitsgewinn entsteht, wenn die Backend-Adressen des API Servers nicht als öffentliche Zieladressen verwendet werden. \u003ca href=\"/kubernetes/\"\u003eBackend Cloaking\u003c/a\u003e\n beschreibt genau diese Trennung: Der Client verbindet sich mit dem Edge-Endpoint, während die ayedo Edge Cloud die Verbindung zu den konfigurierten API-Server-Backends herstellt.\u003c/p\u003e\n\u003cp\u003eDamit wird nicht nur eine IP-Adresse versteckt. Auch die Netzwerktopologie des Clusters wird weniger direkt nach außen sichtbar. Änderungen an Nodes, Control-Plane-Instanzen oder der zugrunde liegenden Infrastruktur müssen nicht automatisch zu einer Änderung des öffentlichen Kubernetes-Endpunkts führen. Das vereinfacht Migrationen und reduziert die Kopplung zwischen Clusterbetrieb und DNS- oder Clientkonfiguration.\u003c/p\u003e\n\u003cp\u003eBackend Cloaking ist trotzdem kein vollständiger Schutz gegen missbräuchliche API-Zugriffe. Ein Angreifer, der den öffentlichen Endpoint kennt, kann weiterhin Verbindungsversuche gegen die API richten. Deshalb bleiben starke Kubernetes-Authentisierung, restriktive Autorisierung, geeignete Netzwerkpfade und eine kontrollierte Administration erforderlich. Die Edge Cloud ergänzt diese Kontrollen um eine vorgelagerte, providerunabhängige Netzwerkgrenze.\u003c/p\u003e\n\u003ch2 id=\"4-providerunabhängigkeit-als-architekturentscheidung\"\u003e4. Providerunabhängigkeit als Architekturentscheidung\u003c/h2\u003e\n\u003cp\u003eEin Kubernetes API Server Loadbalancer sollte nicht untrennbar an die Compute-Plattform gekoppelt sein. Cluster können in ayedo Managed Kubernetes, in einer eigenen Umgebung oder bei einem anderen Provider betrieben werden. Der öffentliche Control-Plane-Zugang bleibt dabei als eigenständige Architekturkomponente bestehen.\u003c/p\u003e\n\u003cp\u003eDie ayedo Edge Cloud nutzt dafür Anycast-basiertes Layer-4-Loadbalancing, eine eigene Netzwerk-Infrastruktur und ein eigenes Autonomous System. Die verteilte Multi-PoP-Architektur sowie das Aktiv-Aktiv-Prinzip unterstützen einen Zugang, der nicht auf eine einzelne Providerregion oder ein einzelnes Netzwerksegment reduziert ist. Die Backends können weiterhin in der jeweils verantworteten Compute-Umgebung liegen.\u003c/p\u003e\n\u003cp\u003eDiese Entkopplung verändert auch Verantwortlichkeiten. Das Clusterteam betreibt und sichert die Kubernetes Control Plane. Die Edge-Schicht übernimmt den öffentlichen Einstieg, die Weiterleitung, \u003ca href=\"/kubernetes/\"\u003eBackend-Cloaking\u003c/a\u003e\n und die Verfügbarkeitsprüfung der konfigurierten Ziele. Dadurch lassen sich Providerwechsel oder hybride Betriebsmodelle planen, ohne den externen API-Endpunkt als impliziten Bestandteil einer einzelnen Compute-Plattform zu behandeln.\u003c/p\u003e\n\u003ch2 id=\"praxisszenario-clusterwechsel-ohne-änderung-des-api-endpunkts\"\u003ePraxisszenario: Clusterwechsel ohne Änderung des API-Endpunkts\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt einen Kubernetes-Cluster zunächst bei einem externen Cloud-Provider und plant später den Umzug in eine eigene Infrastruktur. Der API Server ist über eine feste öffentliche Adresse erreichbar, die in kubeconfig-Dateien, CI/CD-Systemen und Administrationsprozessen verwendet wird.\u003c/p\u003e\n\u003cp\u003eStatt diese Adresse direkt auf eine Control-Plane-Instanz zeigen zu lassen, liegt sie auf einem Anycast-Endpoint der Edge Cloud. Die API-Server-Adressen werden als Backends hinterlegt und durch Health Checks überwacht. Während der Migration werden neue Backends ergänzt, getestet und anschließend priorisiert oder alte Ziele entfernt. Clients verwenden weiterhin denselben Endpoint. Die Zugriffsrechte und Kubernetes-Authentisierung ändern sich dadurch nicht; lediglich der öffentliche Netzwerkpfad und die Backend-Zuordnung werden kontrolliert betrieben.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"ist-ein-kubernetes-api-server-ein-ingress-ziel\"\u003eIst ein Kubernetes API Server ein Ingress-Ziel?\u003c/h3\u003e\n\u003cp\u003eNein. Der API Server dient der Clusterverwaltung und hat andere Schutz- und Verfügbarkeitsanforderungen als Anwendungsverkehr. Ein Ingress-Controller ist daher nicht automatisch die passende Veröffentlichungsstrategie.\u003c/p\u003e\n\u003ch3 id=\"muss-der-cluster-bei-ayedo-managed-kubernetes-laufen\"\u003eMuss der Cluster bei ayedo Managed Kubernetes laufen?\u003c/h3\u003e\n\u003cp\u003eNein. Die ayedo Edge Cloud kann Kubernetes-API-Backends auch für eigene Cluster oder Cluster bei anderen Providern bereitstellen.\u003c/p\u003e\n\u003ch3 id=\"ersetzt-backend-cloaking-die-kubernetes-authentisierung\"\u003eErsetzt Backend Cloaking die Kubernetes-Authentisierung?\u003c/h3\u003e\n\u003cp\u003eNein. Cloaking verbirgt die Backend-Adressen und reduziert die direkte Angriffsfläche. Authentisierung und Autorisierung des API Servers bleiben weiterhin erforderlich.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eDer Kubernetes API Server sollte als geschützter Control-Plane-Endpoint behandelt werden, nicht als gewöhnlicher Dienst hinter einem Ingress. Anycast Layer 4 sorgt für einen stabilen, providerunabhängigen Zugang; Backend Cloaking trennt diesen Zugang von den tatsächlichen Control-Plane-Adressen. Die ayedo Edge Cloud ordnet diese Funktionen als eigenständige Edge-Plattform vor der Compute-Infrastruktur ein und unterstützt damit Clusterarchitekturen über verschiedene Betriebsmodelle hinweg.\u003c/p\u003e\n",
      "summary": "\nTL;DR Der Kubernetes API Server ist kein gewöhnliches Ingress-Ziel, sondern der zentrale Steuerungspunkt eines Clusters. Ein Kubernetes API Server Loadbalancer muss deshalb Erreichbarkeit, Failover und Zugriffsschutz zusammenführen. Die ayedo Edge Cloud veröffentlicht Kubernetes-APIs providerunabhängig über Anycast Layer 4 und schützt die Backend-Adressen durch Backend Cloaking .\nEinleitung Der Kubernetes API Server wird in vielen Architekturen wie ein weiterer öffentlicher Service behandelt. Das ist ein Fehler: Über seine API werden Workloads verändert, Secrets verwaltet und Clusterzustände gesteuert. Ein öffentlich erreichbarer Control-Plane-Endpunkt braucht daher eine andere Schutz- und Betriebsstrategie als ein gewöhnlicher Ingress. Gleichzeitig müssen Administratoren, CI/CD-Systeme und Cluster-Komponenten einen stabilen Endpoint erreichen, auch wenn sich die Compute-Infrastruktur oder der Provider ändert. Ein Kubernetes API Server Loadbalancer ist damit nicht nur eine Verteilungsfunktion. Er bildet die kontrollierte öffentliche Grenze zwischen Kubernetes Control Plane und den zugreifenden Clients.\n",
      "image": "https://ayedo.de/providerunabhangige-loadbalancer-fur-kubernetes-apis.png",
      "date_published": "2026-09-02T14:12:27Z",
      "date_modified": "2026-09-02T14:12:27Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["kubernetes","cloud","software-delivery","security","development"],
      "language": "de"
    },{
      "id": "https://ayedo.de/posts/automatisches-failover-fur-kubernetes-backends-planen/",
      "url": "https://ayedo.de/posts/automatisches-failover-fur-kubernetes-backends-planen/",
      "title": "Automatisches Failover für Kubernetes-Backends planen",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/automatisches-failover-fur-kubernetes-backends-planen/automatisches-failover-fur-kubernetes-backends-planen.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eKubernetes Backend Failover beginnt nicht beim Umschalten des Traffics, sondern bei klar definierten Zuständen: Welche Endpunkte gelten als gesund, wann wird ein Backend aus dem Routing genommen und wohin wird weitergeleitet? Die ayedo Edge Cloud trennt diese Edge-Entscheidung von der Verfügbarkeit der \u003ca href=\"/kubernetes/\"\u003eKubernetes-Workloads\u003c/a\u003e\n und schafft damit eine belastbare Grundlage für kontrolliertes Failover.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eEin \u003ca href=\"/kubernetes/\"\u003eKubernetes-Service\u003c/a\u003e\n kann intern verfügbar sein und trotzdem von außen nicht zuverlässig erreichbar bleiben. Umgekehrt kann ein Backend technisch antworten, obwohl die Anwendung bereits fehlerhafte oder unvollständige Antworten liefert. Genau deshalb ist automatisches Failover keine einzelne Loadbalancer-Funktion, sondern eine Architekturentscheidung: Health Checks müssen den relevanten Zustand prüfen, Failover-Regeln müssen zum Betriebsmodell passen und die Kubernetes-Workloads müssen selbst hochverfügbar ausgelegt sein. Die Edge Cloud kann öffentlichen Traffic bei einem erkannten Backend-Ausfall kontrolliert umleiten. Sie ersetzt jedoch weder Replica-Strategien noch Pod-Scheduling, Datenbankreplikation oder Disaster-Recovery-Verfahren innerhalb der Compute-Infrastruktur.\u003c/p\u003e\n\u003ch2 id=\"1-health-checks-müssen-den-richtigen-fehler-erkennen\"\u003e1. Health Checks müssen den richtigen Fehler erkennen\u003c/h2\u003e\n\u003cp\u003eEin Backend Health Check beantwortet nicht pauschal die Frage, ob ein Kubernetes-Cluster „online“ ist. Er prüft einen definierten technischen Zustand: Erreichbarkeit, Protokollverhalten oder die Antwort eines festgelegten Endpunkts. Ein einfacher TCP-Check erkennt beispielsweise, dass ein Port Verbindungen annimmt. Er sagt jedoch wenig darüber aus, ob die Anwendung Requests korrekt verarbeitet. Ein HTTP-Check kann dagegen Statuscodes oder die Erreichbarkeit eines konkreten Pfads bewerten.\u003c/p\u003e\n\u003cp\u003eFür Kubernetes-Backends sollte der Prüfpunkt zur Verantwortungsgrenze passen. Ein Readiness-Zustand innerhalb des Clusters und ein Health Check an der öffentlichen Edge verfolgen ähnliche, aber nicht identische Ziele. Die Kubernetes-Steuerung entscheidet, ob ein Pod Traffic erhalten soll. Die Edge Cloud entscheidet, ob ein öffentlich erreichbares Backend für eingehenden Traffic verwendet wird. Werden beide Ebenen vermischt, entstehen falsche Sicherheit oder unnötige Failover-Ereignisse.\u003c/p\u003e\n\u003ch2 id=\"2-failover-regeln-brauchen-eindeutige-zustände\"\u003e2. Failover-Regeln brauchen eindeutige Zustände\u003c/h2\u003e\n\u003cp\u003eKubernetes Backend Failover funktioniert nur zuverlässig, wenn Ausfall, Degradation und Wartung unterscheidbar sind. Ein einzelner fehlgeschlagener Check sollte nicht automatisch zu einer sofortigen globalen Umschaltung führen. Netzwerkunterbrechungen, kurze Neustarts oder temporäre Überlast können sonst unnötige Routingwechsel auslösen. Umgekehrt darf ein dauerhaft fehlerhaftes Backend nicht zu lange als gesund gelten.\u003c/p\u003e\n\u003cp\u003eBei der Planung sind deshalb Prüfintervall, Fehlergrenze und Wiederfreigabe gemeinsam zu betrachten. Entscheidend ist außerdem, ob auf ein alternatives Backend, einen anderen Cluster oder eine bewusst begrenzte Fehlerantwort umgeschaltet wird. Traffic Failover ist kein Versuch, beliebige Kapazität zu erzeugen. Das Ziel besteht darin, Requests nur an ein Ziel weiterzuleiten, dessen Betriebszustand bekannt und für den jeweiligen Service geeignet ist.\u003c/p\u003e\n\u003cp\u003eDie ayedo Edge Cloud stellt dafür Backend Health Checks und Failover auf der öffentlichen Traffic-Ebene bereit. Die konkrete Wirkung hängt von den definierten Backends und Routing-Regeln ab. Eine automatische Umschaltung sollte daher immer mit Runbooks, Monitoring und einem kontrollierten Rückschaltverhalten verbunden werden.\u003c/p\u003e\n\u003ch2 id=\"3-edge-failover-und-workload-verfügbarkeit-trennen\"\u003e3. Edge-Failover und Workload-Verfügbarkeit trennen\u003c/h2\u003e\n\u003cp\u003eDie Edge kann einen ausgefallenen Cluster aus dem öffentlichen Routing nehmen. Sie stellt dadurch aber keine neuen Pods bereit, repariert keine fehlerhafte Anwendung und synchronisiert keine Daten. Kubernetes Hochverfügbarkeit bleibt eine Aufgabe der Compute-Infrastruktur. Dazu gehören unter anderem ausreichende Replikate, Verteilung über geeignete Ausfallbereiche, funktionierende Readiness- und Liveness-Mechanismen sowie die Verfügbarkeit abhängiger Systeme.\u003c/p\u003e\n\u003cp\u003eDiese Trennung ist auch für die Fehlersuche wichtig. Wenn die Edge einen Cluster wegen fehlgeschlagener Checks aus dem Traffic nimmt, kann der Fehler im Ingress-Pfad, im Service, in der Anwendung oder in einer nachgelagerten Abhängigkeit liegen. Wenn dagegen die Workloads gesund sind, aber DNS, Netzwerk oder ein vorgelagerter Zugang ausfallen, kann ein Edge-Failover die Erreichbarkeit verbessern.\u003c/p\u003e\n\u003cp\u003eDie ayedo Edge Cloud bildet den öffentlichen Eingang vor Anwendungen und APIs. Sie kann \u003ca href=\"/kubernetes/\"\u003eKubernetes-Backends\u003c/a\u003e\n über die Edge absichern und verteilen, unabhängig davon, ob die Cluster mit ayedo Managed Kubernetes oder bei einem anderen Provider betrieben werden. Die Verfügbarkeit der Workloads muss trotzdem separat geplant und nachgewiesen werden.\u003c/p\u003e\n\u003ch2 id=\"4-failover-verändert-betrieb-security-und-kosten\"\u003e4. Failover verändert Betrieb, Security und Kosten\u003c/h2\u003e\n\u003cp\u003eEin Failover verschiebt nicht nur IP-Traffic. Es verändert Lastverteilung, Fehlerbilder, Logquellen und möglicherweise die Datenpfade einer Anwendung. Das alternative Backend muss deshalb dieselben Protokolle, Zertifikatsannahmen und Request-Erwartungen erfüllen. Backend Cloaking kann dabei die interne Struktur der Cluster aus dem öffentlichen Zugriff herausnehmen: Clients kommunizieren mit der Edge, nicht direkt mit den eigentlichen Backend-Adressen.\u003c/p\u003e\n\u003cp\u003eAuch Sicherheitskontrollen müssen im Umschaltfall gelten. WAF, TLS Termination und DDoS Protection sollten nicht nur für das primäre Ziel betrachtet werden, sondern als zentrale Edge-Funktionen für den gesamten öffentlichen Pfad. Gleichzeitig kann Failover Betriebskosten erhöhen, wenn ein alternatives Backend dauerhaft vorgehalten, synchronisiert und überwacht werden muss. Ein nominelles Zweit-Backend ohne getestete Kapazität ist keine belastbare Hochverfügbarkeitsstrategie.\u003c/p\u003e\n\u003cp\u003eDie ayedo Edge Cloud nutzt eine verteilte Multi-PoP-Architektur, ein eigenes Autonomous System und ein Aktiv-Aktiv-Prinzip. Für die Planung bedeutet das: Edge-seitige Ausfallszenarien und Backend-seitige Ausfallszenarien sind getrennt zu bewerten. Erst diese Trennung zeigt, welchen Fehler das Failover tatsächlich behandelt.\u003c/p\u003e\n\u003ch2 id=\"praxis--und-betriebsszenario\"\u003ePraxis- und Betriebsszenario\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt einen öffentlichen API-Service auf zwei Kubernetes-Clustern bei unterschiedlichen Providern. Cluster A ist primär, Cluster B dient als alternatives Backend. Die Edge prüft einen dedizierten, anwendungsnahen HTTP-Endpunkt und entfernt Cluster A bei wiederholtem Fehlschlag aus dem Routing. Der Traffic wird anschließend an Cluster B weitergeleitet.\u003c/p\u003e\n\u003cp\u003eVor dem produktiven Einsatz muss geklärt sein, ob Cluster B aktuelle Daten besitzt, ausreichende Kapazität hat und dieselben Sicherheits- und Protokollanforderungen erfüllt. Ebenso braucht es einen Test für Rückschaltung und einen Mechanismus, der bei einer fehlerhaften Anwendung nicht beide Cluster gleichzeitig als gesund bewertet. Die Edge behandelt den Ausfall des Backends; die Anwendungsteams verantworten Datenkonsistenz und Workload-Betrieb.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"was-ist-der-unterschied-zwischen-kubernetes-hochverfügbarkeit-und-edge-failover\"\u003eWas ist der Unterschied zwischen Kubernetes-Hochverfügbarkeit und Edge-Failover?\u003c/h3\u003e\n\u003cp\u003eKubernetes-Hochverfügbarkeit hält Workloads innerhalb der Compute-Infrastruktur verfügbar. Edge-Failover steuert, welches erreichbare Backend öffentlichen Traffic erhält. Beide Ebenen ergänzen sich, ersetzen einander aber nicht.\u003c/p\u003e\n\u003ch3 id=\"muss-das-alternative-kubernetes-backend-beim-selben-provider-liegen\"\u003eMuss das alternative Kubernetes-Backend beim selben Provider liegen?\u003c/h3\u003e\n\u003cp\u003eNein. Ein Failover-Design kann auch Cluster bei unterschiedlichen Providern einbeziehen. Entscheidend sind technische Kompatibilität, Datenversorgung, Kapazität und ein getesteter Betriebsprozess.\u003c/p\u003e\n\u003ch3 id=\"wann-ist-ein-health-check-zu-oberflächlich\"\u003eWann ist ein Health Check zu oberflächlich?\u003c/h3\u003e\n\u003cp\u003eWenn er nur Netzwerkport oder Prozessstatus prüft, obwohl die Anwendung bereits keine gültigen Antworten liefert. Für öffentliche Services sollte der Check einen für den Traffic relevanten Zustand abbilden.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eAutomatisches Failover ist dann belastbar, wenn die Zuständigkeiten präzise getrennt sind: Die Edge erkennt den Zustand öffentlicher Backends und steuert den Traffic, \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n und die Compute-Infrastruktur sichern die Workloads und ihre Abhängigkeiten. Die ayedo Edge Cloud unterstützt diese Architektur mit Backend Health Checks und Failover für Kubernetes-Umgebungen, auch außerhalb von ayedo Managed Kubernetes. Entscheidend bleiben realistische Prüfpunkte, geeignete Alternativen und regelmäßig getestete Umschaltprozesse.\u003c/p\u003e\n",
      "summary": "\nTL;DR Kubernetes Backend Failover beginnt nicht beim Umschalten des Traffics, sondern bei klar definierten Zuständen: Welche Endpunkte gelten als gesund, wann wird ein Backend aus dem Routing genommen und wohin wird weitergeleitet? Die ayedo Edge Cloud trennt diese Edge-Entscheidung von der Verfügbarkeit der Kubernetes-Workloads und schafft damit eine belastbare Grundlage für kontrolliertes Failover.\nEinleitung Ein Kubernetes-Service kann intern verfügbar sein und trotzdem von außen nicht zuverlässig erreichbar bleiben. Umgekehrt kann ein Backend technisch antworten, obwohl die Anwendung bereits fehlerhafte oder unvollständige Antworten liefert. Genau deshalb ist automatisches Failover keine einzelne Loadbalancer-Funktion, sondern eine Architekturentscheidung: Health Checks müssen den relevanten Zustand prüfen, Failover-Regeln müssen zum Betriebsmodell passen und die Kubernetes-Workloads müssen selbst hochverfügbar ausgelegt sein. Die Edge Cloud kann öffentlichen Traffic bei einem erkannten Backend-Ausfall kontrolliert umleiten. Sie ersetzt jedoch weder Replica-Strategien noch Pod-Scheduling, Datenbankreplikation oder Disaster-Recovery-Verfahren innerhalb der Compute-Infrastruktur.\n",
      "image": "https://ayedo.de/automatisches-failover-fur-kubernetes-backends-planen.png",
      "date_published": "2026-09-02T14:11:46Z",
      "date_modified": "2026-09-02T14:11:46Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["kubernetes","operations","cloud-native","digital-sovereignty","software-delivery"],
      "language": "de"
    },{
      "id": "https://ayedo.de/posts/edge-cloud-mit-eigenen-kubernetes-clustern-nutzen/",
      "url": "https://ayedo.de/posts/edge-cloud-mit-eigenen-kubernetes-clustern-nutzen/",
      "title": "Edge Cloud mit eigenen Kubernetes-Clustern nutzen",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/edge-cloud-mit-eigenen-kubernetes-clustern-nutzen/edge-cloud-mit-eigenen-kubernetes-clustern-nutzen.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eEin \u003ca href=\"/kubernetes/\"\u003eKubernetes-Cluster\u003c/a\u003e\n muss nicht beim selben Anbieter betrieben werden wie die Edge-Infrastruktur. Die ayedo Edge Cloud trennt den öffentlichen Traffic-Eingang von der Compute-Plattform und kann dadurch mit selbst betriebenen sowie bei anderen Providern laufenden Kubernetes-Clustern eingesetzt werden. Das schafft Providerunabhängigkeit, verändert aber Anforderungen an Routing, Security und Betrieb.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eEin häufiger Architekturfehler besteht darin, Edge und Compute als untrennbare Einheit zu planen. Wird Kubernetes selbst betrieben oder bei einem anderen Provider genutzt, landet der öffentliche Traffic oft direkt am Cluster oder an einem providergebundenen Ingress. Damit werden Schutzfunktionen, TLS-Terminierung, Failover und Routing eng an die jeweilige Compute-Plattform gekoppelt. Die technische Alternative ist eine klare Trennung: Die Edge Cloud bildet den öffentlichen Eingang, während der \u003ca href=\"/kubernetes/\"\u003eKubernetes-Cluster\u003c/a\u003e\n ausschließlich die Anwendungen und Services ausführt. Diese Entscheidung erweitert die Auswahl möglicher Compute-Provider, bringt aber zusätzliche Anforderungen an Backend-Erreichbarkeit, Zustandsüberwachung und Verantwortungsgrenzen mit sich.\u003c/p\u003e\n\u003ch2 id=\"1-edge-und-kubernetes-als-getrennte-verantwortungsbereiche\"\u003e1. Edge und Kubernetes als getrennte Verantwortungsbereiche\u003c/h2\u003e\n\u003cp\u003eEin \u003ca href=\"/kubernetes/\"\u003eKubernetes-Cluster\u003c/a\u003e\n ist in erster Linie eine Plattform zum Ausführen und Orchestrieren von Workloads. Er stellt Services bereit, skaliert Pods und verarbeitet internen sowie anwendungsbezogenen Traffic. Die Edge Cloud übernimmt davor eine andere Aufgabe: Sie nimmt öffentlichen Traffic an, wendet Routing- und Schutzmechanismen an und verteilt Anfragen an erreichbare Backends.\u003c/p\u003e\n\u003cp\u003eDiese Trennung ist auch dann sinnvoll, wenn der Cluster selbst betrieben wird. Anwendungen müssen nicht direkt aus dem Internet erreichbar sein. Stattdessen kann die Edge Cloud als kontrollierter Eintrittspunkt dienen. Backend Cloaking reduziert dabei die öffentliche Sichtbarkeit der eigentlichen Cluster-Endpunkte. TLS Termination, Web Application Firewall und DDoS Protection liegen an der Edge, während \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n die Anwendungslogik ausführt.\u003c/p\u003e\n\u003cp\u003eFür den Betrieb bedeutet das eine klare Zuständigkeit: Das Plattformteam verantwortet Cluster, Workloads und interne Services; die Edge-Verantwortung umfasst öffentlichen Traffic, Routing, Schutz und Failover. Diese Aufteilung verhindert, dass jeder Cluster eigene, teilweise unterschiedliche Internet-facing-Komponenten betreiben muss.\u003c/p\u003e\n\u003ch2 id=\"2-selbst-betriebenes-kubernetes-und-multi-cloud\"\u003e2. Selbst betriebenes Kubernetes und Multi-Cloud\u003c/h2\u003e\n\u003cp\u003eBeim \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n Cluster an Edge Cloud anbinden ist zunächst die Compute-Herkunft zweitrangig. Ein Cluster kann im eigenen Rechenzentrum, in einer Public Cloud oder bei einem spezialisierten Provider laufen. Entscheidend ist, dass die vorgesehenen Backends aus der Edge erreichbar sind und Antworten zuverlässig zurückliefern.\u003c/p\u003e\n\u003cp\u003eFür Multi-Cloud \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n entsteht damit eine zusätzliche Abstraktionsebene. Die Edge Cloud kann den öffentlichen Dienst unabhängig davon adressieren, wo der jeweilige Cluster betrieben wird. Ein Wechsel des Compute-Providers muss dann nicht automatisch eine Änderung des öffentlichen Endpunkts oder der gesamten DNS- und Security-Architektur auslösen. Das reduziert Migrationsrisiken, ersetzt aber keine sorgfältige Netzwerkplanung.\u003c/p\u003e\n\u003cp\u003eZu prüfen sind insbesondere Routing, Firewall-Regeln, Quelladressierung und die Behandlung von Rückverkehr. Proxy Protocol kann relevante Verbindungsinformationen bis zum Backend transportieren, sofern die nachgelagerten Komponenten dies unterstützen. Backend Health Checks und Failover helfen, nicht erreichbare oder fehlerhafte Ziele aus dem Traffic zu nehmen. Die konkrete Umsetzung bleibt eine Integrationsaufgabe zwischen Edge-, Netzwerk- und \u003ca href=\"/kubernetes/\"\u003eKubernetes-Team\u003c/a\u003e\n.\u003c/p\u003e\n\u003ch2 id=\"3-abgrenzung-zu-ayedo-managed-kubernetes\"\u003e3. Abgrenzung zu ayedo Managed Kubernetes\u003c/h2\u003e\n\u003cp\u003eDie Nutzung der ayedo Edge Cloud ist nicht auf ayedo Managed \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n beschränkt. Managed \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n bündelt die Verantwortung für die Compute-Plattform bei ayedo. Bei einem eigenen Cluster oder einem Cluster eines anderen Providers verbleibt diese Verantwortung beim jeweiligen Unternehmen oder dessen Infrastrukturpartner.\u003c/p\u003e\n\u003cp\u003eDie Edge-Funktionen bleiben davon getrennt. Anycast-basiertes Layer-4- und Layer-7-Loadbalancing, Anycast DNS beziehungsweise Multi-Provider-DNS, TLS Termination und zentrale Schutzmechanismen können als vorgelagerte Plattform genutzt werden. Dadurch ist die Edge nicht lediglich ein Zusatzmodul innerhalb eines Managed-Cluster-Angebots, sondern eine eigenständige Infrastrukturkomponente für öffentliche Anwendungen und APIs.\u003c/p\u003e\n\u003cp\u003eFür die Entscheidung ist deshalb die Verantwortungsmatrix wichtiger als die Anbieterzuordnung. Wer betreibt das Cluster? Wer pflegt Ingress- und Service-Konfigurationen? Wer überwacht Backend-Erreichbarkeit? Wer reagiert bei Routing- oder Zertifikatsproblemen? Mit einem externen oder selbst betriebenen Cluster fallen diese Aufgaben nicht weg. Sie werden nur sauber von den Edge-Aufgaben getrennt und müssen organisatorisch verbindlich zugeordnet werden.\u003c/p\u003e\n\u003ch2 id=\"4-technische-und-wirtschaftliche-konsequenzen\"\u003e4. Technische und wirtschaftliche Konsequenzen\u003c/h2\u003e\n\u003cp\u003eProviderunabhängigkeit ist kein Selbstzweck. Sie ist dann relevant, wenn Unternehmen Compute-Entscheidungen unabhängig vom öffentlichen Zugang treffen wollen. Gründe können bestehende Rechenzentrumsinfrastruktur, regulatorische Anforderungen, eine Multi-Cloud-Strategie oder die Vermeidung starker Bindung an einen einzelnen Cloud-Provider sein.\u003c/p\u003e\n\u003cp\u003eDie Trennung kann Kosten und Betriebsaufwand reduzieren, wenn zentrale Edge-Funktionen nicht mehrfach pro Cluster aufgebaut werden müssen. Ein Unternehmen kann beispielsweise Schutz, DNS, TLS und Traffic-Verteilung an einer Stelle organisieren, statt diese Funktionen für jede [Kubernetes]-Umgebung unterschiedlich zu implementieren. Gleichzeitig entstehen Integrations- und Governance-Kosten: Netzwerkpfade müssen dokumentiert, Health Checks abgestimmt und Zuständigkeiten im Incident-Fall geklärt werden.\u003c/p\u003e\n\u003cp\u003eDie eigene Netzwerk-Infrastruktur und das eigene Autonomous System der ayedo Edge Cloud sind in diesem Zusammenhang architektonisch relevant. Zusammen mit der verteilten Multi-PoP-Architektur und dem Aktiv-Aktiv-Prinzip bilden sie die Grundlage für einen eigenständigen öffentlichen Zugang, der nicht von der Topologie eines einzelnen \u003ca href=\"/kubernetes/\"\u003eKubernetes-Providers\u003c/a\u003e\n abhängt. Das verbessert die Entkopplung, ersetzt aber keine belastbare Backend-Architektur.\u003c/p\u003e\n\u003ch2 id=\"praxis--und-betriebsszenario\"\u003ePraxis- und Betriebsszenario\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt seine Produktionscluster selbst und nutzt zusätzlich einen \u003ca href=\"/kubernetes/\"\u003eKubernetes-Cluster\u003c/a\u003e\n bei einem Cloud-Provider für saisonale Lasten. Beide Umgebungen sollen unter denselben öffentlichen Domains erreichbar sein. Statt jeden Cluster direkt zu veröffentlichen, liegt der öffentliche Zugang an der Edge. DNS, TLS, WAF und DDoS-Schutz werden zentral behandelt; die Edge verteilt den Traffic auf die jeweils vorgesehenen Backends.\u003c/p\u003e\n\u003cp\u003eFällt ein Cluster aus oder wird bewusst aus dem Betrieb genommen, können Health Checks und Failover die Weiterleitung beeinflussen. Das Plattformteam bleibt für die Cluster und Services verantwortlich. Das Edge-Team betreibt Routing und Schutzfunktionen. Im Vergleich zu zwei unabhängig konfigurierten Ingress-Stacks entsteht weniger funktionale Duplizierung, aber ein höherer Bedarf an abgestimmten Betriebsprozessen.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"kann-die-ayedo-edge-cloud-nur-ayedo-managed-kubernetes-anbinden\"\u003eKann die ayedo Edge Cloud nur ayedo Managed Kubernetes anbinden?\u003c/h3\u003e\n\u003cp\u003eNein. Die Integration ist auch mit selbst betriebenen \u003ca href=\"/kubernetes/\"\u003eKubernetes-Clustern\u003c/a\u003e\n sowie mit Clustern anderer Provider möglich. Edge und Compute werden dabei als getrennte Verantwortungsbereiche behandelt.\u003c/p\u003e\n\u003ch3 id=\"muss-der-kubernetes-cluster-öffentlich-erreichbar-sein\"\u003eMuss der \u003ca href=\"/kubernetes/\"\u003eKubernetes-Cluster\u003c/a\u003e\n öffentlich erreichbar sein?\u003c/h3\u003e\n\u003cp\u003eNicht zwingend direkt. Die Backends müssen aus Sicht der Edge erreichbar sein. Backend Cloaking kann die öffentliche Sichtbarkeit der eigentlichen Cluster-Endpunkte reduzieren.\u003c/p\u003e\n\u003ch3 id=\"eignet-sich-der-ansatz-für-multi-cloud-kubernetes\"\u003eEignet sich der Ansatz für Multi-Cloud \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n?\u003c/h3\u003e\n\u003cp\u003eJa, wenn Routing, Backend-Erreichbarkeit, Health Checks und Zuständigkeiten sauber definiert sind. Die Edge kann dabei als providerunabhängiger öffentlicher Eingang dienen.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eWer \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n selbst oder bei einem anderen Provider betreibt, muss den öffentlichen Zugang nicht an die Compute-Plattform koppeln. Die ayedo Edge Cloud ermöglicht eine getrennte Architektur für Traffic-Eingang, Schutz, Routing und Lastverteilung vor unterschiedlichen \u003ca href=\"/kubernetes/\"\u003eKubernetes-Umgebungen\u003c/a\u003e\n. Der wesentliche Gewinn liegt in der Providerunabhängigkeit und in zentralen Betriebsfunktionen. Voraussetzung sind klare Netzwerkpfade, abgestimmte Health Checks und eine belastbare Aufteilung der Verantwortlichkeiten.\u003c/p\u003e\n",
      "summary": "\nTL;DR Ein Kubernetes-Cluster muss nicht beim selben Anbieter betrieben werden wie die Edge-Infrastruktur. Die ayedo Edge Cloud trennt den öffentlichen Traffic-Eingang von der Compute-Plattform und kann dadurch mit selbst betriebenen sowie bei anderen Providern laufenden Kubernetes-Clustern eingesetzt werden. Das schafft Providerunabhängigkeit, verändert aber Anforderungen an Routing, Security und Betrieb.\nEinleitung Ein häufiger Architekturfehler besteht darin, Edge und Compute als untrennbare Einheit zu planen. Wird Kubernetes selbst betrieben oder bei einem anderen Provider genutzt, landet der öffentliche Traffic oft direkt am Cluster oder an einem providergebundenen Ingress. Damit werden Schutzfunktionen, TLS-Terminierung, Failover und Routing eng an die jeweilige Compute-Plattform gekoppelt. Die technische Alternative ist eine klare Trennung: Die Edge Cloud bildet den öffentlichen Eingang, während der Kubernetes-Cluster ausschließlich die Anwendungen und Services ausführt. Diese Entscheidung erweitert die Auswahl möglicher Compute-Provider, bringt aber zusätzliche Anforderungen an Backend-Erreichbarkeit, Zustandsüberwachung und Verantwortungsgrenzen mit sich.\n",
      "image": "https://ayedo.de/edge-cloud-mit-eigenen-kubernetes-clustern-nutzen.png",
      "date_published": "2026-09-02T14:11:46Z",
      "date_modified": "2026-09-02T14:11:46Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["kubernetes","security","cloud-native","cloud","operations"],
      "language": "de"
    },{
      "id": "https://ayedo.de/posts/ingress-und-api-server-mit-einem-zentralen-edge-einstieg/",
      "url": "https://ayedo.de/posts/ingress-und-api-server-mit-einem-zentralen-edge-einstieg/",
      "title": "Ingress und API Server mit einem zentralen Edge-Einstieg",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/ingress-und-api-server-mit-einem-zentralen-edge-einstieg/ingress-und-api-server-mit-einem-zentralen-edge-einstieg.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eEin zentraler Edge-Einstieg kann öffentliche \u003ca href=\"/kubernetes/\"\u003eKubernetes-Endpunkte\u003c/a\u003e\n wie Ingress-Services und API Server unter einer gemeinsamen Architektur zusammenführen. Entscheidend sind eine klare Trennung der Routingregeln, getrennte Sicherheitsanforderungen und eine kontrollierte TLS-Terminierung. Die ayedo Edge Cloud übernimmt dabei den öffentlichen Zugang, Schutz und die Verteilung, während Kubernetes die Workloads und API-Funktionen ausführt.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eIngress-Traffic und Zugriffe auf den \u003ca href=\"/kubernetes/\"\u003eKubernetes API Server\u003c/a\u003e\n haben unterschiedliche Aufgaben, werden aber in vielen Umgebungen über getrennte öffentliche Konstruktionen betrieben. Das erhöht DNS-, Zertifikats- und Betriebsaufwand und erschwert eine konsistente Kontrolle des eingehenden Traffics. Ein Kubernetes zentraler Edge-Einstieg kann diese Endpunkte an einer gemeinsamen Edge-Schicht bündeln, ohne sie logisch gleichzusetzen. Die zentrale Architekturentscheidung lautet daher nicht „ein Endpoint für alles“, sondern: Welche Funktionen werden an der Edge terminiert, wie werden sie geroutet und welche Verbindungen bleiben bis zum Backend geschützt? Genau diese Trennung bestimmt, ob die Bündelung die Plattform vereinfacht oder einen gemeinsamen Ausfall- und Sicherheitsbereich erzeugt.\u003c/p\u003e\n\u003ch2 id=\"1-gemeinsamer-einstieg-getrennte-endpunkte\"\u003e1. Gemeinsamer Einstieg, getrennte Endpunkte\u003c/h2\u003e\n\u003cp\u003eEin zentraler Edge-Einstieg beginnt mit einer sauberen logischen Trennung. Ingress-Traffic kann beispielsweise über anwendungsspezifische Hostnamen oder Pfade zu Kubernetes-Services verteilt werden. Der API Server erhält dagegen einen eindeutig abgegrenzten Hostnamen und eigene Routingregeln. Die gemeinsame öffentliche IP- beziehungsweise Anycast-Schicht ist damit nur der gemeinsame Eingang, nicht die gemeinsame Anwendungsebene.\u003c/p\u003e\n\u003cp\u003eDiese Struktur reduziert die Anzahl öffentlich verwalteter Einstiege und zentralisiert DNS, TLS und grundlegende Traffic-Steuerung. Gleichzeitig bleiben Zuständigkeiten nachvollziehbar: Regeln für \u003ccode\u003eapi.example\u003c/code\u003e dürfen nicht versehentlich auf Webanwendungen übertragen werden. Für den API Server sind insbesondere erlaubte Quellnetze, Methoden, Ports und Protokolle relevant. Ein zentraler Einstieg ist deshalb nur dann sinnvoll, wenn die Konfiguration nicht als pauschale Freigabe, sondern als Sammlung voneinander abgegrenzter Services modelliert wird.\u003c/p\u003e\n\u003ch2 id=\"2-tls-termination-mit-unterschiedlichen-anforderungen\"\u003e2. TLS Termination mit unterschiedlichen Anforderungen\u003c/h2\u003e\n\u003cp\u003eTLS Termination an der Edge kann Zertifikatsverwaltung und öffentliche Verschlüsselung vereinheitlichen. Bei Ingress-Services endet die TLS-Verbindung typischerweise an der Edge, bevor der Traffic über eine kontrollierte Verbindung zum Backend weitergeleitet wird. Für den API Server gelten jedoch strengere Anforderungen: Clients wie \u003ccode\u003ekubectl\u003c/code\u003e, Operatoren oder Automatisierungsplattformen müssen die Identität des API-Endpunkts korrekt validieren, und die Authentifizierung darf nicht durch die Edge ersetzt werden.\u003c/p\u003e\n\u003cp\u003eDie Edge ist für den Transport- und Zugangspfad verantwortlich, nicht für Kubernetes-RBAC oder die Identität des API-Clients. Je nach Sicherheitsmodell kann TLS zum Backend erneut aufgebaut oder die Verbindung bis zum API Server durchgereicht werden. Entscheidend ist, Zertifikatsketten, Client-Authentifizierung und Protokollverhalten vorab zu prüfen. Die ayedo Edge Cloud unterstützt TLS Termination an der Edge und kann öffentliche Endpunkte zentral verarbeiten; die konkrete Terminierungsstrategie muss an die Anforderungen des jeweiligen API-Zugriffs angepasst werden.\u003c/p\u003e\n\u003ch2 id=\"3-routing-health-checks-und-backend-cloaking\"\u003e3. Routing, Health Checks und Backend-Cloaking\u003c/h2\u003e\n\u003cp\u003eIngress Routing und API-Server-Zugriffe profitieren von einer gemeinsamen Verteilungs- und Überwachungsschicht, benötigen aber unterschiedliche Health-Check-Modelle. Bei Anwendungen lässt sich häufig ein definierter HTTP-Endpunkt prüfen. Beim API Server muss ein Check dagegen den tatsächlichen Erreichbarkeits- und Betriebszustand des Kontrollpfads abbilden, ohne unnötige administrative Funktionen offenzulegen.\u003c/p\u003e\n\u003cp\u003eAnycast-basiertes Layer-4- und Layer-7-Loadbalancing kann beide Endpunkttypen über die Edge verteilen. Backend Health Checks und Failover verhindern, dass Traffic dauerhaft an nicht erreichbare Ziele geleitet wird. Backend Cloaking sorgt zusätzlich dafür, dass interne Backend-Adressen nicht als öffentliche Zielstruktur sichtbar werden. Das ist besonders relevant, wenn \u003ca href=\"/kubernetes/\"\u003eKubernetes-Cluster\u003c/a\u003e\n bei unterschiedlichen Providern oder in eigener Infrastruktur betrieben werden. Die Edge Cloud bleibt der öffentliche Eingang, während die tatsächliche Topologie der Control Plane und der Workloads verborgen und unabhängig vom Provider organisiert werden kann.\u003c/p\u003e\n\u003ch2 id=\"4-sicherheits--und-betriebsgrenzen-der-bündelung\"\u003e4. Sicherheits- und Betriebsgrenzen der Bündelung\u003c/h2\u003e\n\u003cp\u003eDie gemeinsame Edge-Schicht schafft zentrale Kontrollmöglichkeiten, erhöht aber auch die Bedeutung der dort definierten Grenzen. DDoS Protection, Web Application Firewall und Traffic-Steuerung können den öffentlichen Eingang absichern. Diese Funktionen schützen jedoch nicht automatisch vor missbräuchlichen Kubernetes-Berechtigungen oder kompromittierten Zugangsdaten. API-Zugriffe benötigen weiterhin eine geeignete Authentifizierung, Autorisierung und gegebenenfalls zusätzliche Netzwerkrestriktionen.\u003c/p\u003e\n\u003cp\u003eBetrieblich entsteht ein einheitlicher Ort für DNS, Zertifikate, Routing und Traffic-Statistiken. Das kann Zuständigkeiten und Fehlersuche vereinfachen. Gleichzeitig müssen Änderungen an API- und Ingress-Regeln getrennt getestet, versioniert und überwacht werden. Eine Aktiv-Aktiv-Architektur und die verteilte Multi-PoP-Struktur der ayedo Edge Cloud unterstützen den gemeinsamen Einstieg als hochverfügbare Edge-Funktion. Sie ersetzen aber keine redundante Auslegung der Kubernetes-Control-Plane oder der Anwendungen dahinter.\u003c/p\u003e\n\u003ch2 id=\"praxis--und-betriebsszenario\"\u003ePraxis- und Betriebsszenario\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt mehrere Kubernetes-Cluster bei unterschiedlichen Providern. Öffentliche Anwendungen werden über Ingress bereitgestellt; administrative Zugriffe auf die API Server sollen nicht über individuelle Loadbalancer je Cluster veröffentlicht werden. Stattdessen erhält jeder Cluster einen getrennten API-Hostnamen, während Anwendungsdomains über eigene Ingress-Regeln geroutet werden. Die ayedo Edge Cloud übernimmt Anycast DNS, TLS Termination, DDoS Protection und die Weiterleitung zu den jeweiligen Backends.\u003c/p\u003e\n\u003cp\u003eFällt ein API-Backend aus, greift ein passender Health Check und der Traffic wird nicht weiter an dieses Ziel verteilt. Die Anwendungsrouten bleiben davon logisch getrennt. Für den Betrieb bedeutet das: weniger öffentliche Einstiegspunkte, aber weiterhin getrennte Freigaben, Zertifikate, Überwachungsregeln und Berechtigungsmodelle.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"ist-ein-zentraler-edge-einstieg-für-den-api-server-automatisch-sicherer\"\u003eIst ein zentraler Edge-Einstieg für den API Server automatisch sicherer?\u003c/h3\u003e\n\u003cp\u003eNein. Er zentralisiert Schutz- und Steuerungsfunktionen, ersetzt aber weder Kubernetes-Authentifizierung noch RBAC. Die API-Route muss separat eingeschränkt, überwacht und betrieben werden.\u003c/p\u003e\n\u003ch3 id=\"können-api-server-und-ingress-dieselbe-tls-konfiguration-verwenden\"\u003eKönnen API Server und Ingress dieselbe TLS-Konfiguration verwenden?\u003c/h3\u003e\n\u003cp\u003eSie können an derselben Edge terminiert werden, sollten aber nicht zwingend identisch konfiguriert sein. Zertifikate, Protokollanforderungen und Zugriffsregeln müssen je Endpunkttyp bewertet werden.\u003c/p\u003e\n\u003ch3 id=\"muss-der-kubernetes-cluster-bei-ayedo-betrieben-werden\"\u003eMuss der Kubernetes-Cluster bei ayedo betrieben werden?\u003c/h3\u003e\n\u003cp\u003eNein. Die ayedo Edge Cloud kann auch mit eigenen oder bei anderen Providern betriebenen Kubernetes-Clustern eingesetzt werden.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eEin Kubernetes zentraler Edge-Einstieg ist vor allem eine Strukturierungsentscheidung: Öffentliche Zugänge werden an einer gemeinsamen Schicht gebündelt, während API Server und Ingress logisch, sicherheitstechnisch und betrieblich getrennt bleiben. So lassen sich DNS, TLS Termination, Schutz und Routing zentral organisieren, ohne die Verantwortungsgrenzen von Edge und Compute aufzulösen. Die ayedo Edge Cloud ist dafür als providerunabhängige, aktiv-aktive Edge-Plattform relevant – nicht als Ersatz für Kubernetes, sondern als kontrollierter öffentlicher Eingang davor.\u003c/p\u003e\n",
      "summary": "\nTL;DR Ein zentraler Edge-Einstieg kann öffentliche Kubernetes-Endpunkte wie Ingress-Services und API Server unter einer gemeinsamen Architektur zusammenführen. Entscheidend sind eine klare Trennung der Routingregeln, getrennte Sicherheitsanforderungen und eine kontrollierte TLS-Terminierung. Die ayedo Edge Cloud übernimmt dabei den öffentlichen Zugang, Schutz und die Verteilung, während Kubernetes die Workloads und API-Funktionen ausführt.\nEinleitung Ingress-Traffic und Zugriffe auf den Kubernetes API Server haben unterschiedliche Aufgaben, werden aber in vielen Umgebungen über getrennte öffentliche Konstruktionen betrieben. Das erhöht DNS-, Zertifikats- und Betriebsaufwand und erschwert eine konsistente Kontrolle des eingehenden Traffics. Ein Kubernetes zentraler Edge-Einstieg kann diese Endpunkte an einer gemeinsamen Edge-Schicht bündeln, ohne sie logisch gleichzusetzen. Die zentrale Architekturentscheidung lautet daher nicht „ein Endpoint für alles“, sondern: Welche Funktionen werden an der Edge terminiert, wie werden sie geroutet und welche Verbindungen bleiben bis zum Backend geschützt? Genau diese Trennung bestimmt, ob die Bündelung die Plattform vereinfacht oder einen gemeinsamen Ausfall- und Sicherheitsbereich erzeugt.\n",
      "image": "https://ayedo.de/ingress-und-api-server-mit-einem-zentralen-edge-einstieg.png",
      "date_published": "2026-09-02T14:11:46Z",
      "date_modified": "2026-09-02T14:11:46Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["kubernetes","security","cloud-native","development","digital-sovereignty"],
      "language": "de"
    },{
      "id": "https://ayedo.de/posts/kubernetes-cluster-providerubergreifend-an-der-edge-schutzen/",
      "url": "https://ayedo.de/posts/kubernetes-cluster-providerubergreifend-an-der-edge-schutzen/",
      "title": "Kubernetes-Cluster providerübergreifend an der Edge schützen",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/kubernetes-cluster-providerubergreifend-an-der-edge-schutzen/kubernetes-cluster-providerubergreifend-an-der-edge-schutzen.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eProviderübergreifendes \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n benötigt einen gemeinsamen öffentlichen Einstieg, wenn Security, Routing und Failover nicht an einzelne Cluster oder Cloud-Anbieter gebunden sein sollen. Die ayedo Edge Cloud bündelt Anycast-Routing, Web Application Firewall, DDoS-Schutz und Backend Cloaking vor eigenen sowie extern betriebenen Clustern.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eEin häufiger Architekturfehler besteht darin, jeden \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n-Cluster direkt über den jeweiligen Cloud-Loadbalancer oder eine öffentliche Ingress-Adresse bereitzustellen. Dadurch werden Schutzfunktionen, Routingregeln und Betriebsprozesse an einzelne Provider gebunden. Bei mehreren Clustern entstehen unterschiedliche Sicherheitsmodelle, wechselnde Endpunkte und zusätzliche Abhängigkeiten im Failover.\u003c/p\u003e\n\u003cp\u003eSinnvoller ist ein zentraler öffentlicher Einstieg vor den Clustern. Dort werden eingehende Verbindungen geprüft, terminiert und verteilt, während die \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n-Backends ihre Providerunabhängigkeit behalten. Entscheidend ist dabei die Trennung von Edge und Compute: Die Edge schützt und routet den öffentlichen Traffic; die Cluster führen Anwendungen und APIs aus.\u003c/p\u003e\n\u003ch2 id=\"1-ein-gemeinsamer-einstieg-für-verteilte-cluster\"\u003e1. Ein gemeinsamer Einstieg für verteilte Cluster\u003c/h2\u003e\n\u003cp\u003eEin providerübergreifender \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n-Betrieb kann mehrere technische Realitäten umfassen: ein eigener Cluster im Rechenzentrum, ein Cluster bei einem Public-Cloud-Provider und weitere Umgebungen bei spezialisierten Infrastruktur-Anbietern. Ohne gemeinsame Edge liegen DNS, TLS, DDoS-Schutz und Traffic-Verteilung häufig an unterschiedlichen Stellen.\u003c/p\u003e\n\u003cp\u003eEin zentraler Einstieg standardisiert diese Funktionen. Anycast-basierter Layer-4- und Layer-7-Traffic wird an die Edge geführt, dort verarbeitet und anschließend an geeignete Backends verteilt. Für HTTP- und HTTPS-Services kann die Web Application Firewall Anforderungen prüfen, während TLS an der Edge terminiert wird. Nicht jede Anwendung muss dabei denselben Cluster verwenden.\u003c/p\u003e\n\u003cp\u003eDie ayedo Edge Cloud kann \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n-Cluster unabhängig davon anbinden, ob sie mit ayedo Managed \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n oder bei einem anderen Provider betrieben werden. Damit wird \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n nicht zum Bindeglied zwischen den Providern. Die gemeinsame Ebene liegt davor: im öffentlichen Routing- und Schutzpfad.\u003c/p\u003e\n\u003ch2 id=\"2-backend-cloaking-reduziert-die-öffentliche-angriffsfläche\"\u003e2. Backend Cloaking reduziert die öffentliche Angriffsfläche\u003c/h2\u003e\n\u003cp\u003eEin \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n-Ingress ist ein technischer Einstieg in den Cluster, aber nicht automatisch eine geeignete Sicherheitsgrenze. Wird seine öffentliche Adresse direkt veröffentlicht, sind Clusterstandort, Provider und teilweise auch Infrastrukturwechsel leichter erkennbar. Außerdem müssen Schutzmechanismen an jedem einzelnen Eingang konsistent umgesetzt werden.\u003c/p\u003e\n\u003cp\u003eBackend Cloaking verändert diese Sichtbarkeit. Clients kommunizieren mit dem Edge-Endpunkt, nicht mit der öffentlich beworbenen Adresse des eigentlichen Backends. Die Edge Cloud übernimmt die Annahme des Traffics und leitet zulässige Verbindungen an die konfigurierten \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n-Backends weiter. Das verbirgt die Backend-Struktur aus Sicht des öffentlichen Clients und erschwert direkte Zugriffe auf die Cluster-Eingänge.\u003c/p\u003e\n\u003cp\u003eCloaking ersetzt keine Netzsegmentierung und keine Absicherung der Backends. Es verhindert insbesondere nicht, dass ein bereits kompromittierter Zugang missbraucht wird. Sein Wert liegt in der Reduktion unnötiger Sichtbarkeit und darin, dass WAF, DDoS-Schutz und Routing vor dem Cluster an einer gemeinsamen Stelle greifen.\u003c/p\u003e\n\u003ch2 id=\"3-security-regeln-gehören-an-die-öffentliche-grenze\"\u003e3. Security-Regeln gehören an die öffentliche Grenze\u003c/h2\u003e\n\u003cp\u003eProviderübergreifendes \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n wird operativ schwierig, wenn jeder Cluster eigene Regeln für Webschutz, TLS und Traffic-Filterung erhält. Unterschiede zwischen Cloud-Loadbalancern, Ingress-Konfigurationen und Sicherheitsdiensten führen zu abweichendem Verhalten. Änderungen müssen mehrfach ausgerollt und im Fehlerfall an mehreren Stellen analysiert werden.\u003c/p\u003e\n\u003cp\u003eEine zentrale Web Application Firewall vor den Clustern schafft ein einheitliches Prüfmodell für HTTP- und HTTPS-Services. DDoS-Schutz und Scrubbing an der Edge setzen zusätzlich vor der Compute-Infrastruktur an. Dadurch erreicht auffälliger oder volumetrischer Traffic nicht unmittelbar die Ressourcen der \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n-Umgebungen.\u003c/p\u003e\n\u003cp\u003eDie Edge ist dabei keine vollständige Ersatzinstanz für Cluster-Security. Authentisierung, Autorisierung, Pod-Sicherheit und Netzwerkregeln bleiben Aufgaben der Anwendung und der Compute-Plattform. Der Vorteil entsteht durch klare Verantwortungsgrenzen: Die Edge schützt den öffentlichen Eingang, \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n schützt und betreibt die Workloads.\u003c/p\u003e\n\u003ch2 id=\"4-routing-und-failover-ohne-providerbindung\"\u003e4. Routing und Failover ohne Providerbindung\u003c/h2\u003e\n\u003cp\u003eEine zentrale Schutzarchitektur ist erst dann belastbar, wenn sie auch den Ausfall eines Clusters oder Providers abbilden kann. Dafür müssen Backends nicht nur erreichbar, sondern auf Anwendungsebene überprüfbar sein. Health Checks erkennen, ob ein Ziel grundsätzlich antwortet und für Traffic geeignet ist. Bei einem Fehler kann die Edge den Traffic auf ein anderes Backend oder einen anderen Cluster verteilen.\u003c/p\u003e\n\u003cp\u003eAnycast und Aktiv-Aktiv-Architektur unterstützen dabei einen verteilten Einstieg, ohne dass ein einzelner Standort den gesamten öffentlichen Traffic tragen muss. Das eigene Autonomous System und die eigene Netzwerk-Infrastruktur der ayedo Edge Cloud bilden den netzseitigen Rahmen für diese providerunabhängige Anbindung. Multi-Provider-DNS kann ergänzend eingesetzt werden, ersetzt aber nicht die Routing- und Schutzlogik der Edge.\u003c/p\u003e\n\u003cp\u003eWichtig bleibt die Anwendungsarchitektur: Datenbanken, Sessions und Zustandsabhängigkeiten können Failover begrenzen. Ein erreichbarer zweiter Cluster ist daher noch kein automatisches Disaster-Recovery-Konzept.\u003c/p\u003e\n\u003ch2 id=\"szenario-ein-service-zwei-kubernetes-umgebungen\"\u003eSzenario: Ein Service, zwei \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n-Umgebungen\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt eine API in einem eigenen \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n-Cluster und hält einen zweiten Cluster bei einem externen Provider bereit. Beide Cluster verfügen über eigene Ingress-Einstiege, sollen aber unter derselben öffentlichen Adresse erreichbar sein.\u003c/p\u003e\n\u003cp\u003eStatt beide Adressen per DNS zu veröffentlichen, zeigt der öffentliche DNS-Eintrag auf die Edge. Dort werden TLS und WAF-Prüfung durchgeführt. Die Edge leitet den zulässigen Traffic an die Backends beider Cluster weiter und führt Health Checks aus. Fällt das primäre Backend aus, kann der Traffic zum zweiten Cluster gelangen. Die Clusteradressen bleiben dabei aus der öffentlichen Kommunikation herausgehalten.\u003c/p\u003e\n\u003cp\u003eDer Betriebsaufwand verschiebt sich damit von mehreren providerabhängigen Eingängen zu einem gemeinsamen Edge-Modell. Die Unterschiede zwischen den \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n-Umgebungen bleiben im Compute-Bereich beherrschbar.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"muss-kubernetes-bei-ayedo-betrieben-werden\"\u003eMuss \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n bei ayedo betrieben werden?\u003c/h3\u003e\n\u003cp\u003eNein. Die Edge Cloud kann auch eigene \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n-Cluster sowie Cluster bei anderen Providern an den gemeinsamen öffentlichen Schutz- und Routing-Einstieg anbinden.\u003c/p\u003e\n\u003ch3 id=\"ersetzt-backend-cloaking-die-absicherung-des-clusters\"\u003eErsetzt Backend Cloaking die Absicherung des Clusters?\u003c/h3\u003e\n\u003cp\u003eNein. Es reduziert die öffentliche Sichtbarkeit der Backends. Netzwerkzugriffe, Identitäten, Workload-Sicherheit und Berechtigungen müssen weiterhin im Cluster und in der Anwendung abgesichert werden.\u003c/p\u003e\n\u003ch3 id=\"ist-die-edge-nur-für-http-services-relevant\"\u003eIst die Edge nur für HTTP-Services relevant?\u003c/h3\u003e\n\u003cp\u003eNein. Die ayedo Edge Cloud unterstützt Anycast-basiertes Layer-4- und Layer-7-Loadbalancing. WAF und TLS-Termination beziehen sich dabei auf HTTP- beziehungsweise HTTPS-Services.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eProviderunabhängiges \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n braucht eine Architektur, die öffentliche Erreichbarkeit von der Ausführung der Workloads trennt. Ein gemeinsamer Edge-Einstieg bündelt Routing, WAF, DDoS-Schutz, TLS und Backend Cloaking vor Clustern verschiedener Betreiber. Die ayedo Edge Cloud ist in diesem Modell eine eigenständige Schutz- und Routingplattform – nicht lediglich ein vorgeschalteter Loadbalancer für ayedo Managed \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n.\u003c/p\u003e\n",
      "summary": "\nTL;DR Providerübergreifendes Kubernetes benötigt einen gemeinsamen öffentlichen Einstieg, wenn Security, Routing und Failover nicht an einzelne Cluster oder Cloud-Anbieter gebunden sein sollen. Die ayedo Edge Cloud bündelt Anycast-Routing, Web Application Firewall, DDoS-Schutz und Backend Cloaking vor eigenen sowie extern betriebenen Clustern.\nEinleitung Ein häufiger Architekturfehler besteht darin, jeden Kubernetes -Cluster direkt über den jeweiligen Cloud-Loadbalancer oder eine öffentliche Ingress-Adresse bereitzustellen. Dadurch werden Schutzfunktionen, Routingregeln und Betriebsprozesse an einzelne Provider gebunden. Bei mehreren Clustern entstehen unterschiedliche Sicherheitsmodelle, wechselnde Endpunkte und zusätzliche Abhängigkeiten im Failover.\n",
      "image": "https://ayedo.de/kubernetes-cluster-providerubergreifend-an-der-edge-schutzen.png",
      "date_published": "2026-09-02T14:11:46Z",
      "date_modified": "2026-09-02T14:11:46Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["kubernetes","security","cloud-native","development","operations"],
      "language": "de"
    },{
      "id": "https://ayedo.de/posts/kubernetes-dns-und-zertifikate-sauber-entkoppeln/",
      "url": "https://ayedo.de/posts/kubernetes-dns-und-zertifikate-sauber-entkoppeln/",
      "title": "Kubernetes-DNS und Zertifikate sauber entkoppeln",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/kubernetes-dns-und-zertifikate-sauber-entkoppeln/kubernetes-dns-und-zertifikate-sauber-entkoppeln.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eKubernetes-DNS, ACME-DNS-01 und TLS-Terminierung lösen unterschiedliche Probleme. Werden sie als eine einzige Funktion betrachtet, entstehen unklare Zuständigkeiten, fehlerhafte Automatisierung und unnötige Ausfallrisiken. Eine Edge-Plattform wie die ayedo Edge Cloud kann DNS-Veröffentlichung, ACME-Validierung und TLS-Terminierung verbinden, ohne diese Verantwortlichkeiten technisch zu vermischen.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eEin DNS-Record beweist nicht, dass ein TLS-Zertifikat korrekt ausgestellt wurde – und ein gültiges Zertifikat veröffentlicht noch keinen Service. In Kubernetes werden diese Zusammenhänge jedoch häufig in einer gemeinsamen Automatisierung verborgen. Das wirkt zunächst effizient, erschwert aber die Fehlersuche: Ein nicht erreichbarer Service kann auf einen falschen DNS-Record, eine fehlgeschlagene ACME-DNS-01-Challenge, einen fehlerhaften Ingress oder eine nicht passende TLS-Terminierung zurückgehen. Die zentrale Architekturentscheidung lautet deshalb: DNS-Veröffentlichung, Zertifikatsvalidierung und TLS-Verarbeitung müssen getrennte Verantwortlichkeiten bleiben, auch wenn sie über denselben Workflow orchestriert werden.\u003c/p\u003e\n\u003ch2 id=\"1-drei-funktionen-drei-technische-verantwortlichkeiten\"\u003e1. Drei Funktionen, drei technische Verantwortlichkeiten\u003c/h2\u003e\n\u003cp\u003eKubernetes-DNS beschreibt zunächst die Auflösung eines Namens zu einer Adresse oder einem Ziel. Für einen öffentlichen Service kann das ein A- oder AAAA-Record, ein CNAME oder eine delegierte Zone sein. Diese Information sagt jedoch nichts darüber aus, ob der dahinterliegende Dienst erreichbar ist, ob der Hostname für ein Zertifikat validiert wurde oder wo TLS beendet wird.\u003c/p\u003e\n\u003cp\u003eDie ACME-DNS-01-Challenge verfolgt ein anderes Ziel. Die Zertifizierungsstelle verlangt einen TXT-Record unter \u003ccode\u003e_acme-challenge.\u0026lt;domain\u0026gt;\u003c/code\u003e. Erst wenn dieser Record öffentlich korrekt auflösbar ist, kann die Kontrolle über die Domain nachgewiesen werden. Der eigentliche Anwendungsverkehr wird dabei nicht geprüft.\u003c/p\u003e\n\u003cp\u003eTLS-Terminierung ist wiederum eine Laufzeitfunktion. Sie bestimmt, wo der Client-Handshake stattfindet, welches Zertifikat ausgeliefert wird und ob die Verbindung zum Backend erneut verschlüsselt wird. In der ayedo Edge Cloud kann TLS an der Edge terminiert werden, während das Backend über einen getrennten technischen Pfad erreicht wird. Diese Trennung verhindert, dass ein DNS-Fehler fälschlich als Zertifikatsproblem behandelt wird.\u003c/p\u003e\n\u003ch2 id=\"2-dns-records-und-acme-dns-01-getrennt-betreiben\"\u003e2. DNS-Records und ACME-DNS-01 getrennt betreiben\u003c/h2\u003e\n\u003cp\u003eFür den normalen Servicezugriff und für die Zertifikatsvalidierung gelten unterschiedliche Änderungs- und Sicherheitsanforderungen. Ein öffentlicher Record wie \u003ccode\u003eapi.example.com\u003c/code\u003e verweist auf den vorgesehenen Eingangspunkt. Der TXT-Record für ACME-DNS-01 ist dagegen temporär und darf nur für die Dauer der Validierung existieren. Beide Record-Typen gehören zwar in dieselbe DNS-Welt, haben aber verschiedene Lebenszyklen und Berechtigungsprofile.\u003c/p\u003e\n\u003cp\u003eEine robuste DNS-Automatisierung behandelt sie deshalb als getrennte Objekte. Der Prozess für Zertifikatsausstellung oder -erneuerung benötigt Schreibrechte auf den relevanten \u003ccode\u003e_acme-challenge\u003c/code\u003e-Pfad, nicht automatisch auf alle produktiven Records. Das reduziert den Blast Radius eines kompromittierten Controllers und verhindert, dass eine Zertifikatsautomatisierung versehentlich Serviceziele verändert.\u003c/p\u003e\n\u003cp\u003eDie ayedo Edge Cloud stellt Anycast DNS und Multi-Provider-DNS als Edge-Funktionen bereit. In einer entsprechenden Architektur können öffentliche Service-Records und ACME-Challenge-Records über dieselbe Edge-DNS-Plattform verwaltet werden. Das ändert nichts an der notwendigen Trennung von Record-Zweck, Berechtigung, TTL-Strategie und Monitoring.\u003c/p\u003e\n\u003ch2 id=\"3-zertifikatsausstellung-ist-nicht-tls-terminierung\"\u003e3. Zertifikatsausstellung ist nicht TLS-Terminierung\u003c/h2\u003e\n\u003cp\u003eEin häufiges Missverständnis besteht darin, die erfolgreiche ACME-DNS-01-Validierung mit einem funktionierenden HTTPS-Service gleichzusetzen. Die Validierung bestätigt lediglich die Domainkontrolle. Danach muss das ausgestellte Zertifikat noch an der Stelle verfügbar sein, an der TLS terminiert. Zusätzlich müssen Hostname, Zertifikatskette, Ablaufdatum und Routing zusammenpassen.\u003c/p\u003e\n\u003cp\u003eBei einer Terminierung an der Edge ist der öffentliche Clientverkehr von der Verbindung zwischen Edge und Backend getrennt. Das ermöglicht Backend Cloaking: Das eigentliche Backend muss nicht als öffentliches Ziel im DNS erscheinen. DNS verweist stattdessen auf den Edge-Eingang, während die Edge anhand von Hostname, Protokoll und Routing zum geeigneten Backend weiterleitet.\u003c/p\u003e\n\u003cp\u003eDie ayedo Edge Cloud kombiniert dafür öffentliche DNS-Funktionen mit TLS Termination, Layer-4- und Layer-7-Loadbalancing sowie Backend Health Checks. Diese Funktionen bilden eine zusammenhängende Plattform, bleiben aber logisch unterscheidbar. Kubernetes muss daher nicht zwingend selbst öffentliches TLS terminieren. Das gilt auch für eigene oder bei anderen Providern betriebene Kubernetes-Cluster.\u003c/p\u003e\n\u003ch2 id=\"4-vermischte-zuständigkeiten-erzeugen-betriebsrisiken\"\u003e4. Vermischte Zuständigkeiten erzeugen Betriebsrisiken\u003c/h2\u003e\n\u003cp\u003eWer DNS, Zertifikatsvalidierung und TLS-Terminierung in einem undurchsichtigen Kubernetes-Workflow bündelt, verliert wichtige Diagnosegrenzen. Ein abgelaufener TXT-Record kann die Erneuerung blockieren, obwohl der Service weiterhin erreichbar ist. Ein falscher A-Record kann den Service ausfallen lassen, obwohl das Zertifikat gültig ist. Ein korrektes Zertifikat kann wiederum an der falschen Edge-Konfiguration oder am Backend-Routing scheitern.\u003c/p\u003e\n\u003cp\u003eAuch organisatorisch entstehen Risiken. DNS-Administration, Plattformbetrieb und Security benötigen nicht zwangsläufig identische Rechte. Eine getrennte Verantwortungszuordnung erlaubt es, Änderungen nachvollziehbar zu prüfen und gezielt zu automatisieren. Sinnvoll sind außerdem getrennte Prüfungen für DNS-Auflösung, ACME-Record-Präsenz, Zertifikatsgültigkeit, TLS-Handshake und Backend-Health.\u003c/p\u003e\n\u003cp\u003eWirtschaftlich reduziert diese Struktur vor allem die Zeit zur Störungsanalyse. Sie verhindert nicht jede Fehlkonfiguration, macht deren Ursache aber lokalisierbar. Gerade bei providerunabhängigen Kubernetes-Architekturen ist das relevant: Die Edge bleibt der kontrollierte öffentliche Eingang, während der Cluster als Compute-Verantwortungsbereich unabhängig betrieben werden kann.\u003c/p\u003e\n\u003ch2 id=\"praxisszenario-ein-neuer-kubernetes-service\"\u003ePraxisszenario: Ein neuer Kubernetes-Service\u003c/h2\u003e\n\u003cp\u003eEin Team veröffentlicht \u003ccode\u003epayments.example.com\u003c/code\u003e aus einem Kubernetes-Cluster bei einem externen Provider. Der öffentliche DNS-Record zeigt auf die ayedo Edge Cloud. Für die erstmalige Zertifikatsausstellung legt die Zertifikatsautomatisierung einen temporären TXT-Record unter \u003ccode\u003e_acme-challenge.payments.example.com\u003c/code\u003e an. Nach erfolgreicher Validierung wird das Zertifikat an der Edge hinterlegt und dort für die TLS-Terminierung verwendet.\u003c/p\u003e\n\u003cp\u003eDer Kubernetes-Service bleibt intern adressierbar und muss nicht direkt im öffentlichen DNS erscheinen. Fällt später die Zertifikatserneuerung aus, bleibt der bestehende Servicepfad zunächst von der DNS-Veröffentlichung getrennt beobachtbar. Das Betriebsteam kann daher unterscheiden, ob die Störung bei DNS, ACME, TLS oder beim Backend liegt, statt den gesamten Veröffentlichungsprozess als eine einzige Fehlerquelle zu behandeln.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"muss-der-kubernetes-cluster-dns-selbst-verwalten\"\u003eMuss der Kubernetes-Cluster DNS selbst verwalten?\u003c/h3\u003e\n\u003cp\u003eNein. Kubernetes kann Services intern auflösen, während öffentliche DNS-Records durch eine externe DNS-Plattform oder die ayedo Edge Cloud verwaltet werden.\u003c/p\u003e\n\u003ch3 id=\"benötigt-acme-dns-01-einen-öffentlich-erreichbaren-webserver\"\u003eBenötigt ACME DNS-01 einen öffentlich erreichbaren Webserver?\u003c/h3\u003e\n\u003cp\u003eNein. Die Zertifizierungsstelle prüft den autorisierten TXT-Record. Deshalb eignet sich DNS-01 auch für Backends, die nicht direkt aus dem Internet erreichbar sind.\u003c/p\u003e\n\u003ch3 id=\"wo-sollte-tls-terminiert-werden\"\u003eWo sollte TLS terminiert werden?\u003c/h3\u003e\n\u003cp\u003eDas hängt von Routing, Security und Betriebsmodell ab. Eine Terminierung an der Edge zentralisiert den öffentlichen TLS-Eingang; das Backend kann anschließend separat geschützt und überwacht werden.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eKubernetes-DNS, ACME-DNS-01 und TLS-Terminierung gehören in denselben Veröffentlichungsprozess, aber nicht in dieselbe Verantwortlichkeit. Wer Records, Validierung und Laufzeit-TLS sauber trennt, erhält klarere Berechtigungen, bessere Diagnosemöglichkeiten und weniger Abhängigkeiten zwischen Cluster und öffentlichem Eingang. Die ayedo Edge Cloud unterstützt dieses Modell als providerunabhängige Edge-Plattform für DNS, Zertifikatsnahe Validierungspfade und TLS-Terminierung – auch vor Kubernetes-Clustern außerhalb von ayedo Managed Kubernetes.\u003c/p\u003e\n",
      "summary": "\nTL;DR Kubernetes-DNS, ACME-DNS-01 und TLS-Terminierung lösen unterschiedliche Probleme. Werden sie als eine einzige Funktion betrachtet, entstehen unklare Zuständigkeiten, fehlerhafte Automatisierung und unnötige Ausfallrisiken. Eine Edge-Plattform wie die ayedo Edge Cloud kann DNS-Veröffentlichung, ACME-Validierung und TLS-Terminierung verbinden, ohne diese Verantwortlichkeiten technisch zu vermischen.\nEinleitung Ein DNS-Record beweist nicht, dass ein TLS-Zertifikat korrekt ausgestellt wurde – und ein gültiges Zertifikat veröffentlicht noch keinen Service. In Kubernetes werden diese Zusammenhänge jedoch häufig in einer gemeinsamen Automatisierung verborgen. Das wirkt zunächst effizient, erschwert aber die Fehlersuche: Ein nicht erreichbarer Service kann auf einen falschen DNS-Record, eine fehlgeschlagene ACME-DNS-01-Challenge, einen fehlerhaften Ingress oder eine nicht passende TLS-Terminierung zurückgehen. Die zentrale Architekturentscheidung lautet deshalb: DNS-Veröffentlichung, Zertifikatsvalidierung und TLS-Verarbeitung müssen getrennte Verantwortlichkeiten bleiben, auch wenn sie über denselben Workflow orchestriert werden.\n",
      "image": "https://ayedo.de/kubernetes-dns-und-zertifikate-sauber-entkoppeln.png",
      "date_published": "2026-09-02T14:11:46Z",
      "date_modified": "2026-09-02T14:11:46Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["kubernetes","automation","cloud-native","digital-sovereignty","software-delivery"],
      "language": "de"
    },{
      "id": "https://ayedo.de/posts/acme-dns-challenges-mit-kubernetes-automatisieren/",
      "url": "https://ayedo.de/posts/acme-dns-challenges-mit-kubernetes-automatisieren/",
      "title": "ACME-DNS-Challenges mit Kubernetes automatisieren",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/acme-dns-challenges-mit-kubernetes-automatisieren/acme-dns-challenges-mit-kubernetes-automatisieren.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eDie DNS-01-Challenge automatisiert die Ausstellung und Erneuerung von TLS-Zertifikaten, ohne dass ein Service über HTTP erreichbar sein muss. In \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n übernimmt ein Zertifikatscontroller den Lebenszyklus. Eine Edge-Plattform wie die ayedo Edge Cloud stellt dafür DNS, öffentliche Erreichbarkeit und optional die TLS-Terminierung getrennt vom Cluster bereit.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eTLS-Zertifikate manuell zu beantragen und zu erneuern, ist in \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n keine belastbare Betriebsstrategie. Zertifikate laufen ab, Zuständigkeiten verteilen sich über mehrere Teams, und bei dynamischen Deployments entstehen leicht Inkonsistenzen zwischen DNS, Ingress und Secret-Management. Die DNS-01-Challenge verschiebt die Validierung auf eine kontrollierte DNS-Änderung: Der ACME-Client veröffentlicht einen TXT-Record, der die Kontrolle über eine Domain nachweist. Dadurch lassen sich auch Wildcard-Zertifikate und Services validieren, die nicht öffentlich per HTTP erreichbar sind. Die eigentliche Herausforderung liegt nicht im ACME-Protokoll, sondern in einer sicheren und nachvollziehbaren Automatisierung über DNS und \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n hinweg.\u003c/p\u003e\n\u003ch2 id=\"1-dns-01-statt-http-01-was-sich-architektonisch-ändert\"\u003e1. DNS-01 statt HTTP-01: Was sich architektonisch ändert\u003c/h2\u003e\n\u003cp\u003eBei einer HTTP-01-Challenge muss die Zertifizierungsstelle einen definierten Pfad über Port 80 erreichen. Das setzt eine funktionierende öffentliche Route bis zum zuständigen Ingress voraus. Die DNS-01-Challenge verwendet dagegen einen TXT-Record unterhalb von \u003ccode\u003e_acme-challenge.\u0026lt;domain\u0026gt;\u003c/code\u003e. Der ACME-Client erzeugt einen Token, veröffentlicht ihn im DNS und wartet, bis die Änderung für die Validierung sichtbar ist.\u003c/p\u003e\n\u003cp\u003eDamit wird die Zertifikatsausstellung vom HTTP-Datenpfad entkoppelt. Ein Cluster kann hinter einem Loadbalancer, einem privaten Netzwerk oder einer zusätzlichen Schutzschicht liegen. Auch Wildcard-Zertifikate wie \u003ccode\u003e*.example.com\u003c/code\u003e lassen sich über DNS-01 validieren, was mit HTTP-01 nicht möglich ist.\u003c/p\u003e\n\u003cp\u003eDer Preis dafür ist eine höhere Verantwortung für DNS. Falsche Zonen, verzögerte Propagation oder konkurrierende TXT-Records führen zu Validierungsfehlern. DNS ist damit nicht nur Namensauflösung, sondern Bestandteil des Zertifikatsprozesses.\u003c/p\u003e\n\u003ch2 id=\"2-kubernetes-automatisiert-den-zertifikatslebenszyklus\"\u003e2. \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n automatisiert den Zertifikatslebenszyklus\u003c/h2\u003e\n\u003cp\u003eIn \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n wird die Automatisierung typischerweise durch einen Zertifikatscontroller umgesetzt. Ein deklaratives Objekt beschreibt Domainnamen, Aussteller und gewünschte Zertifikate. Der Controller erstellt daraus ACME-Orders und Challenges, legt die erforderlichen TXT-Records an und schreibt das fertige Zertifikat in ein Kubernetes Secret.\u003c/p\u003e\n\u003cp\u003eFür den Betrieb ist entscheidend, dass Ausstellung und Erneuerung denselben Prozess verwenden. Ein einmalig ausgestelltes Zertifikat reduziert den manuellen Aufwand zunächst, löst aber nicht die Ablaufproblematik. Der Controller muss frühzeitig erneuern, Fehler sichtbar machen und nach temporären DNS- oder ACME-Problemen erneut versuchen können.\u003c/p\u003e\n\u003cp\u003eDie Secrets müssen außerdem dort verfügbar sein, wo TLS terminiert wird. Bei einer Termination im \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n-Ingress liegen die Zertifikate im Cluster. Wird TLS dagegen an einer vorgeschalteten Edge beendet, gehört das Zertifikatsmanagement zur Edge-Schicht. Beide Modelle sind technisch möglich, benötigen aber klare Zuständigkeiten für Zertifikatsspeicher, Zugriffsschutz, Rotation und Monitoring.\u003c/p\u003e\n\u003ch2 id=\"3-dns-zugriff-sicher-und-providerunabhängig-gestalten\"\u003e3. DNS-Zugriff sicher und providerunabhängig gestalten\u003c/h2\u003e\n\u003cp\u003eFür DNS-01 benötigt der \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n-Controller Schreibrechte auf den relevanten DNS-Zonen. Ein globaler DNS-Administratorzugang ist dafür ungeeignet: Ein kompromittierter Controller könnte beliebige Records verändern. Besser sind dedizierte, minimal berechtigte Zugangsdaten und eine Begrenzung auf die erforderlichen Zonen oder Recordtypen.\u003c/p\u003e\n\u003cp\u003eAuch die DNS-Architektur beeinflusst die Automatisierung. Bei mehreren autoritativen Providern müssen Änderungen konsistent veröffentlicht werden. Andernfalls fragt die Zertifizierungsstelle einen Nameserver ab, auf dem der TXT-Record noch fehlt. Anycast DNS und Multi-Provider-DNS können die Verfügbarkeit der Auflösung erhöhen, ersetzen aber nicht die korrekte Synchronisation und die Überprüfung der Propagation.\u003c/p\u003e\n\u003cp\u003eDie ayedo Edge Cloud bietet Anycast DNS und Multi-Provider-DNS als Bestandteil ihrer Edge-Plattform. [Kubernetes]-Workloads können dabei in ayedo Managed \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n oder in eigenen beziehungsweise bei anderen Providern betriebenen Clustern laufen. Für das Zertifikatsdesign bleibt wichtig, ob ayedo DNS die autoritative Zone verwaltet und wie der Controller beziehungsweise ein delegierter Challenge-Mechanismus darauf zugreift.\u003c/p\u003e\n\u003ch2 id=\"4-edge-terminierung-und-cluster-terminierung-sauber-trennen\"\u003e4. Edge-Terminierung und Cluster-Terminierung sauber trennen\u003c/h2\u003e\n\u003cp\u003eDNS-01 beantwortet die Frage, wie eine Domain validiert wird. Sie legt nicht fest, wo der spätere TLS-Datenverkehr terminiert. Diese Entscheidung sollte unabhängig getroffen werden. Terminiert \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n TLS selbst, muss der Ingress das richtige Secret laden und bei Erneuerungen ohne Unterbrechung aktualisieren. Terminiert die Edge, bleiben Zertifikate und öffentliche TLS-Konfiguration außerhalb des Clusters; der Backend-Traffic kann anschließend geschützt und verteilt werden.\u003c/p\u003e\n\u003cp\u003eDie ayedo Edge Cloud übernimmt den öffentlichen Eingang vor Anwendungen und APIs, unterstützt TLS Termination an der Edge, Backend Cloaking, Health Checks und Failover. Dadurch kann ein Cluster seine interne Topologie nicht öffentlich ausweisen, während die Edge den externen Traffic verarbeitet. Die DNS-01-Automatisierung ist dabei ein Baustein des Zertifikatslebenszyklus, nicht die gesamte Edge-Funktion.\u003c/p\u003e\n\u003cp\u003eFür Plattformteams entsteht eine klare Trennung: DNS und Zertifikatsausstellung müssen automatisiert und auditierbar sein; Edge-Routing und Schutzmechanismen gehören in die öffentliche Eingangsschicht; \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n bleibt für die Workloads und – je nach Architektur – für die interne TLS-Verarbeitung verantwortlich.\u003c/p\u003e\n\u003ch2 id=\"praxis--und-betriebsszenario\"\u003ePraxis- und Betriebsszenario\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt mehrere [Kubernetes]-Cluster bei unterschiedlichen Providern und veröffentlicht Anwendungen unter einer gemeinsamen Domain. Die HTTP-01-Challenge wäre problematisch, weil nicht jeder Service öffentlich erreichbar sein soll und sich Routing während eines Failovers ändern kann.\u003c/p\u003e\n\u003cp\u003eStattdessen verwaltet ein [Kubernetes]-Zertifikatscontroller DNS-01-Challenges. Die ACME-TXT-Records werden in der autoritativen DNS-Struktur veröffentlicht. Die ayedo Edge Cloud übernimmt Anycast DNS, den öffentlichen Traffic-Eingang und optional die TLS-Terminierung. Die Backends bleiben hinter der Edge verborgen und können bei Bedarf zwischen Clustern umgeschaltet werden.\u003c/p\u003e\n\u003cp\u003eDer entscheidende Betriebsgewinn liegt nicht nur in weniger manuellen Zertifikatsänderungen. DNS-Validierung, Zertifikatserneuerung und Traffic-Routing bleiben auch dann funktionsfähig, wenn sich der konkrete [Kubernetes]-Standort oder das Backend ändert.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"ist-dns-01-für-interne-kubernetes-services-geeignet\"\u003eIst DNS-01 für interne [Kubernetes]-Services geeignet?\u003c/h3\u003e\n\u003cp\u003eJa, sofern die ACME-Zertifizierungsstelle den öffentlichen TXT-Record auflösen kann. Der Service selbst muss nicht öffentlich per HTTP erreichbar sein.\u003c/p\u003e\n\u003ch3 id=\"können-mit-dns-01-wildcard-zertifikate-ausgestellt-werden\"\u003eKönnen mit DNS-01 Wildcard-Zertifikate ausgestellt werden?\u003c/h3\u003e\n\u003cp\u003eJa. Die DNS-01-Challenge unterstützt Wildcard-Domains, weil die Kontrolle über die Domain per TXT-Record nachgewiesen wird.\u003c/p\u003e\n\u003ch3 id=\"wo-sollte-das-zertifikat-gespeichert-werden\"\u003eWo sollte das Zertifikat gespeichert werden?\u003c/h3\u003e\n\u003cp\u003eDas hängt vom Terminierungspunkt ab: im \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n Secret bei Ingress-Terminierung oder in der Edge-Schicht bei TLS Termination an der Edge.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eACME DNS Challenge in \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n ist vor allem eine Architekturentscheidung für einen automatisierbaren Zertifikatslebenszyklus. DNS-01 entkoppelt die Validierung von öffentlicher HTTP-Erreichbarkeit, verlangt dafür aber kontrollierten DNS-Zugriff, zuverlässige Propagation und klare Secret-Zuständigkeiten. In Verbindung mit der ayedo Edge Cloud lassen sich DNS, öffentlicher Eingang, TLS-Terminierung und Backend-Abschirmung getrennt vom Compute-Betrieb organisieren. Das schafft eine belastbare Grundlage für providerübergreifende [Kubernetes]-Umgebungen.\u003c/p\u003e\n",
      "summary": "\nTL;DR Die DNS-01-Challenge automatisiert die Ausstellung und Erneuerung von TLS-Zertifikaten, ohne dass ein Service über HTTP erreichbar sein muss. In Kubernetes übernimmt ein Zertifikatscontroller den Lebenszyklus. Eine Edge-Plattform wie die ayedo Edge Cloud stellt dafür DNS, öffentliche Erreichbarkeit und optional die TLS-Terminierung getrennt vom Cluster bereit.\nEinleitung TLS-Zertifikate manuell zu beantragen und zu erneuern, ist in Kubernetes keine belastbare Betriebsstrategie. Zertifikate laufen ab, Zuständigkeiten verteilen sich über mehrere Teams, und bei dynamischen Deployments entstehen leicht Inkonsistenzen zwischen DNS, Ingress und Secret-Management. Die DNS-01-Challenge verschiebt die Validierung auf eine kontrollierte DNS-Änderung: Der ACME-Client veröffentlicht einen TXT-Record, der die Kontrolle über eine Domain nachweist. Dadurch lassen sich auch Wildcard-Zertifikate und Services validieren, die nicht öffentlich per HTTP erreichbar sind. Die eigentliche Herausforderung liegt nicht im ACME-Protokoll, sondern in einer sicheren und nachvollziehbaren Automatisierung über DNS und Kubernetes hinweg.\n",
      "image": "https://ayedo.de/acme-dns-challenges-mit-kubernetes-automatisieren.png",
      "date_published": "2026-09-02T14:11:45Z",
      "date_modified": "2026-09-02T14:11:45Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["kubernetes","automation","software-delivery","cloud-native","digital-sovereignty"],
      "language": "de"
    },{
      "id": "https://ayedo.de/posts/dns-records-aus-kubernetes-ingress-automatisch-verwalten/",
      "url": "https://ayedo.de/posts/dns-records-aus-kubernetes-ingress-automatisch-verwalten/",
      "title": "DNS-Records aus Kubernetes Ingress automatisch verwalten",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/dns-records-aus-kubernetes-ingress-automatisch-verwalten/dns-records-aus-kubernetes-ingress-automatisch-verwalten.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eKubernetes-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.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eEin \u003ca href=\"https://kubernetes.io/docs/concepts/services-networking/ingress/\" target=\"_blank\" rel=\"noopener\"\u003eKubernetes-Hostname\u003c/a\u003e\n ist noch kein erreichbarer Service. Ein \u003ccode\u003eIngress\u003c/code\u003e oder ein Gateway kann zwar festlegen, dass \u003ccode\u003eapi.example.com\u003c/code\u003e 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.\u003c/p\u003e\n\u003ch2 id=\"1-kubernetes-hosts-als-deklarative-quelle\"\u003e1. Kubernetes-Hosts als deklarative Quelle\u003c/h2\u003e\n\u003cp\u003eIngress-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.\u003c/p\u003e\n\u003cp\u003eGenau 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 \u003ccode\u003espec.rules.host\u003c/code\u003e 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.\u003c/p\u003e\n\u003cp\u003eWichtig 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.\u003c/p\u003e\n\u003ch2 id=\"2-dns-veröffentlichung-ist-ein-kontrollierter-abgleich\"\u003e2. DNS-Veröffentlichung ist ein kontrollierter Abgleich\u003c/h2\u003e\n\u003cp\u003eAutomatisierte 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?\u003c/p\u003e\n\u003cp\u003eExternal-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.\u003c/p\u003e\n\u003cp\u003eDie 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.\u003c/p\u003e\n\u003ch2 id=\"3-die-edge-cloud-als-ziel-des-öffentlichen-endpunkts\"\u003e3. Die Edge Cloud als Ziel des öffentlichen Endpunkts\u003c/h2\u003e\n\u003cp\u003eDer 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.\u003c/p\u003e\n\u003cp\u003eDie 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.\u003c/p\u003e\n\u003cp\u003eDiese 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.\u003c/p\u003e\n\u003ch2 id=\"4-konsistenz-braucht-status-tests-und-betriebsregeln\"\u003e4. Konsistenz braucht Status, Tests und Betriebsregeln\u003c/h2\u003e\n\u003cp\u003eDer 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.\u003c/p\u003e\n\u003cp\u003eDeshalb 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.\u003c/p\u003e\n\u003cp\u003eFü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.\u003c/p\u003e\n\u003ch2 id=\"praxis--und-betriebsszenario\"\u003ePraxis- und Betriebsszenario\u003c/h2\u003e\n\u003cp\u003eEin Team veröffentlicht \u003ccode\u003epayments.example.com\u003c/code\u003e über ein Gateway im eigenen \u003ca href=\"/kubernetes/\"\u003eKubernetes-Cluster\u003c/a\u003e\n. 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.\u003c/p\u003e\n\u003cp\u003eWird 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.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"ist-external-dns-selbst-ein-dns-server\"\u003eIst External-DNS selbst ein DNS-Server?\u003c/h3\u003e\n\u003cp\u003eNein. 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.\u003c/p\u003e\n\u003ch3 id=\"können-gateway-api-ressourcen-statt-ingress-verwendet-werden\"\u003eKönnen Gateway-API-Ressourcen statt Ingress verwendet werden?\u003c/h3\u003e\n\u003cp\u003eJa, 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.\u003c/p\u003e\n\u003ch3 id=\"muss-der-dns-record-direkt-auf-den-kubernetes-cluster-zeigen\"\u003eMuss der DNS-Record direkt auf den Kubernetes-Cluster zeigen?\u003c/h3\u003e\n\u003cp\u003eNein. 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.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eKubernetes 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.\u003c/p\u003e\n",
      "summary": "\nTL;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.\nEinleitung 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.\n",
      "image": "https://ayedo.de/dns-records-aus-kubernetes-ingress-automatisch-verwalten.png",
      "date_published": "2026-09-02T14:11:45Z",
      "date_modified": "2026-09-02T14:11:45Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["kubernetes","operations","development","cloud-native","digital-sovereignty"],
      "language": "de"
    },{
      "id": "https://ayedo.de/posts/gateway-api-und-edge-routing-in-kubernetes-verbinden/",
      "url": "https://ayedo.de/posts/gateway-api-und-edge-routing-in-kubernetes-verbinden/",
      "title": "Gateway API und Edge Routing in Kubernetes verbinden",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/gateway-api-und-edge-routing-in-kubernetes-verbinden/gateway-api-und-edge-routing-in-kubernetes-verbinden.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eDie Kubernetes \u003ca href=\"/kubernetes/\"\u003eGateway API\u003c/a\u003e\n trennt Zuständigkeiten zwischen Infrastruktur, Plattform und Anwendung deutlich besser als klassische Ingress-Ressourcen. Für öffentliches Routing reicht die Modellierung im Cluster jedoch nicht immer aus. Eine Edge-Plattform wie die ayedo Edge Cloud verbindet Kubernetes-Routing mit Anycast, Loadbalancing, TLS, Schutzfunktionen und Backend-Failover.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eÖffentliche Routing-Regeln sollten nicht automatisch dort enden, wo ein Kubernetes-Cluster beginnt. Ein häufiger Architekturfehler besteht darin, Ingress oder \u003ca href=\"/kubernetes/\"\u003eGateway API\u003c/a\u003e\n als vollständige Definition des externen Datenpfads zu betrachten. Diese Ressourcen beschreiben vor allem, wie Traffic innerhalb beziehungsweise bis zu einem Gateway verarbeitet wird. DNS, Anycast, DDoS-Schutz, TLS-Terminierung, Backend-Abschirmung und Failover liegen jedoch auf einer vorgelagerten Ebene. Die zentrale Frage lautet deshalb nicht, ob Kubernetes \u003ca href=\"/kubernetes/\"\u003eGateway API\u003c/a\u003e\n oder Edge Routing eingesetzt wird. Entscheidend ist, wie beide Modelle mit klaren Verantwortungsgrenzen zusammenspielen und welche Routing-Regeln an welcher Stelle technisch und betrieblich wirksam werden.\u003c/p\u003e\n\u003ch2 id=\"1-ingress-und-gateway-api-modellieren-routing-unterschiedlich\"\u003e1. Ingress und Gateway API modellieren Routing unterschiedlich\u003c/h2\u003e\n\u003cp\u003eDas klassische Ingress-Modell bündelt externe HTTP- und HTTPS-Regeln in einer vergleichsweise kompakten Ressource. Hosts und Pfade verweisen auf Services; ein Ingress Controller setzt diese Vorgaben in eine konkrete Proxy- oder Loadbalancer-Konfiguration um. Das Modell ist etabliert, bildet Zuständigkeiten aber nur begrenzt ab. TLS, Controller-spezifische Annotationen und erweiterte Routing-Funktionen landen häufig in derselben Konfiguration.\u003c/p\u003e\n\u003cp\u003eDie Kubernetes \u003ca href=\"/kubernetes/\"\u003eGateway API\u003c/a\u003e\n führt dafür explizitere Rollen ein. Ein Gateway beschreibt einen Eintrittspunkt und seine Listener, während HTTPRoute Regeln für Hosts, Pfade und Backends definiert. Über GatewayClass und Referenzen lassen sich Infrastruktur- und Anwendungsebene sauberer trennen. Das ist insbesondere relevant, wenn mehrere Teams Routing-Regeln verwalten, ohne den öffentlichen Netzwerkzugang selbst kontrollieren zu müssen.\u003c/p\u003e\n\u003cp\u003eFür Edge Routing entsteht dadurch ein zweistufiges Modell: Die Edge nimmt den öffentlichen Traffic an und verteilt ihn auf erreichbare Backends. Kubernetes \u003ca href=\"/kubernetes/\"\u003eGateway API\u003c/a\u003e\n beschreibt anschließend, welche Anwendung innerhalb dieser Backend-Struktur zuständig ist.\u003c/p\u003e\n\u003ch2 id=\"2-der-öffentliche-datenpfad-endet-nicht-am-gateway\"\u003e2. Der öffentliche Datenpfad endet nicht am Gateway\u003c/h2\u003e\n\u003cp\u003eEin Kubernetes Gateway ist ein Routing- und Policy-Punkt im Clusterkontext. Der öffentliche Eingang kann jedoch davor liegen. Anycast DNS und Anycast-basiertes Layer-4- und Layer-7-Loadbalancing bestimmen, wie Anfragen die Edge erreichen und auf geeignete Backends verteilt werden. Diese Ebene kann unabhängig davon bestehen, ob das Backend ein ayedo Managed Kubernetes Cluster, ein eigener Cluster oder eine Kubernetes-Umgebung bei einem anderen Provider ist.\u003c/p\u003e\n\u003cp\u003eDiese Trennung verhindert, dass jeder Cluster direkt als öffentlich exponierter Endpunkt behandelt werden muss. TLS kann an der Edge terminiert werden; Backend Cloaking reduziert die Sichtbarkeit interner Endpunkte. Health Checks und Failover beziehen sich auf die Erreichbarkeit der Backends, während HTTPRoute die fachliche Weiterleitung innerhalb des Zielsystems beschreibt.\u003c/p\u003e\n\u003cp\u003eWichtig ist die Semantik der Regeln: Ein Hostname kann an der Edge als Routing- und Schutzgrenze dienen und im Cluster erneut durch HTTP Routing ausgewertet werden. Das ist keine zwangsläufige Doppelkonfiguration, sondern eine bewusste Aufteilung von Netzwerk- und Anwendungsebene.\u003c/p\u003e\n\u003ch2 id=\"3-verantwortlichkeiten-zwischen-edge-und-kubernetes-abgrenzen\"\u003e3. Verantwortlichkeiten zwischen Edge und Kubernetes abgrenzen\u003c/h2\u003e\n\u003cp\u003eDie \u003ca href=\"/kubernetes/\"\u003eGateway API\u003c/a\u003e\n schafft eine bessere Delegation, ersetzt aber keine Architekturentscheidung über den externen Traffic. Infrastrukturverantwortliche definieren typischerweise Gateway- beziehungsweise Listener-relevante Vorgaben, während Anwendungsteams HTTPRoute-Ressourcen für ihre Services verwalten. An der Edge müssen parallel Fragen zu DNS, IP-Adressierung, TLS, Schutz und Backend-Erreichbarkeit beantwortet werden.\u003c/p\u003e\n\u003cp\u003eEine belastbare Integration braucht deshalb ein klares Ownership-Modell. Wer darf einen öffentlichen Host registrieren? Wer ändert ein Backend? Wie werden Zertifikate und Failover geprüft? Welche Regeln gelten, wenn eine HTTPRoute im Cluster vorhanden ist, der Host an der Edge aber nicht freigeschaltet wurde? Ohne diese Antworten entstehen Konfigurationen, die syntaktisch gültig, aber operativ wirkungslos sind.\u003c/p\u003e\n\u003cp\u003eDie ayedo Edge Cloud ist in diesem Modell keine reine Erweiterung von Managed Kubernetes. Ihre Kubernetes-native Integration kann öffentliche Routing-Anforderungen mit Clustern unterschiedlicher Betriebsmodelle verbinden. Die Edge bleibt für Eingang, Schutz und Verteilung verantwortlich; Kubernetes bleibt der Ort für workloadnahe Routing- und Servicebeziehungen.\u003c/p\u003e\n\u003ch2 id=\"4-routing-modelle-beeinflussen-security-und-betrieb\"\u003e4. Routing-Modelle beeinflussen Security und Betrieb\u003c/h2\u003e\n\u003cp\u003eIngress und \u003ca href=\"/kubernetes/\"\u003eGateway API\u003c/a\u003e\n unterscheiden sich nicht nur in ihrer Ausdrucksstärke, sondern auch in der Steuerbarkeit des Betriebs. Ingress-Konfigurationen hängen oft stark von Controller-spezifischen Erweiterungen ab. Das kann Migrationen erschweren und Sicherheitsprüfungen unübersichtlich machen. \u003ca href=\"/kubernetes/\"\u003eGateway API\u003c/a\u003e\n standardisiert zentrale Konzepte wie Listener, Routen und Referenzen stärker und unterstützt damit klarere Plattformgrenzen.\u003c/p\u003e\n\u003cp\u003eFür die Edge ist zusätzlich entscheidend, welche Prüfungen vor dem Cluster stattfinden. Eine Web Application Firewall kann HTTP- und HTTPS-Anfragen an der Edge bewerten, während DDoS Protection und Scrubbing volumetrische oder protokollbezogene Belastungen vom Backend fernhalten. Proxy Protocol kann Informationen über die ursprüngliche Verbindung an nachgelagerte Systeme weitergeben, sofern die Backend-Kette dies unterstützt.\u003c/p\u003e\n\u003cp\u003eBetrieblich entsteht ein zentraler Vorteil durch die Entkopplung: Änderungen an HTTPRoute müssen nicht zwangsläufig die öffentliche IP- oder DNS-Struktur verändern. Umgekehrt können Edge-Routing, TLS oder Failover angepasst werden, ohne jede Anwendungskonfiguration im Cluster neu zu modellieren. Das reduziert Kopplung, verlangt aber konsequentes Monitoring beider Ebenen.\u003c/p\u003e\n\u003ch2 id=\"praxis--und-betriebsszenario\"\u003ePraxis- und Betriebsszenario\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt dieselbe Anwendung in zwei Kubernetes-Clustern. An der Edge wird ein öffentlicher Hostname über Anycast DNS erreichbar gemacht. Das Edge Routing verteilt Anfragen anhand von Health Checks auf die verfügbaren Cluster. Innerhalb jedes Clusters definiert eine HTTPRoute, welcher Host und welcher Pfad an welchen Service weitergeleitet werden.\u003c/p\u003e\n\u003cp\u003eBeim klassischen Ingress-Modell könnten Controller-spezifische Annotationen zusätzlich festlegen, wie TLS, Weiterleitungen oder Timeout-Verhalten umgesetzt werden. Das erschwert den Vergleich zwischen Clustern. Mit \u003ca href=\"/kubernetes/\"\u003eGateway API\u003c/a\u003e\n lassen sich die workloadnahen Regeln strukturierter abbilden. Die Edge-Konfiguration bleibt dennoch separat: Sie steuert öffentlichen Zugang, Backend-Auswahl und Schutz, während die Route im Cluster die Anwendung auflöst.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"ersetzt-die-gateway-api-eine-edge-plattform\"\u003eErsetzt die \u003ca href=\"/kubernetes/\"\u003eGateway API\u003c/a\u003e\n eine Edge-Plattform?\u003c/h3\u003e\n\u003cp\u003eNein. Sie modelliert Routing im Kubernetes-Umfeld. DNS, Anycast, DDoS-Schutz, Edge-TLS, Backend-Failover und öffentliche Erreichbarkeit bleiben eigenständige Verantwortungsbereiche.\u003c/p\u003e\n\u003ch3 id=\"muss-die-ayedo-edge-cloud-mit-managed-kubernetes-betrieben-werden\"\u003eMuss die ayedo Edge Cloud mit Managed Kubernetes betrieben werden?\u003c/h3\u003e\n\u003cp\u003eNein. Die Kubernetes-native Integration kann auch mit eigenen oder bei anderen Providern betriebenen Kubernetes-Clustern genutzt werden.\u003c/p\u003e\n\u003ch3 id=\"warum-nicht-direkt-auf-einen-kubernetes-service-routen\"\u003eWarum nicht direkt auf einen Kubernetes-Service routen?\u003c/h3\u003e\n\u003cp\u003eEin vorgelagerter Edge-Eingang kann Backend-Endpunkte abschirmen, Traffic prüfen und verteilen. Dadurch werden öffentliche Erreichbarkeit und workloadnahes HTTP Routing getrennt steuerbar.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eKubernetes \u003ca href=\"/kubernetes/\"\u003eGateway API\u003c/a\u003e\n und Edge Routing lösen unterschiedliche Teile desselben öffentlichen Datenpfads. Gateway und HTTPRoute strukturieren Zuständigkeiten im Cluster; die Edge kontrolliert den externen Eingang, Schutz, Termination und Backend-Verteilung. Diese Trennung ist besonders wertvoll bei mehreren Clustern oder Providern. Die ayedo Edge Cloud ordnet sich als eigenständige Edge-Plattform vor diesen Workloads ein und verbindet Kubernetes-native Routing-Modelle mit Anycast, Loadbalancing und betrieblicher Kontrolle.\u003c/p\u003e\n",
      "summary": "\nTL;DR Die Kubernetes Gateway API trennt Zuständigkeiten zwischen Infrastruktur, Plattform und Anwendung deutlich besser als klassische Ingress-Ressourcen. Für öffentliches Routing reicht die Modellierung im Cluster jedoch nicht immer aus. Eine Edge-Plattform wie die ayedo Edge Cloud verbindet Kubernetes-Routing mit Anycast, Loadbalancing, TLS, Schutzfunktionen und Backend-Failover.\nEinleitung Öffentliche Routing-Regeln sollten nicht automatisch dort enden, wo ein Kubernetes-Cluster beginnt. Ein häufiger Architekturfehler besteht darin, Ingress oder Gateway API als vollständige Definition des externen Datenpfads zu betrachten. Diese Ressourcen beschreiben vor allem, wie Traffic innerhalb beziehungsweise bis zu einem Gateway verarbeitet wird. DNS, Anycast, DDoS-Schutz, TLS-Terminierung, Backend-Abschirmung und Failover liegen jedoch auf einer vorgelagerten Ebene. Die zentrale Frage lautet deshalb nicht, ob Kubernetes Gateway API oder Edge Routing eingesetzt wird. Entscheidend ist, wie beide Modelle mit klaren Verantwortungsgrenzen zusammenspielen und welche Routing-Regeln an welcher Stelle technisch und betrieblich wirksam werden.\n",
      "image": "https://ayedo.de/gateway-api-und-edge-routing-in-kubernetes-verbinden.png",
      "date_published": "2026-09-02T14:11:45Z",
      "date_modified": "2026-09-02T14:11:45Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["kubernetes","cloud-native","development","operations","digital-sovereignty"],
      "language": "de"
    },{
      "id": "https://ayedo.de/posts/loadbalancer-provisionierung-aus-kubernetes-steuern/",
      "url": "https://ayedo.de/posts/loadbalancer-provisionierung-aus-kubernetes-steuern/",
      "title": "Loadbalancer-Provisionierung aus Kubernetes steuern",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/loadbalancer-provisionierung-aus-kubernetes-steuern/loadbalancer-provisionierung-aus-kubernetes-steuern.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eKubernetes kann den gewünschten öffentlichen Dienstzustand deklarativ beschreiben, übernimmt aber nicht automatisch die gesamte Netzwerkbereitstellung. Eine Kubernetes-Integration verbindet Ressourcen wie \u003ccode\u003eService\u003c/code\u003e mit einer Edge-Plattform, die öffentliche Erreichbarkeit, Routing und Schutz umsetzt. So bleiben Anwendung und Infrastruktur getrennt, während der Betriebsprozess automatisiert wird.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eEin häufiger Architekturfehler besteht darin, Kubernetes-Services und öffentliche Netzwerkplattform gleichzusetzen. Ein \u003ccode\u003eService\u003c/code\u003e vom Typ \u003ccode\u003eLoadBalancer\u003c/code\u003e beschreibt zunächst einen gewünschten Zustand innerhalb des Kubernetes-Modells. Damit daraus ein erreichbarer öffentlicher Endpunkt entsteht, muss eine externe Komponente diese Absicht erkennen, adressieren und die erforderlichen Netzwerkfunktionen bereitstellen. Genau an dieser Stelle trennt sich die deklarative Steuerungsebene von der eigentlichen Edge-Infrastruktur. Für den Betrieb ist diese Trennung entscheidend: Kubernetes bleibt für Workloads und Service-Definitionen zuständig, während die Edge Cloud den öffentlichen Eingang, die Verteilung und den Schutz des Traffics übernimmt.\u003c/p\u003e\n\u003ch2 id=\"1-kubernetes-beschreibt-den-gewünschten-zustand\"\u003e1. Kubernetes beschreibt den gewünschten Zustand\u003c/h2\u003e\n\u003cp\u003eKubernetes-Ressourcen sind deklarative Schnittstellen. Ein Team definiert beispielsweise einen \u003ccode\u003eService\u003c/code\u003e, legt Ports fest und bestimmt je nach Architektur, ob dieser Dienst intern oder öffentlich erreichbar sein soll. Kubernetes versucht anschließend, den beschriebenen Zustand herzustellen und dauerhaft mit dem tatsächlichen Zustand abzugleichen.\u003c/p\u003e\n\u003cp\u003eBei einem \u003ccode\u003eService\u003c/code\u003e vom Typ \u003ccode\u003eLoadBalancer\u003c/code\u003e ist die Absicht klar: Für einen Dienst soll eine externe Erreichbarkeit hergestellt werden. Kubernetes selbst stellt dadurch jedoch nicht automatisch Anycast-Routing, DNS, DDoS-Schutz oder eine globale Traffic-Verteilung bereit. Diese Funktionen liegen außerhalb des Kubernetes-Kerns und benötigen eine Infrastruktur, die den Service-Zustand interpretieren kann.\u003c/p\u003e\n\u003cp\u003eDie automatische Provisionierung entsteht somit durch das Zusammenspiel mehrerer Komponenten. Eine Kubernetes-native Integration beobachtet relevante Ressourcen, leitet daraus Konfigurationsänderungen ab und übergibt diese an die öffentliche Netzwerkplattform. Änderungen an Ports, Backends oder dem gewünschten Veröffentlichungsstatus können dadurch in einen kontrollierten Bereitstellungsprozess einfließen. Kubernetes bleibt deklarative Quelle der Absicht; die Edge Cloud setzt diese Absicht im öffentlichen Netz um.\u003c/p\u003e\n\u003ch2 id=\"2-die-edge-cloud-übernimmt-eine-andere-verantwortung\"\u003e2. Die Edge Cloud übernimmt eine andere Verantwortung\u003c/h2\u003e\n\u003cp\u003eDie Edge Cloud ist nicht lediglich ein weiterer Loadbalancer innerhalb des Clusters. Sie bildet den öffentlichen Eingang vor den Anwendungen und APIs. Dort wird eingehender Traffic angenommen, geprüft, geschützt und an geeignete Backends verteilt. Diese Aufgaben liegen bewusst außerhalb der Compute-Infrastruktur.\u003c/p\u003e\n\u003cp\u003eFür die Provisionierung bedeutet das: Kubernetes liefert Informationen über den bereitzustellenden Dienst und seine Backends. Die Edge Cloud stellt daraus einen öffentlichen Endpunkt her und übernimmt Funktionen wie Anycast-basiertes Layer-4- und Layer-7-Loadbalancing, TLS Termination, Web Application Firewall und DDoS Protection. Backend Health Checks und Failover tragen dazu bei, nicht verfügbare Ziele aus der Verteilung zu nehmen.\u003c/p\u003e\n\u003cp\u003eDiese Aufgabenteilung reduziert Kopplungen. Ein Cluster muss nicht selbst den gesamten öffentlichen Netzwerkzugang abbilden. Gleichzeitig kann die Edge Cloud vor ayedo Managed Kubernetes, eigenen Kubernetes-Clustern oder Clustern bei anderen Providern eingesetzt werden. Der öffentliche Zugang ist damit nicht an einen bestimmten Compute-Betrieb gebunden. Backend Cloaking kann zusätzlich verhindern, dass interne Zielstrukturen direkt als öffentliche Architektur sichtbar werden.\u003c/p\u003e\n\u003ch2 id=\"3-vom-kubernetes-service-zum-öffentlichen-endpunkt\"\u003e3. Vom Kubernetes-Service zum öffentlichen Endpunkt\u003c/h2\u003e\n\u003cp\u003eTechnisch beginnt der Ablauf mit einer Änderung am gewünschten Zustand: Ein Team legt einen \u003ccode\u003eService\u003c/code\u003e an oder verändert dessen Konfiguration. Die Kubernetes-Integration erkennt diese Änderung und prüft, welche öffentliche Bereitstellung daraus entstehen soll. Dazu gehören unter anderem der zu veröffentlichende Port, das Protokoll und die verfügbaren Backends.\u003c/p\u003e\n\u003cp\u003eAnschließend wird die Edge-Konfiguration aktualisiert. Je nach Anforderung kann der Endpunkt auf Layer 4 oder Layer 7 arbeiten. Bei HTTP- und HTTPS-Diensten lassen sich zusätzlich TLS Termination und WAF-Funktionen an der Edge einordnen. Für die Weiterleitung zum Cluster können technische Mechanismen wie Proxy Protocol relevant sein, wenn der Backend-Dienst Informationen zur ursprünglichen Verbindung benötigt.\u003c/p\u003e\n\u003cp\u003eWichtig ist die Rückkopplung in das Kubernetes-Modell. Ein erfolgreicher Bereitstellungsprozess muss den resultierenden Zustand nachvollziehbar machen, etwa durch die am Service sichtbare externe Erreichbarkeit. Fehler dürfen nicht als scheinbar erfolgreicher Zustand enden. Für Betrieb und Fehlersuche müssen deshalb Kubernetes-Ressource, Edge-Konfiguration, DNS-Auflösung und Backend-Gesundheit gemeinsam betrachtet werden. Automatisierung ersetzt keine Zustandskontrolle; sie macht diese erst skalierbar.\u003c/p\u003e\n\u003ch2 id=\"4-deklarative-steuerung-braucht-klare-betriebsgrenzen\"\u003e4. Deklarative Steuerung braucht klare Betriebsgrenzen\u003c/h2\u003e\n\u003cp\u003eDie technische Automatisierung ist nur dann belastbar, wenn Zuständigkeiten eindeutig definiert sind. Kubernetes-Teams verantworten typischerweise Workloads, Services, Deployments und die gewünschte Veröffentlichung. Die Plattform- oder Netzwerkverantwortlichen definieren dagegen Richtlinien für öffentliche Endpunkte, Schutzfunktionen, Adressierung und Failover. Ohne diese Grenze können Änderungen an einer Kubernetes-Ressource unbeabsichtigt Auswirkungen auf den öffentlichen Netzbetrieb haben.\u003c/p\u003e\n\u003cp\u003eAuch Sicherheitsentscheidungen sollten nicht ausschließlich aus dem Cluster heraus getroffen werden. Ein öffentlich erreichbarer Service benötigt eine Bewertung von TLS, WAF-Regeln, DDoS-Schutz, Backend-Isolation und Monitoring. Die Edge Cloud bietet dafür eine zusammenhängende Plattform mit eigener Netzwerk-Infrastruktur, eigenem Autonomous System und verteilter Aktiv-Aktiv-Architektur. Diese Eigenschaften sind für die öffentliche Erreichbarkeit relevant, während Kubernetes weiterhin die Anwendungsebene beschreibt.\u003c/p\u003e\n\u003cp\u003eWirtschaftlich reduziert eine gemeinsame Provisionierung den manuellen Abstimmungsaufwand zwischen Entwicklung, Plattformbetrieb und Netzwerkteam. Der größere Vorteil liegt jedoch in reproduzierbaren Änderungen und klaren Verantwortungsgrenzen. Ein \u003ccode\u003eService\u003c/code\u003e wird nicht zu einem undokumentierten Sonderfall, sondern zu einem standardisierten Eingangspunkt in einem kontrollierten Bereitstellungsprozess.\u003c/p\u003e\n\u003ch2 id=\"praxis--und-betriebsszenario\"\u003ePraxis- und Betriebsszenario\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt einen \u003ca href=\"/kubernetes/\"\u003eKubernetes-Service\u003c/a\u003e\n für eine API. Der Service soll öffentlich erreichbar sein, die Pods bleiben jedoch in privaten Cluster-Netzen. Das Team beschreibt den Service deklarativ in Kubernetes. Die Integration erzeugt daraus einen öffentlichen Endpunkt in der Edge Cloud, während Health Checks die verfügbaren Backends bestimmen.\u003c/p\u003e\n\u003cp\u003eBei einer Skalierung der Anwendung verändert sich die Backend-Menge im Cluster. Die Edge-Konfiguration muss deshalb den aktuellen Zustand übernehmen, ohne dass ein Netzwerkadministrator manuell Regeln anpasst. Fällt ein Backend aus, kann die Edge Cloud es aus der Verteilung nehmen. Die Anwendung bleibt dabei unabhängig davon, ob der Cluster von ayedo, im eigenen Rechenzentrum oder bei einem anderen Provider betrieben wird. Kubernetes steuert den gewünschten Dienst; die Edge Cloud verantwortet dessen öffentlichen Netzwerkpfad.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"ist-ein-kubernetes-service-bereits-ein-öffentlicher-loadbalancer\"\u003eIst ein Kubernetes-\u003ccode\u003eService\u003c/code\u003e bereits ein öffentlicher Loadbalancer?\u003c/h3\u003e\n\u003cp\u003eNein. Ein \u003ccode\u003eService\u003c/code\u003e beschreibt den gewünschten Zugriff auf Workloads. Die öffentliche Adresse, das Edge-Routing und Schutzfunktionen benötigen eine externe Loadbalancer- oder Edge-Plattform.\u003c/p\u003e\n\u003ch3 id=\"muss-der-kubernetes-cluster-bei-ayedo-betrieben-werden\"\u003eMuss der Kubernetes-Cluster bei ayedo betrieben werden?\u003c/h3\u003e\n\u003cp\u003eNein. Die Kubernetes-native Integration kann auch mit eigenen Clustern oder Kubernetes-Umgebungen anderer Provider genutzt werden. Die Edge Cloud und die Compute-Infrastruktur bleiben getrennte Verantwortungsbereiche.\u003c/p\u003e\n\u003ch3 id=\"was-passiert-bei-einer-änderung-am-service\"\u003eWas passiert bei einer Änderung am Service?\u003c/h3\u003e\n\u003cp\u003eDie Integration erkennt den neuen gewünschten Zustand und aktualisiert die zugehörige Edge-Bereitstellung. Für den Betrieb müssen anschließend Status, DNS, Routing und Backend-Gesundheit konsistent geprüft werden.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eLoadbalancer-Provisionierung aus \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n ist kein einzelner Infrastrukturvorgang, sondern eine Kette aus deklarativer Service-Beschreibung, automatisierter Zustandsübernahme und öffentlicher Traffic-Verarbeitung. Kubernetes steuert, welcher Dienst veröffentlicht werden soll. Die ayedo Edge Cloud übernimmt den öffentlichen Netzwerkpfad, Schutz, Termination und Verteilung. Diese Trennung ermöglicht providerunabhängige Cluster-Architekturen, ohne den Netzwerkbetrieb von der Anwendungskonfiguration zu entkoppeln.\u003c/p\u003e\n",
      "summary": "\nTL;DR Kubernetes kann den gewünschten öffentlichen Dienstzustand deklarativ beschreiben, übernimmt aber nicht automatisch die gesamte Netzwerkbereitstellung. Eine Kubernetes-Integration verbindet Ressourcen wie Service mit einer Edge-Plattform, die öffentliche Erreichbarkeit, Routing und Schutz umsetzt. So bleiben Anwendung und Infrastruktur getrennt, während der Betriebsprozess automatisiert wird.\nEinleitung Ein häufiger Architekturfehler besteht darin, Kubernetes-Services und öffentliche Netzwerkplattform gleichzusetzen. Ein Service vom Typ LoadBalancer beschreibt zunächst einen gewünschten Zustand innerhalb des Kubernetes-Modells. Damit daraus ein erreichbarer öffentlicher Endpunkt entsteht, muss eine externe Komponente diese Absicht erkennen, adressieren und die erforderlichen Netzwerkfunktionen bereitstellen. Genau an dieser Stelle trennt sich die deklarative Steuerungsebene von der eigentlichen Edge-Infrastruktur. Für den Betrieb ist diese Trennung entscheidend: Kubernetes bleibt für Workloads und Service-Definitionen zuständig, während die Edge Cloud den öffentlichen Eingang, die Verteilung und den Schutz des Traffics übernimmt.\n",
      "image": "https://ayedo.de/loadbalancer-provisionierung-aus-kubernetes-steuern.png",
      "date_published": "2026-09-02T14:11:45Z",
      "date_modified": "2026-09-02T14:11:45Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["kubernetes","operations","cloud-native","digital-sovereignty","software-delivery"],
      "language": "de"
    },{
      "id": "https://ayedo.de/posts/ingress-mit-der-ayedo-edge-cloud-automatisieren/",
      "url": "https://ayedo.de/posts/ingress-mit-der-ayedo-edge-cloud-automatisieren/",
      "title": "Ingress mit der ayedo Edge Cloud automatisieren",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/ingress-mit-der-ayedo-edge-cloud-automatisieren/ingress-mit-der-ayedo-edge-cloud-automatisieren.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eKubernetes Ingress automatisieren bedeutet mehr als einen Loadbalancer per YAML zu erzeugen. Entscheidend ist die Verbindung zwischen deklarativer Ressource, Edge-Konfiguration und tatsächlichem Backend. Die ayedo Edge Cloud übernimmt dabei den öffentlichen Eingang, Routing, Schutz und Health Checks, während \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n die gewünschte Veröffentlichung beschreibt.\u003c/p\u003e\n\u003cp\u003eEin manuell konfigurierter Loadbalancer ist zunächst kein Problem. Problematisch wird er, wenn Anwendungen in Kubernetes dynamisch entstehen, sich ihre Endpunkte ändern oder mehrere Cluster und Provider beteiligt sind. Dann entsteht eine operative Lücke zwischen dem Zustand im Cluster und der Infrastruktur davor: DNS-Einträge, Listener, TLS-Konfiguration, Backends und Health Checks müssen außerhalb von Kubernetes gepflegt werden.\u003c/p\u003e\n\u003cp\u003eDie deklarative Veröffentlichung über Ingress-Ressourcen verschiebt diese Zuständigkeit. Der gewünschte externe Zugriff wird als Kubernetes-Konfiguration beschrieben. Eine Kubernetes-native Integration kann daraus die benötigte Anbindung an die ayedo Edge Cloud ableiten und Änderungen kontrolliert nachführen. Dadurch wird die Loadbalancer-Provisionierung Teil des Anwendungsbetriebs statt eines separaten manuellen Infrastrukturprozesses.\u003c/p\u003e\n\u003ch2 id=\"1-ingress-als-deklarativer-vertrag\"\u003e1. Ingress als deklarativer Vertrag\u003c/h2\u003e\n\u003cp\u003eEine Ingress-Ressource beschreibt, welche HTTP- oder HTTPS-Anfragen zu welchem Service gelangen sollen. Typische Angaben sind Hostnamen, Pfade und TLS-Anforderungen. Sie ist damit kein vollständiger Ersatz für die Edge-Infrastruktur, sondern ein deklarativer Vertrag zwischen Anwendungsteam, \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n und der Eingangsschicht.\u003c/p\u003e\n\u003cp\u003eFür den Betrieb ist diese Trennung wichtig. Kubernetes kennt Services und Workload-Endpunkte. Die Edge Cloud verarbeitet dagegen den öffentlichen Traffic vor dem Cluster. Sie benötigt Informationen über Erreichbarkeit, Routing und den Zustand der Backends. Eine Integration muss diese beiden Perspektiven miteinander verbinden, ohne die Zuständigkeiten zu vermischen.\u003c/p\u003e\n\u003cp\u003eBeim Automatisieren wird die Ingress-Ressource zum Auslöser für die Bereitstellung oder Anpassung der externen Veröffentlichung. Änderungen an Hostnamen, Pfaden oder Backends können dadurch über denselben kontrollierten Prozess ausgerollt werden wie Änderungen an Deployments und Services. Das reduziert Konfigurationsdrift zwischen Cluster und vorgeschalteter Infrastruktur.\u003c/p\u003e\n\u003ch2 id=\"2-provisionierung-als-lebenszyklusproblem\"\u003e2. Provisionierung als Lebenszyklusproblem\u003c/h2\u003e\n\u003cp\u003eDie eigentliche Herausforderung der Loadbalancer-Provisionierung liegt nicht im initialen Anlegen. Entscheidend ist der vollständige Lebenszyklus: Erzeugen, Ändern, Prüfen und Entfernen einer Veröffentlichung. Wird eine Anwendung gelöscht, darf ihre externe Route nicht dauerhaft weiterbestehen. Ändert sich ein Service, müssen die Backends und Health Checks zur neuen Situation passen.\u003c/p\u003e\n\u003cp\u003eEin deklaratives Modell arbeitet mit gewünschtem und beobachtetem Zustand. Der gewünschte Zustand steht in Kubernetes-Ressourcen, der beobachtete Zustand umfasst die tatsächlich eingerichtete Edge-Konfiguration und die Erreichbarkeit der Backends. Abweichungen müssen erkannt und nachgeführt werden. Das ist ein anderer Betriebsmodus als ein einmalig ausgeführtes Skript oder ein manuell gepflegtes Ticket.\u003c/p\u003e\n\u003cp\u003eFür Teams bedeutet das: Änderungen werden versionierbar, reviewbar und reproduzierbar. Gleichzeitig müssen Zuständigkeiten geklärt werden. Wer darf externe Hostnamen veröffentlichen? Welche TLS- und Routing-Regeln sind zulässig? Welche Ressourcen werden automatisch entfernt? Ohne solche Regeln kann Automatisierung zwar schneller, aber nicht zwangsläufig kontrollierter werden.\u003c/p\u003e\n\u003ch2 id=\"3-edge-und-cluster-sauber-verbinden\"\u003e3. Edge und Cluster sauber verbinden\u003c/h2\u003e\n\u003cp\u003eKubernetes Networking endet nicht automatisch an der Grenze des Clusters. Der Ingress Controller verarbeitet Regeln innerhalb des Kubernetes-Kontexts, während die ayedo Edge Cloud den öffentlichen Eingang bereitstellt. Sie kann Traffic per Anycast auf die Edge bringen, dort TLS terminieren, Web-Anfragen über die Web Application Firewall prüfen und sie anschließend an geeignete Backends weiterleiten.\u003c/p\u003e\n\u003cp\u003eDiese Aufgabenteilung beeinflusst die Architektur. Die Backends müssen nicht direkt öffentlich adressierbar sein. Backend Cloaking reduziert die Sichtbarkeit der eigentlichen Infrastruktur; Health Checks und Failover unterstützen die Auswahl erreichbarer Ziele. Je nach Aufbau kann die Edge Cloud mit ayedo Managed Kubernetes oder mit eigenen beziehungsweise bei anderen Providern betriebenen Kubernetes-Clustern verbunden werden.\u003c/p\u003e\n\u003cp\u003eDamit wird die Ingress-Ressource nicht zu einer providergebundenen Loadbalancer-Definition. Sie beschreibt die Anwendungsschnittstelle, während die Edge als eigenständige Plattform den öffentlichen Traffic-Eingang, Schutz und Verteilung übernimmt. Das ist besonders relevant, wenn Cluster ersetzt, verschoben oder parallel betrieben werden sollen.\u003c/p\u003e\n\u003ch2 id=\"4-automatisierung-verändert-den-betrieb\"\u003e4. Automatisierung verändert den Betrieb\u003c/h2\u003e\n\u003cp\u003eManuelle Konfiguration verteilt Wissen auf mehrere Systeme: Kubernetes-Manifeste, DNS-Verwaltung, Loadbalancer-Konfiguration und häufig zusätzliche Dokumentation. Fehler entstehen dann nicht nur durch falsche Regeln, sondern auch durch unterschiedliche Änderungszeitpunkte. Eine Route kann bereits im Cluster existieren, während DNS oder Edge-Konfiguration noch fehlen.\u003c/p\u003e\n\u003cp\u003eDie automatische Anbindung verkürzt diese Lücke, beseitigt aber nicht alle Betriebsrisiken. Teams müssen Status und Fehler der Bereitstellung sichtbar machen, Berechtigungen begrenzen und Änderungen nachvollziehbar protokollieren. Ebenso wichtig sind klare Verfahren für Rollback, Löschung und die Behandlung nicht erreichbarer Backends. Ein erfolgreicher Apply-Vorgang ist nicht dasselbe wie eine funktionierende Anwendung.\u003c/p\u003e\n\u003cp\u003eWirtschaftlich verschiebt sich der Aufwand: Weniger manuelle Routinearbeit steht einem höheren Anspruch an Standards, Governance und Plattformbetrieb gegenüber. Für Organisationen mit vielen Services ist diese Verschiebung sinnvoll, weil zentrale Regeln für DNS, Edge-Schutz, TLS und Routing wiederverwendbar werden. Die Edge Cloud wird damit Teil des Plattformmodells, nicht nur ein nachgelagerter Infrastrukturbaustein.\u003c/p\u003e\n\u003ch2 id=\"betriebsszenario-eine-route-über-zwei-cluster\"\u003eBetriebsszenario: Eine Route über zwei Cluster\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt eine API zunächst in einem eigenen Kubernetes-Cluster und veröffentlicht sie über eine Ingress-Ressource. Die ayedo Edge Cloud stellt den öffentlichen Eingang bereit und leitet Anfragen an die definierten Backends weiter. Der Cluster bleibt dabei für Workloads, Services und interne Skalierung verantwortlich.\u003c/p\u003e\n\u003cp\u003eSpäter wird eine zweite Umgebung bei einem anderen Provider aufgebaut. Statt DNS, TLS und Loadbalancer manuell neu zu konfigurieren, wird die gewünschte Veröffentlichung deklarativ erweitert. Die Edge kann die Backends über Health Checks bewerten und bei einem Ausfall auf die erreichbare Umgebung reagieren. Für den Betrieb entstehen dennoch neue Anforderungen: Beide Cluster müssen dieselben Routingannahmen erfüllen, Zuständigkeiten müssen dokumentiert sein und ein Rollback darf nicht nur die Kubernetes-Ressource, sondern auch die externe Veröffentlichung berücksichtigen.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"ersetzt-eine-ingress-ressource-den-loadbalancer\"\u003eErsetzt eine Ingress-Ressource den Loadbalancer?\u003c/h3\u003e\n\u003cp\u003eNein. Sie beschreibt die gewünschte Veröffentlichung. Die Edge Cloud stellt den öffentlichen Eingang, Routing, Schutz und die Weiterleitung zu den Backends bereit.\u003c/p\u003e\n\u003ch3 id=\"funktioniert-die-anbindung-nur-mit-ayedo-managed-kubernetes\"\u003eFunktioniert die Anbindung nur mit ayedo Managed Kubernetes?\u003c/h3\u003e\n\u003cp\u003eNein. Die \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n-Integration kann auch mit eigenen oder bei anderen Providern betriebenen Clustern eingesetzt werden.\u003c/p\u003e\n\u003ch3 id=\"was-passiert-beim-löschen-einer-ingress-ressource\"\u003eWas passiert beim Löschen einer Ingress-Ressource?\u003c/h3\u003e\n\u003cp\u003eDie zugehörige externe Veröffentlichung sollte im Rahmen des deklarativen Lebenszyklus kontrolliert entfernt werden. Dafür sind Statusprüfung und klare Ownership-Regeln erforderlich.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eKubernetes Ingress automatisieren heißt, den Lebenszyklus einer Anwendung bis an den öffentlichen Eingang konsistent zu modellieren. Der entscheidende Gewinn entsteht durch weniger Konfigurationsdrift, nicht durch das bloße Einsparen einzelner Klicks. Die ayedo Edge Cloud ordnet sich dabei als eigenständige Edge-Plattform vor dem Cluster ein: \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n beschreibt die Veröffentlichung, die Edge übernimmt Eingang, Schutz und Verteilung. Diese Trennung schafft eine belastbare Grundlage für providerunabhängigen Betrieb und kontrollierte Änderungen.\u003c/p\u003e\n",
      "summary": "\nTL;DR Kubernetes Ingress automatisieren bedeutet mehr als einen Loadbalancer per YAML zu erzeugen. Entscheidend ist die Verbindung zwischen deklarativer Ressource, Edge-Konfiguration und tatsächlichem Backend. Die ayedo Edge Cloud übernimmt dabei den öffentlichen Eingang, Routing, Schutz und Health Checks, während Kubernetes die gewünschte Veröffentlichung beschreibt.\nEin manuell konfigurierter Loadbalancer ist zunächst kein Problem. Problematisch wird er, wenn Anwendungen in Kubernetes dynamisch entstehen, sich ihre Endpunkte ändern oder mehrere Cluster und Provider beteiligt sind. Dann entsteht eine operative Lücke zwischen dem Zustand im Cluster und der Infrastruktur davor: DNS-Einträge, Listener, TLS-Konfiguration, Backends und Health Checks müssen außerhalb von Kubernetes gepflegt werden.\n",
      "image": "https://ayedo.de/ingress-mit-der-ayedo-edge-cloud-automatisieren.png",
      "date_published": "2026-09-02T14:11:44Z",
      "date_modified": "2026-09-02T14:11:44Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["kubernetes","cloud-native","cloud","operations","hosting"],
      "language": "de"
    },{
      "id": "https://ayedo.de/posts/kubernetes-api-server-sicher-uber-die-edge-anbinden/",
      "url": "https://ayedo.de/posts/kubernetes-api-server-sicher-uber-die-edge-anbinden/",
      "title": "Kubernetes API Server sicher über die Edge anbinden",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/kubernetes-api-server-sicher-uber-die-edge-anbinden/kubernetes-api-server-sicher-uber-die-edge-anbinden.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eEin öffentlich erreichbarer \u003ca href=\"/kubernetes/\"\u003eKubernetes API Server\u003c/a\u003e\n benötigt mehr als eine Weiterleitung auf einen Control-Plane-Endpunkt. Entscheidend sind ein klarer TLS-Modus, restriktives Routing, DDoS-Schutz, Backend-Cloaking und belastbare Health Checks. Eine Edge-Plattform wie die ayedo Edge Cloud trennt dabei öffentlichen Zugang und private Steuerungsebene.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eDer häufigste Fehler bei der Veröffentlichung des Kubernetes API Servers ist, ihn wie eine gewöhnliche Webanwendung zu behandeln. Ein DNS-Eintrag und ein Loadbalancer machen den Endpunkt erreichbar, definieren aber noch keine belastbare Sicherheitsarchitektur. Der API Server ist der zentrale Zugang zur \u003ca href=\"/kubernetes/\"\u003eKubernetes-Steuerungsebene\u003c/a\u003e\n: Über ihn werden Ressourcen gelesen, verändert und teilweise auch Workloads administriert. Wird dieser Zugriff außerhalb des Cluster-Netzes benötigt, müssen Routing, TLS, Authentisierung, DDoS-Schutz und Backend-Erreichbarkeit gemeinsam betrachtet werden. Die zentrale Architekturentscheidung lautet deshalb nicht nur, \u003cem\u003eob\u003c/em\u003e der API Server öffentlich erreichbar ist, sondern an welcher Stelle welcher Sicherheitsmechanismus greift.\u003c/p\u003e\n\u003ch2 id=\"1-öffentlicher-einstieg-und-private-steuerungsebene-trennen\"\u003e1. Öffentlicher Einstieg und private Steuerungsebene trennen\u003c/h2\u003e\n\u003cp\u003eEin öffentlicher Kubernetes API Zugriff sollte nicht bedeuten, dass die tatsächlichen Control-Plane-Adressen direkt im Internet sichtbar sind. Sinnvoller ist ein stabiler Edge-Endpunkt, der eingehende Verbindungen annimmt und ausschließlich zum vorgesehenen API-Service weiterleitet. Die Backends bleiben dabei verborgen; dieses Backend Cloaking reduziert die direkte Angriffsfläche und verhindert, dass interne Topologie und Adressierung zum Bestandteil des öffentlichen Zugriffsmodells werden.\u003c/p\u003e\n\u003cp\u003eTechnisch übernimmt die Edge Cloud den öffentlichen Eingang, das Routing und die Verteilung auf erreichbare Backends. Die Compute- oder Control-Plane-Infrastruktur bleibt für den Betrieb des API Servers verantwortlich. Diese Trennung ist auch organisatorisch relevant: Netzwerk- und Security-Teams können den externen Zugang zentral steuern, während das Kubernetes-Team weiterhin Authentisierung, Autorisierung und die Verfügbarkeit des API Servers betreibt. Das gilt ebenso für eigene Cluster und Cluster bei anderen Providern, nicht nur für ayedo Managed Kubernetes.\u003c/p\u003e\n\u003ch2 id=\"2-tls-modus-passend-zum-kubernetes-zugriffsmodell-wählen\"\u003e2. TLS-Modus passend zum Kubernetes-Zugriffsmodell wählen\u003c/h2\u003e\n\u003cp\u003eTLS ist beim API Server nicht lediglich eine Verschlüsselungsschicht für Browserdaten. Kubernetes-Clients verwenden \u003ccode\u003ekubeconfig\u003c/code\u003e-Dateien, Zertifikate, Token oder andere Authentisierungsverfahren. Deshalb muss vor der Implementierung geklärt werden, ob die Edge TLS nur durchreicht oder an der Edge terminiert. Bei TLS-Passthrough bleibt die Verbindung zwischen Client und API Server Ende-zu-Ende erhalten. Das vereinfacht Szenarien, in denen der API Server selbst Client-Zertifikate auswertet.\u003c/p\u003e\n\u003cp\u003eBei einer TLS Termination an der Edge endet die äußere TLS-Verbindung am Edge-Einstieg. Die Verbindung zum Backend muss anschließend separat abgesichert und die Identität des ursprünglichen Clients sauber in das Backend-Sicherheitsmodell überführt werden. Das ist keine automatische Eigenschaft von HTTP-Headern. Eine Terminierung kann zentrale Zertifikatsverwaltung und Routing vereinfachen, aber sie darf nicht unkritisch eingesetzt werden, wenn Client-Zertifikate oder Ende-zu-Ende-Vertrauen erforderlich sind. TLS-Design und \u003ca href=\"/kubernetes/\"\u003eKubernetes-Authentisierung\u003c/a\u003e\n müssen daher gemeinsam entschieden werden.\u003c/p\u003e\n\u003ch2 id=\"3-ddos-schutz-und-routingregeln-auf-die-steuerungsebene-ausrichten\"\u003e3. DDoS-Schutz und Routingregeln auf die Steuerungsebene ausrichten\u003c/h2\u003e\n\u003cp\u003eDer Kubernetes API Server ist eine besonders kritische, aber nicht beliebig skalierbare Komponente. Schon ein großer Strom ungültiger oder ressourcenintensiver Anfragen kann Control-Plane-Ressourcen binden, selbst wenn Kubernetes die Anfragen später ablehnt. DDoS Protection an der Edge reduziert diese Belastung, indem schädlicher oder volumetrischer Traffic nicht bis zum Backend weitergeleitet werden muss. Bei größeren Angriffen ist entscheidend, dass Scrubbing außerhalb der eigentlichen Cluster-Infrastruktur erfolgt.\u003c/p\u003e\n\u003cp\u003eDDoS-Schutz ersetzt jedoch keine Zugriffskontrolle. Routingregeln sollten den API-Endpunkt auf die erforderlichen Protokolle und Zielbereiche begrenzen. Eine Web Application Firewall kann bei HTTP-/HTTPS-basierten Zugriffen zusätzliche Prüfungen ermöglichen, muss aber mit den Anforderungen des Kubernetes API Servers kompatibel konfiguriert werden. Zu aggressive Regeln, Protokollbeschränkungen oder unpassende Timeouts können legitime Verwaltungszugriffe blockieren. Security gewinnt hier nicht durch möglichst viele Regeln, sondern durch nachvollziehbare und getestete Regeln.\u003c/p\u003e\n\u003ch2 id=\"4-verfügbarkeit-erfordert-mehr-als-einen-erreichbaren-endpunkt\"\u003e4. Verfügbarkeit erfordert mehr als einen erreichbaren Endpunkt\u003c/h2\u003e\n\u003cp\u003eEin DNS-Name, der auf einen einzelnen API-Server zeigt, verlagert das Verfügbarkeitsrisiko lediglich nach außen. Fällt das Backend aus oder wird ein Pfad zur Control Plane unterbrochen, bleibt der öffentliche Endpunkt zwar technisch erreichbar, liefert aber keine nutzbare Kubernetes-Funktion. Backend Health Checks müssen deshalb den tatsächlichen Zustand der angebundenen API-Dienste berücksichtigen. Failover darf nur auf Ziele erfolgen, die die notwendige Kubernetes-Steuerungsebene tatsächlich bereitstellen.\u003c/p\u003e\n\u003cp\u003eEine verteilte Edge-Architektur mit Anycast-Layer-4- und Layer-7-Loadbalancing kann den Zugang unabhängig vom jeweiligen Standort des Clients an die Edge bringen. Multi-Provider-DNS und Anycast DNS adressieren die Namensauflösung und die Erreichbarkeit auf unterschiedlichen Ebenen. Die ayedo Edge Cloud verbindet diese Funktionen mit eigener Netzwerk-Infrastruktur, eigenem Autonomous System und einem Aktiv-Aktiv-Prinzip. Das erhöht nicht automatisch die Verfügbarkeit des Kubernetes API Servers: Die nachgelagerte Control Plane, ihre Netzpfade und ihre Betriebsprozesse bleiben eigenständige Abhängigkeiten.\u003c/p\u003e\n\u003ch2 id=\"praxisszenario-externer-zugriff-auf-einen-eigenen-cluster\"\u003ePraxisszenario: Externer Zugriff auf einen eigenen Cluster\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt einen Kubernetes-Cluster in einer Provider-Umgebung, während Administratoren und CI-Systeme aus mehreren Netzen zugreifen. Der API Server erhält einen dedizierten öffentlichen Hostnamen an der Edge. Die Backends sind nicht direkt adressierbar; eingehende Verbindungen werden ausschließlich zum API-Service geroutet. Das Team entscheidet sich für TLS-Passthrough, weil die Authentisierung über die vom API Server ausgewerteten Client-Zertifikate erhalten bleiben soll. DDoS-Schutz und restriktive Routingregeln wirken vor dem Cluster.\u003c/p\u003e\n\u003cp\u003eVor der Produktivsetzung werden Ausfall des Backends, Zertifikatswechsel und blockierter Traffic getestet. Erst danach wird geprüft, ob ein alternativer TLS-Modus organisatorisch sinnvoll wäre. Die Edge schützt und verteilt den Zugang, ersetzt aber weder Kubernetes-Authentisierung noch die Absicherung der Control Plane selbst.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"ist-ein-öffentlicher-kubernetes-api-server-grundsätzlich-unsicher\"\u003eIst ein öffentlicher Kubernetes API Server grundsätzlich unsicher?\u003c/h3\u003e\n\u003cp\u003eNein. Öffentlich erreichbar bedeutet jedoch eine größere Angriffsfläche. Entscheidend sind ein kontrollierter Edge-Einstieg, korrektes TLS, starke Kubernetes-Authentisierung, restriktives Routing und Schutz vor volumetrischem sowie missbräuchlichem Traffic.\u003c/p\u003e\n\u003ch3 id=\"wann-ist-tls-passthrough-sinnvoller-als-tls-termination\"\u003eWann ist TLS Passthrough sinnvoller als TLS Termination?\u003c/h3\u003e\n\u003cp\u003ePassthrough ist häufig passend, wenn der API Server Client-Zertifikate selbst prüfen soll. TLS Termination kann zentrale Zertifikats- und Routingprozesse vereinfachen, erfordert aber ein klar definiertes Sicherheitsmodell für die Backend-Verbindung.\u003c/p\u003e\n\u003ch3 id=\"kann-die-edge-den-api-server-vollständig-absichern\"\u003eKann die Edge den API Server vollständig absichern?\u003c/h3\u003e\n\u003cp\u003eNein. Die Edge übernimmt öffentlichen Zugang, Routing und vorgelagerte Schutzfunktionen. Identitäten, Kubernetes-RBAC, API-Konfiguration, Betriebssysteme und die Control-Plane-Komponenten bleiben Aufgaben der jeweiligen Betreiber.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eDer sichere Kubernetes API Zugriff über das Internet ist eine Architekturfrage, keine einzelne Konfiguration. Öffentlicher Edge-Einstieg, Backend-Cloaking, passender TLS-Modus, DDoS Protection und geprüfte Health Checks müssen zusammenpassen. Die ayedo Edge Cloud ist dafür als providerunabhängige Plattform vor Kubernetes-Clustern einordenbar: Sie schützt und verteilt den Zugang, ohne die Verantwortungsgrenze zwischen Edge und Compute aufzulösen.\u003c/p\u003e\n",
      "summary": "\nTL;DR Ein öffentlich erreichbarer Kubernetes API Server benötigt mehr als eine Weiterleitung auf einen Control-Plane-Endpunkt. Entscheidend sind ein klarer TLS-Modus, restriktives Routing, DDoS-Schutz, Backend-Cloaking und belastbare Health Checks. Eine Edge-Plattform wie die ayedo Edge Cloud trennt dabei öffentlichen Zugang und private Steuerungsebene.\nEinleitung Der häufigste Fehler bei der Veröffentlichung des Kubernetes API Servers ist, ihn wie eine gewöhnliche Webanwendung zu behandeln. Ein DNS-Eintrag und ein Loadbalancer machen den Endpunkt erreichbar, definieren aber noch keine belastbare Sicherheitsarchitektur. Der API Server ist der zentrale Zugang zur Kubernetes-Steuerungsebene : Über ihn werden Ressourcen gelesen, verändert und teilweise auch Workloads administriert. Wird dieser Zugriff außerhalb des Cluster-Netzes benötigt, müssen Routing, TLS, Authentisierung, DDoS-Schutz und Backend-Erreichbarkeit gemeinsam betrachtet werden. Die zentrale Architekturentscheidung lautet deshalb nicht nur, ob der API Server öffentlich erreichbar ist, sondern an welcher Stelle welcher Sicherheitsmechanismus greift.\n",
      "image": "https://ayedo.de/kubernetes-api-server-sicher-uber-die-edge-anbinden.png",
      "date_published": "2026-09-02T14:11:44Z",
      "date_modified": "2026-09-02T14:11:44Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["kubernetes","security","cloud-native","development","operations"],
      "language": "de"
    },{
      "id": "https://ayedo.de/posts/kubernetes-loadbalancer-providerunabhangig-betreiben/",
      "url": "https://ayedo.de/posts/kubernetes-loadbalancer-providerunabhangig-betreiben/",
      "title": "Kubernetes-Loadbalancer providerunabhängig betreiben",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/kubernetes-loadbalancer-providerunabhangig-betreiben/kubernetes-loadbalancer-providerunabhangig-betreiben.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eEin \u003ca href=\"/kubernetes/\"\u003eKubernetes-Service\u003c/a\u003e\n vom Typ \u003ccode\u003eLoadBalancer\u003c/code\u003e bindet den öffentlichen Einstieg häufig an die Infrastruktur eines einzelnen Cloudproviders. Ein zentraler Edge-Einstieg trennt dagegen Clusterbetrieb und Traffic-Verarbeitung. Die ayedo Edge Cloud übernimmt Routing, Schutz und Verteilung vor Kubernetes-Clustern – unabhängig davon, bei welchem Provider sie betrieben werden.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eEin Kubernetes-Loadbalancer ist nicht nur eine technische Schnittstelle, sondern eine Architekturentscheidung: Wird der öffentliche Traffic durch den jeweiligen Infrastrukturprovider des Clusters verarbeitet oder durch eine davon getrennte Edge-Plattform? Bei einer providergebundenen Lösung entstehen Loadbalancer, IP-Adressen, Health Checks und oft auch DNS-Abhängigkeiten innerhalb desselben Providerkontexts. Das ist zunächst einfach, erschwert aber spätere Clusterwechsel, Multi-Cloud-Szenarien und eine zentrale Sicherheitsarchitektur. Ein providerunabhängiger Einstieg verlagert diese Verantwortung vor die Cluster und entkoppelt den öffentlichen Traffic-Pfad von der Compute-Infrastruktur.\u003c/p\u003e\n\u003ch2 id=\"1-der-providergebundene-kubernetes-loadbalancer\"\u003e1. Der providergebundene Kubernetes-Loadbalancer\u003c/h2\u003e\n\u003cp\u003eIn vielen Kubernetes-Umgebungen wird ein Service vom Typ \u003ccode\u003eLoadBalancer\u003c/code\u003e automatisch mit einem Loadbalancer des Infrastrukturproviders verbunden. Der Cloud Controller Manager erkennt die Ressource und legt beim Provider einen öffentlichen Einstieg an. Der Service erhält eine externe IP-Adresse oder einen DNS-Namen, über den Clients das Backend erreichen.\u003c/p\u003e\n\u003cp\u003eDieser Ansatz reduziert den initialen Integrationsaufwand. Kubernetes und der Provider bilden eine eng abgestimmte Einheit, und Änderungen am Service können unmittelbar in die Infrastruktur des Providers übersetzt werden. Die Kehrseite ist die Kopplung: Der öffentliche Zugang, die IP-Adressierung und Teile des Failover-Verhaltens hängen an einer Providerintegration.\u003c/p\u003e\n\u003cp\u003eBeim Wechsel des Clusters oder Providers müssen DNS-Einträge, Zertifikate, Firewall-Regeln und erlaubte Quellnetze häufig neu bewertet werden. Auch mehrere Cluster bei unterschiedlichen Providern führen schnell zu mehreren Eintrittspunkten mit abweichenden Konfigurationen. Der Kubernetes Loadbalancer erfüllt dann zwar seine lokale Aufgabe, wird aber zum Bestandteil einer providergebundenen Betriebsarchitektur.\u003c/p\u003e\n\u003ch2 id=\"2-ein-zentraler-edge-einstieg-vor-mehreren-clustern\"\u003e2. Ein zentraler Edge-Einstieg vor mehreren Clustern\u003c/h2\u003e\n\u003cp\u003eEin providerunabhängiger Loadbalancer behandelt Kubernetes nicht als Eigentümer des öffentlichen Traffic-Einstiegs. Stattdessen liegt der Einstieg in einer separaten Edge-Schicht. DNS, Anycast-Routing, TLS Termination, WAF, DDoS Protection und die Verteilung auf Backends werden dort zentral betrieben. Die Kubernetes-Cluster stellen lediglich die eigentlichen Anwendungspunkte bereit.\u003c/p\u003e\n\u003cp\u003eFür HTTP- und HTTPS-Services kann die Edge Cloud als Kubernetes Ingress vor den Clustern eingesetzt werden. Die Edge kennt dabei die veröffentlichten Hostnames und leitet Anfragen an definierte Backends weiter. Diese Backends können in ayedo Managed Kubernetes oder in eigenen beziehungsweise bei anderen Providern betriebenen Kubernetes-Clustern liegen. Die Nutzung des \u003ca href=\"/kubernetes/\"\u003eKubernetes-Loadbalancers\u003c/a\u003e\n ist damit nicht an eine bestimmte Compute-Plattform gebunden.\u003c/p\u003e\n\u003cp\u003eArchitektonisch entsteht eine klare Trennung: Die Edge Cloud verantwortet den öffentlichen Zugang, Kubernetes die Bereitstellung der Anwendung. Diese Grenze erleichtert es, Cluster auszutauschen oder parallel zu betreiben, ohne den externen Einstieg neu zu entwerfen.\u003c/p\u003e\n\u003ch2 id=\"3-betriebs--und-sicherheitsfolgen-der-entkopplung\"\u003e3. Betriebs- und Sicherheitsfolgen der Entkopplung\u003c/h2\u003e\n\u003cp\u003eDie Entkopplung verändert vor allem den Betrieb. Ein zentraler Edge-Einstieg bietet einen einheitlichen Ort für Backend Health Checks, Failover und Traffic-Statistiken. Fällt ein Backend aus, kann die Edge den Traffic an einen anderen verfügbaren Anwendungspunkt verteilen, sofern dieser entsprechend konfiguriert und erreichbar ist. Das reduziert die Notwendigkeit, Failover-Logik in jedem einzelnen Cluster separat abzubilden.\u003c/p\u003e\n\u003cp\u003eSecurity-Funktionen liegen ebenfalls vor den Workloads. TLS kann an der Edge terminiert werden, HTTP- und HTTPS-Services können durch eine Web Application Firewall geschützt werden, und DDoS-Traffic wird nicht erst bis zum Kubernetes-Ingress transportiert. Backend Cloaking verhindert zusätzlich, dass die eigentlichen Backend-Adressen als öffentlicher Zielpunkt dienen müssen.\u003c/p\u003e\n\u003cp\u003eWichtig ist dabei die Konfiguration der Vertrauensgrenzen. Der Cluster darf den Edge-Einstieg als autorisierte Quelle erkennen, während die ursprünglichen Clientinformationen kontrolliert weitergegeben werden. Für diesen Zweck kann Proxy Protocol relevant sein. Die Edge wird damit nicht nur zum Routing-Baustein, sondern zu einer zentralen Policy- und Sicherheitsgrenze.\u003c/p\u003e\n\u003ch2 id=\"4-architektur--und-kostenentscheidung-für-plattformteams\"\u003e4. Architektur- und Kostenentscheidung für Plattformteams\u003c/h2\u003e\n\u003cp\u003eDer providergebundene \u003ca href=\"/kubernetes/\"\u003eKubernetes Loadbalancer\u003c/a\u003e\n ist sinnvoll, wenn ein einzelner Provider, ein einzelner Cluster und ein begrenzter öffentlicher Serviceumfang ausreichen. Die Integration ist direkt, und die Zuständigkeiten bleiben zunächst überschaubar. Mit wachsender Plattformlandschaft steigen jedoch die indirekten Kosten: Jede zusätzliche Umgebung bringt eigene Loadbalancer, Konfigurationen, Monitoring-Punkte und Betriebsprozesse mit.\u003c/p\u003e\n\u003cp\u003eEin zentraler providerunabhängiger Einstieg verschiebt Aufwand in eine gemeinsam betriebene Plattform. Dafür müssen Routingregeln, Backend-Lifecycle, Ownership und Change-Prozesse sauber definiert werden. Dieser Aufwand lohnt sich vor allem dann, wenn mehrere Cluster, Provider oder Umgebungen denselben externen Traffic-Einstieg nutzen sollen.\u003c/p\u003e\n\u003cp\u003eDie ayedo Edge Cloud ist für diese Trennung als zusammenhängende Edge-Plattform ausgelegt: eigenes Autonomous System, eigene Netzwerk-Infrastruktur, verteilte Multi-PoP-Architektur und Aktiv-Aktiv-Betrieb bilden die Grundlage für den öffentlichen Einstieg. Kubernetes bleibt dabei austauschbare Compute-Infrastruktur statt feste Verlängerung eines einzelnen Provider-Loadbalancers.\u003c/p\u003e\n\u003ch2 id=\"praxisszenario-ein-ingress-für-zwei-cluster\"\u003ePraxisszenario: Ein Ingress für zwei Cluster\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt eine Anwendung zunächst in einem Kubernetes-Cluster bei Provider A. Der öffentliche Hostname zeigt auf den providergebundenen Loadbalancer des Clusters. Für eine zweite Umgebung bei Provider B entsteht ein weiterer Einstieg mit eigener IP- und DNS-Konfiguration. Ein Wechsel zwischen beiden Umgebungen erfordert nun Änderungen an mehreren Stellen.\u003c/p\u003e\n\u003cp\u003eMit einem zentralen Edge-Einstieg bleibt der öffentliche Hostname an der Edge. Beide Cluster werden als Backends hinter dem \u003ca href=\"/kubernetes/\"\u003eKubernetes Ingress\u003c/a\u003e\n hinterlegt. Health Checks entscheiden, welcher Anwendungspunkt Traffic erhält; bei Wartung oder Ausfall kann die Verteilung angepasst werden, ohne den externen DNS-Einstieg auszutauschen. Der Clusterwechsel betrifft damit primär das Backend und nicht die gesamte öffentliche Zugangsschicht.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"ist-ein-providerunabhängiger-loadbalancer-nur-für-multi-cloud-erforderlich\"\u003eIst ein providerunabhängiger Loadbalancer nur für Multi-Cloud erforderlich?\u003c/h3\u003e\n\u003cp\u003eNein. Auch bei einem einzelnen Cluster kann die Trennung sinnvoll sein, wenn Security-Funktionen, DNS, TLS oder Failover zentral vor mehreren Anwendungen betrieben werden sollen.\u003c/p\u003e\n\u003ch3 id=\"ersetzt-die-edge-cloud-den-kubernetes-ingress\"\u003eErsetzt die Edge Cloud den Kubernetes Ingress?\u003c/h3\u003e\n\u003cp\u003eSie kann den öffentlichen Ingress-Pfad übernehmen. Kubernetes bleibt für Routing innerhalb der Anwendung und die Bereitstellung der Workloads verantwortlich, abhängig von der gewählten Architektur.\u003c/p\u003e\n\u003ch3 id=\"müssen-kubernetes-cluster-bei-ayedo-betrieben-werden\"\u003eMüssen Kubernetes-Cluster bei ayedo betrieben werden?\u003c/h3\u003e\n\u003cp\u003eNein. Die ayedo Edge Cloud kann mit ayedo Managed Kubernetes sowie mit eigenen oder bei anderen Providern betriebenen Kubernetes-Clustern genutzt werden.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eEin \u003ca href=\"/kubernetes/\"\u003eKubernetes Loadbalancer\u003c/a\u003e\n ist dann providerunabhängig, wenn der öffentliche Einstieg nicht an die Lebensdauer und API eines einzelnen Infrastrukturproviders gekoppelt ist. Die zentrale Edge-Schicht übernimmt Traffic-Verarbeitung, Schutz und Failover, während Cluster als austauschbare Backends behandelt werden. Für Unternehmen mit mehreren Umgebungen schafft diese Trennung einen stabileren Betriebsrahmen. Die ayedo Edge Cloud verbindet dafür providerunabhängigen Kubernetes-Zugang mit eigener Netzwerk-Infrastruktur und einer verteilten Aktiv-Aktiv-Architektur.\u003c/p\u003e\n",
      "summary": "\nTL;DR Ein Kubernetes-Service vom Typ LoadBalancer bindet den öffentlichen Einstieg häufig an die Infrastruktur eines einzelnen Cloudproviders. Ein zentraler Edge-Einstieg trennt dagegen Clusterbetrieb und Traffic-Verarbeitung. Die ayedo Edge Cloud übernimmt Routing, Schutz und Verteilung vor Kubernetes-Clustern – unabhängig davon, bei welchem Provider sie betrieben werden.\nEinleitung Ein Kubernetes-Loadbalancer ist nicht nur eine technische Schnittstelle, sondern eine Architekturentscheidung: Wird der öffentliche Traffic durch den jeweiligen Infrastrukturprovider des Clusters verarbeitet oder durch eine davon getrennte Edge-Plattform? Bei einer providergebundenen Lösung entstehen Loadbalancer, IP-Adressen, Health Checks und oft auch DNS-Abhängigkeiten innerhalb desselben Providerkontexts. Das ist zunächst einfach, erschwert aber spätere Clusterwechsel, Multi-Cloud-Szenarien und eine zentrale Sicherheitsarchitektur. Ein providerunabhängiger Einstieg verlagert diese Verantwortung vor die Cluster und entkoppelt den öffentlichen Traffic-Pfad von der Compute-Infrastruktur.\n",
      "image": "https://ayedo.de/kubernetes-loadbalancer-providerunabhangig-betreiben.png",
      "date_published": "2026-09-02T14:11:44Z",
      "date_modified": "2026-09-02T14:11:44Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["kubernetes","security","operations","cloud","cloud-native"],
      "language": "de"
    },{
      "id": "https://ayedo.de/posts/autoritative-dns-dienste-fur-edge-ausfallsicherheit/",
      "url": "https://ayedo.de/posts/autoritative-dns-dienste-fur-edge-ausfallsicherheit/",
      "title": "Autoritative DNS-Dienste für Edge-Ausfallsicherheit",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/autoritative-dns-dienste-fur-edge-ausfallsicherheit/autoritative-dns-dienste-fur-edge-ausfallsicherheit.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eAutoritative DNS-Dienste sind ein wichtiger Baustein der Edge-Ausfallsicherheit, lösen aber keinen Backend-Ausfall allein. Anycast DNS verbessert die Erreichbarkeit der DNS-Infrastruktur, während Health Checks, Routing, TTLs und Edge-seitiges Failover bestimmen, wie zuverlässig Traffic tatsächlich zu funktionsfähigen Backends gelangt.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eDNS wird in Hochverfügbarkeitsarchitekturen häufig als Failover-Mechanismus betrachtet. Diese Sicht greift zu kurz: Autoritative DNS-Dienste können Antworten ändern, aber keine bereits etablierten Verbindungen umleiten und keine Anwendung reparieren. Ihre Wirkung hängt außerdem von Caches, TTLs, rekursiven Resolvern und dem Verhalten der Clients ab. Für eine belastbare Edge-Ausfallsicherheit muss DNS daher mit einer verteilten Edge, aktiven Health Checks und einem klaren Backend-Failover zusammenspielen. Die zentrale Architekturentscheidung lautet nicht, ob DNS ausfällt, sondern welche Aufgabe DNS im End-to-End-Failover tatsächlich übernehmen soll.\u003c/p\u003e\n\u003ch2 id=\"1-autoritative-dns-dienste-als-kontrollierter-einstiegspunkt\"\u003e1. Autoritative DNS-Dienste als kontrollierter Einstiegspunkt\u003c/h2\u003e\n\u003cp\u003eEin autoritativer DNS-Dienst liefert die verbindliche Antwort für eine Domain oder Zone. Er entscheidet damit, unter welcher IP-Adresse ein Client einen Dienst erreichen soll. Das unterscheidet ihn von rekursiven Resolvern, die Antworten zwischenspeichern und an Clients weitergeben. Für die Edge-Architektur ist diese Trennung entscheidend: Der autoritative Dienst kontrolliert die Quelle der DNS-Antwort, aber nicht den Zeitpunkt, zu dem jeder Client eine neue Antwort abfragt.\u003c/p\u003e\n\u003cp\u003eAnycast DNS unterstützt die Erreichbarkeit, indem mehrere geografisch verteilte DNS-Standorte unter derselben IP-Adresse erreichbar sind. Das Routing des Netzes führt Anfragen typischerweise zu einem geeigneten erreichbaren Standort. Fällt ein einzelner Standort oder ein Pfad aus, kann die Anfrage über einen anderen Standort beantwortet werden. Anycast DNS reduziert damit die Abhängigkeit von einem einzelnen DNS-Endpunkt. Es ersetzt jedoch weder die Verfügbarkeit der Edge-Verarbeitung noch die Funktionsfähigkeit der Backends.\u003c/p\u003e\n\u003ch2 id=\"2-warum-anycast-dns-allein-kein-backend-failover-ist\"\u003e2. Warum Anycast DNS allein kein Backend-Failover ist\u003c/h2\u003e\n\u003cp\u003eEin autoritativer DNS-Dienst kann bei einem erkannten Ausfall eine andere IP-Adresse ausliefern. Das ist sinnvoll, wenn mehrere unabhängige Zielsysteme existieren und deren Erreichbarkeit zuverlässig bewertet wird. Zwischen DNS-Antwort und tatsächlicher Anwendungserreichbarkeit liegen jedoch mehrere Zustände: Ein Resolver kann die Antwort noch im Cache halten, ein Client kann die Adresse wiederverwenden, und bestehende TCP- oder TLS-Verbindungen bleiben zunächst am bisherigen Ziel.\u003c/p\u003e\n\u003cp\u003eDamit entsteht eine zeitliche Lücke zwischen erkanntem Ausfall und wirksamem Failover. Niedrige TTLs verkürzen diese Lücke nicht garantiert, weil Caches und Client-Verhalten die praktische Wirkung beeinflussen. Zudem kann ein Dienst zwar Netzwerkverbindungen annehmen, aber auf Anwendungsebene fehlerhaft sein. Backend-Failover muss deshalb auf geeigneten Health Checks basieren und darf sich nicht ausschließlich auf DNS verlassen. Für laufende Verbindungen braucht es zusätzlich Mechanismen auf der Transport- oder Anwendungsebene.\u003c/p\u003e\n\u003ch2 id=\"3-die-edge-als-zweite-failover-ebene\"\u003e3. Die Edge als zweite Failover-Ebene\u003c/h2\u003e\n\u003cp\u003eEine Edge-Plattform kann die Rolle von DNS und Backend-Failover sauber trennen. DNS verweist auf einen stabilen öffentlichen Einstiegspunkt. Die Edge übernimmt anschließend die Annahme des Traffics, die Auswahl eines verfügbaren Backends und – abhängig vom Protokoll – die weitere Verteilung. Health Checks prüfen dabei die Erreichbarkeit und den Zustand der Backends. Fällt ein Ziel aus, kann die Edge neue Verbindungen an ein anderes funktionsfähiges Backend weiterleiten, ohne dass jede DNS-Antwort geändert werden muss.\u003c/p\u003e\n\u003cp\u003eDas reduziert die Abhängigkeit von DNS-Caches und macht Failover innerhalb der Edge schneller kontrollierbar. Für HTTP- und HTTPS-Dienste kommen zusätzlich TLS Termination, Web Application Firewall und Backend Cloaking als getrennte Edge-Funktionen hinzu. Backend-Adressen müssen dadurch nicht öffentlich veröffentlicht werden. Bei Layer-4-Verbindungen bleiben Protokoll- und Sitzungsanforderungen relevant; ein Wechsel des Backends ist nicht automatisch für jede bestehende Verbindung transparent.\u003c/p\u003e\n\u003ch2 id=\"4-ausfallsicherheit-als-end-to-end-architektur\"\u003e4. Ausfallsicherheit als End-to-End-Architektur\u003c/h2\u003e\n\u003cp\u003eEdge-Ausfallsicherheit entsteht erst durch das Zusammenspiel mehrerer Ebenen: autoritative DNS-Dienste, Netzwerkrouting, verteilte Edge-PoPs, Health Checks, Backend-Failover und die Anwendung selbst. Anycast DNS schützt den DNS-Einstieg, eine Anycast-basierte Edge kann den öffentlichen Traffic-Eingang verteilen, und eine Aktiv-Aktiv-Architektur vermeidet die Abhängigkeit von einem einzelnen aktiven Standort. Das eigene Autonomous System und die eigene Netzwerk-Infrastruktur sind dabei technische Grundlagen für die Kontrolle dieses öffentlichen Pfads.\u003c/p\u003e\n\u003cp\u003eAuch organisatorisch ist die Trennung wichtig. Das Team, das DNS-Zonen verwaltet, muss nicht zwangsläufig für die Anwendungsgesundheit verantwortlich sein. Failover-Kriterien, TTLs, Zuständigkeiten und Wiederanlaufverfahren müssen jedoch zusammen definiert werden. Die ayedo Edge Cloud verbindet Anycast DNS und Multi-Provider-DNS mit Edge-seitigem Loadbalancing, Health Checks und Failover. Das gilt für ayedo Managed \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n ebenso wie für \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n-Cluster bei anderen Providern oder in eigener Infrastruktur.\u003c/p\u003e\n\u003ch2 id=\"praxis--und-betriebsszenario\"\u003ePraxis- und Betriebsszenario\u003c/h2\u003e\n\u003cp\u003eAngenommen, eine API ist über \u003ccode\u003eapi.example.com\u003c/code\u003e erreichbar. Der autoritative DNS-Dienst liefert als Ziel die öffentliche Edge-Adresse, nicht die IP des \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n-Clusters. Fällt ein Backend-Pool aus, bleiben DNS und der öffentliche Einstiegspunkt unverändert. Die Edge erkennt den Ausfall über Health Checks und leitet neue Anfragen an einen zweiten Pool weiter. Nur wenn die gesamte Edge-Erreichbarkeit oder der öffentliche Zielpfad geändert werden muss, wird DNS-Failover relevant.\u003c/p\u003e\n\u003cp\u003eIn einer direkten DNS-zu-Backend-Architektur müsste die DNS-Antwort auf ein alternatives Backend geändert werden. Resolver-Caches und bestehende Verbindungen verlängern dann die Umschaltzeit. Die vorgelagerte Edge verschiebt das Failover an eine Stelle, an der neue Verbindungen aktiv gesteuert werden können.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"sind-niedrige-dns-ttls-ausreichend-für-hochverfügbarkeit\"\u003eSind niedrige DNS-TTLs ausreichend für Hochverfügbarkeit?\u003c/h3\u003e\n\u003cp\u003eNein. Sie verkürzen die mögliche Cache-Dauer, garantieren aber keine sofortige Aktualisierung bei Resolvern, Clients oder bestehenden Verbindungen. TTLs sind ein Baustein, kein vollständiger Failover-Mechanismus.\u003c/p\u003e\n\u003ch3 id=\"was-schützt-anycast-dns-konkret\"\u003eWas schützt Anycast DNS konkret?\u003c/h3\u003e\n\u003cp\u003eAnycast DNS verteilt den autoritativen DNS-Dienst über mehrere erreichbare Netzwerkstandorte. Dadurch sinkt die Abhängigkeit von einem einzelnen Standort oder Pfad. Die Funktion des Backends wird dadurch nicht geprüft oder repariert.\u003c/p\u003e\n\u003ch3 id=\"wann-sollte-failover-an-der-edge-stattfinden\"\u003eWann sollte Failover an der Edge stattfinden?\u003c/h3\u003e\n\u003cp\u003eWenn der öffentliche Einstiegspunkt stabil bleiben soll und neue Verbindungen abhängig vom Backend-Zustand verteilt werden müssen. Die Edge kann dann Health Checks und Routing kombinieren, ohne auf DNS-Cache-Abläufe zu warten.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eAutoritative DNS-Dienste bilden den kontrollierten Namens- und Einstiegspunkt einer Edge-Architektur. Anycast DNS verbessert deren Erreichbarkeit, ist aber kein Ersatz für Backend-Failover. Die belastbarere Architektur hält den öffentlichen Einstieg stabil und verlagert die dynamische Backend-Auswahl an die Edge. Genau dort liegt die technische Bedeutung der ayedo Edge Cloud: DNS, verteilte Edge-Infrastruktur und Health-Check-basiertes Failover werden als zusammenhängende, providerunabhängig nutzbare Plattform betrachtet.\u003c/p\u003e\n",
      "summary": "\nTL;DR Autoritative DNS-Dienste sind ein wichtiger Baustein der Edge-Ausfallsicherheit, lösen aber keinen Backend-Ausfall allein. Anycast DNS verbessert die Erreichbarkeit der DNS-Infrastruktur, während Health Checks, Routing, TTLs und Edge-seitiges Failover bestimmen, wie zuverlässig Traffic tatsächlich zu funktionsfähigen Backends gelangt.\nEinleitung DNS wird in Hochverfügbarkeitsarchitekturen häufig als Failover-Mechanismus betrachtet. Diese Sicht greift zu kurz: Autoritative DNS-Dienste können Antworten ändern, aber keine bereits etablierten Verbindungen umleiten und keine Anwendung reparieren. Ihre Wirkung hängt außerdem von Caches, TTLs, rekursiven Resolvern und dem Verhalten der Clients ab. Für eine belastbare Edge-Ausfallsicherheit muss DNS daher mit einer verteilten Edge, aktiven Health Checks und einem klaren Backend-Failover zusammenspielen. Die zentrale Architekturentscheidung lautet nicht, ob DNS ausfällt, sondern welche Aufgabe DNS im End-to-End-Failover tatsächlich übernehmen soll.\n",
      "image": "https://ayedo.de/autoritative-dns-dienste-fur-edge-ausfallsicherheit.png",
      "date_published": "2026-09-02T14:04:54Z",
      "date_modified": "2026-09-02T14:04:54Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["security","cloud-native","operations","kubernetes","digital-sovereignty"],
      "language": "de"
    },{
      "id": "https://ayedo.de/posts/dns-und-loadbalancing-in-der-edge-architektur-einordnen/",
      "url": "https://ayedo.de/posts/dns-und-loadbalancing-in-der-edge-architektur-einordnen/",
      "title": "DNS und Loadbalancing in der Edge-Architektur einordnen",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/dns-und-loadbalancing-in-der-edge-architektur-einordnen/dns-und-loadbalancing-in-der-edge-architektur-einordnen.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eDNS, Anycast-Erreichbarkeit und Loadbalancing lösen unterschiedliche Aufgaben. Eine erfolgreiche DNS-Auflösung beweist noch keine erreichbare Anwendung; eine erreichbare Edge beweist wiederum nicht, dass ein Backend gesund ist. Für die Fehlerdiagnose muss die gesamte Kette getrennt betrachtet werden: DNS-Antwort, Edge-Erreichbarkeit, Protokollverarbeitung und Backend-Verteilung.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eViele Störungen werden vorschnell als „Loadbalancing-Problem“ bezeichnet, obwohl der Fehler bereits bei der DNS-Auflösung oder beim Routing zur Edge liegt. Umgekehrt kann ein Dienst technisch korrekt über DNS und Anycast erreichbar sein, während die eigentliche Anwendung wegen eines fehlerhaften Backends nicht antwortet. Diese Schichten haben unterschiedliche Zuständigkeiten, Messpunkte und Ausfallbilder. DNS liefert eine Auflösungsentscheidung, Anycast bringt den Traffic zur Edge und das \u003ca href=\"/kubernetes/\"\u003eLoadbalancing\u003c/a\u003e\n verteilt ihn auf geeignete Backends. Im Betrieb ist deshalb entscheidend, die Kette nicht als eine einzige Funktion zu behandeln. Wer die Ebenen systematisch trennt, verkürzt die Fehlersuche und vermeidet unnötige Änderungen an einer funktionierenden Architekturkomponente.\u003c/p\u003e\n\u003ch2 id=\"1-dns-auflösung-ist-der-erste-aber-nicht-der-einzige-prüfpunkt\"\u003e1. DNS-Auflösung ist der erste, aber nicht der einzige Prüfpunkt\u003c/h2\u003e\n\u003cp\u003eBei einer Anfrage beginnt der Ablauf typischerweise mit der DNS-Auflösung des öffentlichen Namens. Der Resolver des Clients fragt die autoritativen DNS-Strukturen ab und erhält die für den Dienst vorgesehene Erreichbarkeitsinformation. In einer Edge-Architektur kann Anycast DNS dafür sorgen, dass DNS-Anfragen über eine verteilte Struktur beantwortet werden. Multi-Provider-DNS kann zusätzlich die Abhängigkeit von einer einzelnen DNS-Infrastruktur reduzieren.\u003c/p\u003e\n\u003cp\u003eFür die Diagnose ist zunächst relevant, ob überhaupt eine gültige Antwort vorliegt, ob sie zum erwarteten Dienst gehört und ob unterschiedliche Resolver konsistente Ergebnisse liefern. Ein Timeout beim DNS-Lookup, eine fehlende Delegation oder veraltete Einträge liegt auf einer anderen Fehlerdomäne als ein späterer HTTP-Fehler. Auch ein negativer DNS-Cache kann dazu führen, dass eine Korrektur nicht sofort bei allen Clients sichtbar wird.\u003c/p\u003e\n\u003cp\u003eEine erfolgreiche Auflösung sagt jedoch nur, wohin ein Client verbinden soll. Sie sagt nicht, ob die Edge erreichbar ist, ob TLS funktioniert oder ob ein Backend Anfragen verarbeiten kann.\u003c/p\u003e\n\u003ch2 id=\"2-anycast-erreichbarkeit-und-edge-routing-getrennt-prüfen\"\u003e2. Anycast-Erreichbarkeit und Edge-Routing getrennt prüfen\u003c/h2\u003e\n\u003cp\u003eNach der DNS-Auflösung baut der Client eine Verbindung zu der veröffentlichten Adresse auf. Anycast sorgt dabei dafür, dass dieselbe Adresse über mehrere Netzpfade erreichbar sein kann. Das Routing entscheidet, an welchem verfügbaren Edge-Punkt der Traffic angenommen wird. Diese Ebene ist weder DNS noch Backend-Loadbalancing: Sie bestimmt zunächst, ob der Datenverkehr die Edge-Infrastruktur erreicht.\u003c/p\u003e\n\u003cp\u003eEin typisches Fehlerbild ist eine erfolgreiche DNS-Auflösung mit anschließendem Verbindungs-Timeout. Dann sollte geprüft werden, ob TCP-Verbindungen aufgebaut werden können, ob die erwartete Zieladresse erreicht wird und ob das Problem aus bestimmten Netzen oder Regionen auftritt. Ein selektiver Ausfall kann auf Routing- oder Erreichbarkeitsprobleme hindeuten, während ein globaler Fehler eher eine übergeordnete Konfiguration oder einen Dienstzustand betrifft.\u003c/p\u003e\n\u003cp\u003eDie ayedo Edge Cloud nutzt eine eigene Netzwerk-Infrastruktur und ein eigenes Autonomous System. Für die Betriebsanalyse bleibt die Schichtentrennung trotzdem entscheidend: Die Edge kann erreichbar sein, ohne dass ein konkretes Backend gesund ist. Umgekehrt kann ein Backend fehlerfrei arbeiten, ohne dass Clients die Edge erreichen.\u003c/p\u003e\n\u003ch2 id=\"3-layer-4--und-layer-7-loadbalancing-unterscheiden\"\u003e3. Layer-4- und Layer-7-Loadbalancing unterscheiden\u003c/h2\u003e\n\u003cp\u003eErreicht eine Verbindung die Edge, beginnt die eigentliche Verarbeitung des Traffics. Layer-4-Loadbalancing verteilt Verbindungen anhand von Transportmerkmalen wie IP-Adresse und Port. Es ist relevant für TCP- oder UDP-basierte Dienste, bei denen die Edge nicht zwingend die Anwendungsebene interpretieren muss. Fehler zeigen sich hier häufig als abgelehnte Verbindungen, Timeouts oder fehlende Weiterleitung.\u003c/p\u003e\n\u003cp\u003eLayer-7-Loadbalancing verarbeitet dagegen Anwendungsmerkmale, etwa HTTP-Hostnamen, Pfade oder Header. Dadurch können Regeln für HTTP-/HTTPS-Services, TLS Termination oder eine gezieltere Backend-Auswahl greifen. Ein TCP-Verbindungsaufbau kann deshalb erfolgreich sein, während die HTTP-Anfrage anschließend mit einem Fehlerstatus beantwortet wird oder kein passendes Routing findet.\u003c/p\u003e\n\u003cp\u003eFür das Troubleshooting müssen Verbindungs- und Anwendungsebene getrennt getestet werden: zunächst der TCP-Handshake, danach TLS und schließlich die konkrete HTTP-Anfrage. Backend Health Checks und Failover beeinflussen, ob ein Ziel überhaupt in die Verteilung einbezogen wird. Ein gesund erscheinender Listener bedeutet daher nicht automatisch, dass die Anwendung hinter ihm korrekt antwortet.\u003c/p\u003e\n\u003ch2 id=\"4-backend-verteilung-und-fehlerdomänen-im-betrieb\"\u003e4. Backend-Verteilung und Fehlerdomänen im Betrieb\u003c/h2\u003e\n\u003cp\u003eAm Ende der Kette steht die Verbindung zum Backend. Die Edge Cloud verteilt den eingehenden Traffic auf konfigurierte Ziele und kann deren Zustand über Health Checks bewerten. Sind alle Backends aus Sicht der Edge fehlerhaft, kann ein Dienst trotz funktionierendem DNS und erreichbarer Anycast-Adresse nicht nutzbar sein. Einzelne fehlerhafte Ziele erzeugen dagegen oft sporadische Fehler, wenn nur ein Teil der Anfragen betroffen ist.\u003c/p\u003e\n\u003cp\u003eFür die Eingrenzung helfen Korrelationen: Treten Fehler nur bei bestimmten Verbindungen auf, liegt der Schwerpunkt eher auf Layer 4. Sind nur bestimmte Pfade, Hostnamen oder Methoden betroffen, ist Layer 7 wahrscheinlicher. Antworten mit Backend-spezifischen Statuscodes oder stark schwankendes Verhalten können auf die Verteilung oder den Zustand einzelner Ziele hinweisen.\u003c/p\u003e\n\u003cp\u003eBackend Cloaking reduziert zusätzlich die direkte öffentliche Sichtbarkeit der eigentlichen Systeme. Dadurch wird die Analyse auf die definierte Edge-zu-Backend-Verbindung konzentriert. In Umgebungen mit ayedo Managed \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n ebenso wie mit eigenen oder bei anderen Providern betriebenen Kubernetes-Clustern bleibt die Verantwortungsgrenze gleich: Die Edge verarbeitet und verteilt den öffentlichen Traffic; der Cluster betreibt die Workloads.\u003c/p\u003e\n\u003ch2 id=\"praxis--und-betriebsszenario\"\u003ePraxis- und Betriebsszenario\u003c/h2\u003e\n\u003cp\u003eEin API-Dienst ist nach einer Änderung nicht erreichbar. Der erste DNS-Test liefert die erwartete Adresse. Ein TCP-Test zur Edge ist ebenfalls erfolgreich, während TLS korrekt terminiert. Ein HTTP-Aufruf auf \u003ccode\u003e/health\u003c/code\u003e funktioniert, Anfragen auf \u003ccode\u003e/orders\u003c/code\u003e liefern jedoch Fehler.\u003c/p\u003e\n\u003cp\u003eDie Diagnose beginnt damit nicht beim DNS. Layer 4 und die Edge-Erreichbarkeit sind nach aktuellem Befund intakt. Der Unterschied liegt auf Layer 7 oder im Backend-Routing. Anschließend werden Routing-Regeln, Health-Check-Ergebnisse und die Verteilung auf die Backends geprüft. Zeigt nur ein Backend Fehler, kann ein Failover oder eine Korrektur dieses Ziels die Störung beheben. Ohne diese schrittweise Prüfung würde eine DNS-Änderung die Ursache nicht beseitigen, sondern lediglich eine weitere Variable einführen.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"beweist-eine-erfolgreiche-dns-auflösung-dass-der-dienst-verfügbar-ist\"\u003eBeweist eine erfolgreiche DNS-Auflösung, dass der Dienst verfügbar ist?\u003c/h3\u003e\n\u003cp\u003eNein. DNS liefert nur die Zielinformation. Erreichbarkeit der Edge, TLS, Protokollverarbeitung und Backend-Zustand müssen separat geprüft werden.\u003c/p\u003e\n\u003ch3 id=\"wann-ist-layer-4-statt-layer-7-relevant\"\u003eWann ist Layer 4 statt Layer 7 relevant?\u003c/h3\u003e\n\u003cp\u003eLayer 4 steht im Vordergrund, wenn bereits der TCP- oder UDP-Verbindungsaufbau scheitert. Layer 7 wird relevant, sobald die Anwendungsebene über HTTP, HTTPS oder Routing-Regeln betroffen ist.\u003c/p\u003e\n\u003ch3 id=\"welche-rolle-spielen-health-checks-bei-der-fehlersuche\"\u003eWelche Rolle spielen Health Checks bei der Fehlersuche?\u003c/h3\u003e\n\u003cp\u003eSie zeigen, ob Backends aus Sicht der Edge als verfügbar gelten. Ein Backend kann lokal funktionieren, aber wegen Erreichbarkeits- oder Prüfproblemen aus der Verteilung ausgeschlossen werden.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eDNS und \u003ca href=\"/kubernetes/\"\u003eLoadbalancing\u003c/a\u003e\n sind keine austauschbaren Bausteine, sondern aufeinanderfolgende Schichten mit unterschiedlichen Fehlerbildern. Eine belastbare Betriebsdiagnose prüft zuerst die Namensauflösung, dann Anycast-Erreichbarkeit, Transportverbindung, Anwendungsrouting und schließlich Backend-Zustand. Die ayedo Edge Cloud bündelt diese Funktionen in einer verteilten Edge-Plattform, ohne die Verantwortungsgrenze zum Compute aufzulösen. Genau diese Trennung macht Fehleranalyse und Betrieb nachvollziehbar.\u003c/p\u003e\n",
      "summary": "\nTL;DR DNS, Anycast-Erreichbarkeit und Loadbalancing lösen unterschiedliche Aufgaben. Eine erfolgreiche DNS-Auflösung beweist noch keine erreichbare Anwendung; eine erreichbare Edge beweist wiederum nicht, dass ein Backend gesund ist. Für die Fehlerdiagnose muss die gesamte Kette getrennt betrachtet werden: DNS-Antwort, Edge-Erreichbarkeit, Protokollverarbeitung und Backend-Verteilung.\nEinleitung Viele Störungen werden vorschnell als „Loadbalancing-Problem“ bezeichnet, obwohl der Fehler bereits bei der DNS-Auflösung oder beim Routing zur Edge liegt. Umgekehrt kann ein Dienst technisch korrekt über DNS und Anycast erreichbar sein, während die eigentliche Anwendung wegen eines fehlerhaften Backends nicht antwortet. Diese Schichten haben unterschiedliche Zuständigkeiten, Messpunkte und Ausfallbilder. DNS liefert eine Auflösungsentscheidung, Anycast bringt den Traffic zur Edge und das Loadbalancing verteilt ihn auf geeignete Backends. Im Betrieb ist deshalb entscheidend, die Kette nicht als eine einzige Funktion zu behandeln. Wer die Ebenen systematisch trennt, verkürzt die Fehlersuche und vermeidet unnötige Änderungen an einer funktionierenden Architekturkomponente.\n",
      "image": "https://ayedo.de/dns-und-loadbalancing-in-der-edge-architektur-einordnen.png",
      "date_published": "2026-09-02T14:04:54Z",
      "date_modified": "2026-09-02T14:04:54Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["cloud-native","operations","hosting","kubernetes","digital-sovereignty"],
      "language": "de"
    },{
      "id": "https://ayedo.de/posts/externe-dns-zonen-zentral-steuern-ohne-providerbindung/",
      "url": "https://ayedo.de/posts/externe-dns-zonen-zentral-steuern-ohne-providerbindung/",
      "title": "Externe DNS-Zonen zentral steuern ohne Providerbindung",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/externe-dns-zonen-zentral-steuern-ohne-providerbindung/externe-dns-zonen-zentral-steuern-ohne-providerbindung.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eProviderunabhängiges DNS entsteht nicht durch den Austausch eines einzelnen Anbieters, sondern durch eine Architektur mit zentraler Steuerung, klarer Verantwortlichkeit und mehreren autoritativen DNS-Pfaden. External Zones lassen sich so konsistent verwalten, während Traffic-Einstieg, Schutz und Routing unabhängig vom DNS-Provider organisiert werden.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eDNS wird häufig dort zentralisiert, wo auch die übrige Internet-Infrastruktur betrieben wird. Genau diese Kopplung erzeugt jedoch einen strategischen Engpass: Änderungen an DNS-Zonen, Traffic-Steuerung und Providerverträgen hängen an derselben Plattform. Ein Anbieterwechsel wird dadurch nicht nur zu einer technischen Migration, sondern zu einem Eingriff in die öffentliche Erreichbarkeit von Anwendungen und APIs. Providerunabhängiges DNS verfolgt einen anderen Ansatz. Es trennt die fachliche und organisatorische Steuerung der Zonen von der Bindung an einen einzelnen autoritativen Dienst. Dafür müssen Delegation, Zuständigkeiten, Ausfallszenarien und der eigentliche Traffic-Einstieg gemeinsam betrachtet werden.\u003c/p\u003e\n\u003ch2 id=\"1-dns-zentralisierung-braucht-eine-klare-trennung-der-verantwortlichkeiten\"\u003e1. DNS-Zentralisierung braucht eine klare Trennung der Verantwortlichkeiten\u003c/h2\u003e\n\u003cp\u003eEine zentrale DNS-Verwaltung bedeutet nicht, dass alle Zonen zwingend bei einem einzigen Provider liegen. Entscheidend ist eine einheitliche Steuerung von Zone Files, Records, Delegationen, Freigaben und Änderungsprozessen. Die autoritativen Nameserver können dabei bei unterschiedlichen Providern betrieben werden, solange die Zuständigkeiten und Synchronisationswege definiert sind.\u003c/p\u003e\n\u003cp\u003eIn größeren Organisationen sollte DNS deshalb als Plattformprozess behandelt werden. Applikationsteams benötigen einen kontrollierten Weg für Records, während Netzwerk- oder Plattformteams Policies, Delegation und Ausfallszenarien verantworten. Ohne diese Trennung entstehen Schattenzonen, manuelle Änderungen und widersprüchliche TTL- oder Routing-Entscheidungen.\u003c/p\u003e\n\u003cp\u003eTechnisch wichtig ist die Unterscheidung zwischen DNS-Steuerung und Traffic-Steuerung. DNS beantwortet Anfragen zu Namen. Es entscheidet aber nicht allein, wie ein Dienst geschützt, terminiert oder zu Backends verteilt wird. Diese Funktionen liegen an einer vorgelagerten Edge. Eine zentrale DNS-Verwaltung sollte daher nicht automatisch eine zentrale Abhängigkeit von derselben Betriebsplattform erzeugen.\u003c/p\u003e\n\u003ch2 id=\"2-multi-provider-dns-reduziert-abhängigkeiten-erhöht-aber-die-betriebsanforderungen\"\u003e2. Multi-Provider-DNS reduziert Abhängigkeiten, erhöht aber die Betriebsanforderungen\u003c/h2\u003e\n\u003cp\u003eMulti-Provider-DNS wird oft als einfache Redundanzmaßnahme verstanden: Mehrere Anbieter veröffentlichen dieselbe Zone, und Resolver können bei Störungen auf einen anderen autoritativen Dienst ausweichen. Das ist nur dann belastbar, wenn die Daten konsistent bleiben und Änderungen reproduzierbar erfolgen.\u003c/p\u003e\n\u003cp\u003eDazu gehören ein definiertes Source-of-Truth-Modell, kontrollierte Publikationsprozesse und eine Prüfung, ob alle Provider dieselben Records und Delegationsanforderungen abbilden. Unterschiede bei Funktionen, Validierung oder Propagation müssen berücksichtigt werden. Eine Zone, die bei Provider A gültig ist, muss nicht automatisch mit identischem Verhalten bei Provider B funktionieren.\u003c/p\u003e\n\u003cp\u003eDer betriebliche Vorteil liegt in der geringeren Abhängigkeit von einem einzelnen DNS-Anbieter. Der Preis ist zusätzliche Komplexität: Änderungen müssen getestet, Zuständigkeiten dokumentiert und Ausfälle regelmäßig bewertet werden. Multi-Provider-DNS ist daher kein Selbstzweck. Es lohnt sich vor allem dort, wo öffentliche Erreichbarkeit, regulatorische Anforderungen, unterschiedliche Providerstrategien oder die Vermeidung eines Vendor Lock-in eine zentrale Rolle spielen.\u003c/p\u003e\n\u003ch2 id=\"3-providerunabhängiges-dns-endet-nicht-bei-der-delegation\"\u003e3. Providerunabhängiges DNS endet nicht bei der Delegation\u003c/h2\u003e\n\u003cp\u003eEine Zone kann bei mehreren Providern autoritativ sein und trotzdem an einen einzelnen Anbieter für die eigentliche Anwendungserreichbarkeit gebunden bleiben. Das passiert beispielsweise, wenn alle Records auf Endpunkte desselben Providers zeigen oder DNS-Änderungen eng mit dessen Loadbalancing und Schutzfunktionen gekoppelt sind.\u003c/p\u003e\n\u003cp\u003eEine belastbare Architektur trennt deshalb drei Ebenen: die Verwaltung der External Zones, die autoritative DNS-Antwort und den öffentlichen Eingang der Anwendungen. Die letzte Ebene umfasst unter anderem Anycast-basiertes Layer-4- und Layer-7-Loadbalancing, TLS Termination, DDoS Protection, Web Application Firewall und Backend Cloaking. DNS verweist dann auf einen unabhängigen Edge-Einstieg, während die eigentlichen Backends bei unterschiedlichen Providern oder in eigenen Rechenzentren betrieben werden können.\u003c/p\u003e\n\u003cp\u003eDie ayedo Edge Cloud ist in diesem Modell keine reine DNS-Verwaltung und kein bloßer vorgelagerter Loadbalancer. Sie verbindet Anycast DNS und Multi-Provider-DNS mit Edge-Funktionen für Routing, Schutz und Verteilung. Durch die providerunabhängige Nutzung kann der Compute-Standort getrennt von der öffentlichen Eintrittsschicht organisiert werden.\u003c/p\u003e\n\u003ch2 id=\"4-zentralisierung-sollte-architekturentscheidungen-statt-anbietergrenzen-abbilden\"\u003e4. Zentralisierung sollte Architekturentscheidungen statt Anbietergrenzen abbilden\u003c/h2\u003e\n\u003cp\u003eFür Unternehmen ist die zentrale Frage nicht: „Welcher DNS-Provider soll Standard werden?“ Relevanter ist: Welche Teile der öffentlichen Infrastruktur müssen unabhängig beweglich bleiben? Dazu gehören Domaindelegation, DNS-Zonen, Edge-Einstieg, Backend-Standorte und Sicherheitsfunktionen.\u003c/p\u003e\n\u003cp\u003eEin sinnvolles Zielbild definiert diese Komponenten getrennt, verbindet sie aber über nachvollziehbare Schnittstellen. DNS-Änderungen werden versioniert und freigegeben. Die Edge referenziert stabile öffentliche Endpunkte. Backends bleiben durch Cloaking vor direkter Erreichbarkeit geschützt. Health Checks und Failover verlagern die Entscheidung über erreichbare Backends an die dafür vorgesehene Edge-Schicht, statt sie ausschließlich über manuelle DNS-Änderungen abzubilden.\u003c/p\u003e\n\u003cp\u003eDie ayedo Edge Cloud unterstützt diese Perspektive durch eigene Netzwerk-Infrastruktur, ein eigenes Autonomous System sowie eine verteilte Multi-PoP-Architektur im Aktiv-Aktiv-Prinzip. Diese Eigenschaften sind relevant, wenn DNS-Zentralisierung nicht nur administrative Vereinfachung, sondern ein Baustein für eine unabhängige öffentliche Infrastruktur sein soll. Sie ersetzen jedoch nicht Governance, Tests und klare Änderungsprozesse.\u003c/p\u003e\n\u003ch2 id=\"praxis--und-betriebsszenario\"\u003ePraxis- und Betriebsszenario\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt Anwendungen in zwei unterschiedlichen Cloud-Umgebungen und möchte seine External Zones zentral steuern. Die Zone wird bei mehreren autoritativen DNS-Providern veröffentlicht. Beide verweisen auf die Edge-Einstiegspunkte, nicht direkt auf die wechselnden Backend-Adressen. Die Edge führt Health Checks aus und verteilt den Traffic an das jeweils verfügbare Backend.\u003c/p\u003e\n\u003cp\u003eBei einem Ausfall eines Compute-Standorts bleibt die DNS-Delegation unverändert. Das reduziert den Änderungsdruck auf die DNS-Schicht und verhindert, dass operative Failover-Entscheidungen von langen manuellen Prozessen abhängen. Ein Wechsel des DNS-Providers betrifft die autoritative Zone, nicht automatisch TLS Termination, DDoS-Schutz oder Backend-Topologie. Genau diese Entkopplung macht die Architektur beweglicher.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"ist-multi-provider-dns-automatisch-ausfallsicher\"\u003eIst Multi-Provider-DNS automatisch ausfallsicher?\u003c/h3\u003e\n\u003cp\u003eNein. Es reduziert die Abhängigkeit von einem Anbieter, erfordert aber konsistente Zonendaten, geprüfte Delegationen und funktionsfähige Betriebsprozesse bei allen beteiligten Providern.\u003c/p\u003e\n\u003ch3 id=\"warum-sollten-dns-und-backend-adresse-getrennt-werden\"\u003eWarum sollten DNS und Backend-Adresse getrennt werden?\u003c/h3\u003e\n\u003cp\u003eDie Trennung verhindert, dass DNS-Änderungen für jedes Backend-Failover nötig werden. Außerdem erschwert Backend Cloaking die direkte Erreichbarkeit der Compute-Infrastruktur.\u003c/p\u003e\n\u003ch3 id=\"ist-providerunabhängiges-dns-dasselbe-wie-ein-providerwechsel\"\u003eIst providerunabhängiges DNS dasselbe wie ein Providerwechsel?\u003c/h3\u003e\n\u003cp\u003eNein. Ein Providerwechsel ersetzt eine Abhängigkeit. Providerunabhängiges DNS verändert die Architektur so, dass DNS, Edge und Compute unabhängig voneinander betrieben und weiterentwickelt werden können.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eProviderunabhängiges DNS ist eine Architekturentscheidung, keine reine Beschaffungsentscheidung. Zentrale Steuerung, Multi-Provider-DNS und eine getrennte Edge-Schicht reduzieren Kopplungen zwischen Domainverwaltung, Traffic-Einstieg und Compute-Betrieb. Die ayedo Edge Cloud ordnet sich dort ein, wo autoritatives DNS mit Anycast, Schutz, Routing und providerunabhängiger Backend-Anbindung verbunden werden soll. Entscheidend bleibt ein Betriebsmodell, das diese technischen Freiheiten tatsächlich nutzt.\u003c/p\u003e\n",
      "summary": "\nTL;DR Providerunabhängiges DNS entsteht nicht durch den Austausch eines einzelnen Anbieters, sondern durch eine Architektur mit zentraler Steuerung, klarer Verantwortlichkeit und mehreren autoritativen DNS-Pfaden. External Zones lassen sich so konsistent verwalten, während Traffic-Einstieg, Schutz und Routing unabhängig vom DNS-Provider organisiert werden.\nEinleitung DNS wird häufig dort zentralisiert, wo auch die übrige Internet-Infrastruktur betrieben wird. Genau diese Kopplung erzeugt jedoch einen strategischen Engpass: Änderungen an DNS-Zonen, Traffic-Steuerung und Providerverträgen hängen an derselben Plattform. Ein Anbieterwechsel wird dadurch nicht nur zu einer technischen Migration, sondern zu einem Eingriff in die öffentliche Erreichbarkeit von Anwendungen und APIs. Providerunabhängiges DNS verfolgt einen anderen Ansatz. Es trennt die fachliche und organisatorische Steuerung der Zonen von der Bindung an einen einzelnen autoritativen Dienst. Dafür müssen Delegation, Zuständigkeiten, Ausfallszenarien und der eigentliche Traffic-Einstieg gemeinsam betrachtet werden.\n",
      "image": "https://ayedo.de/externe-dns-zonen-zentral-steuern-ohne-providerbindung.png",
      "date_published": "2026-09-02T14:04:54Z",
      "date_modified": "2026-09-02T14:04:54Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["development","operations","hosting","kubernetes","cloud-native"],
      "language": "de"
    },{
      "id": "https://ayedo.de/posts/dns-steuerung-und-anycast-routing-klar-trennen/",
      "url": "https://ayedo.de/posts/dns-steuerung-und-anycast-routing-klar-trennen/",
      "title": "DNS-Steuerung und Anycast-Routing klar trennen",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/dns-steuerung-und-anycast-routing-klar-trennen/dns-steuerung-und-anycast-routing-klar-trennen.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eDNS beantwortet die Frage, unter welcher Adresse ein Dienst erreichbar ist. Anycast-Routing bestimmt, zu welchem Netzwerkstandort Pakete gelangen. Erst dort verteilen Layer-4- oder Layer-7-Loadbalancer Verbindungen und Anfragen auf Backends. Eine belastbare Edge-Architektur trennt diese Ebenen, verbindet sie aber kontrolliert.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eEin häufiger Architekturfehler besteht darin, DNS als eigentliche Traffic-Steuerung zu behandeln. Ändert ein Unternehmen einen DNS-Eintrag, wird damit nicht automatisch jede bestehende Verbindung umgeleitet oder die Last innerhalb eines Dienstes verteilt. DNS liefert Namensauflösung; Routing sorgt für die Erreichbarkeit; Loadbalancing entscheidet über die Verteilung eingehender Verbindungen oder HTTP-Anfragen. Diese Unterschiede sind für Failover, Security und Betrieb entscheidend. Die ayedo Edge Cloud verbindet autoritative DNS-Funktionen, Anycast-Netzwerkzugang und Layer-4- beziehungsweise Layer-7-Loadbalancing in einer Plattform. Die Funktionen erfüllen dabei unterschiedliche Aufgaben und sollten auch getrennt geplant werden.\u003c/p\u003e\n\u003ch2 id=\"1-dns-beantwortet-eine-andere-frage-als-routing\"\u003e1. DNS beantwortet eine andere Frage als Routing\u003c/h2\u003e\n\u003cp\u003eAutoritativer DNS verwaltet die Zuordnung eines Namens zu DNS-Ressourceneinträgen. Ein Resolver fragt beispielsweise ab, unter welcher Adresse \u003ccode\u003eapi.example.com\u003c/code\u003e erreichbar ist. Die Antwort wird abhängig von TTL und Resolver-Verhalten zwischengespeichert. Dadurch ist eine DNS-Änderung nicht sofort bei jedem Client wirksam. Bereits etablierte TCP- oder TLS-Verbindungen bleiben ohnehin bestehen, solange sie funktionieren.\u003c/p\u003e\n\u003cp\u003eDNS-Steuerung kann Endpunkte auswählen, etwa zwischen verschiedenen IP-Adressen oder Dienstvarianten. Sie kennt jedoch nicht automatisch den Zustand jeder einzelnen Verbindung und verteilt HTTP-Anfragen nicht wie ein Layer-7-Proxy. Auch ein niedriger TTL-Wert macht DNS nicht zu einem Echtzeitmechanismus für Traffic-Management. Er reduziert lediglich die mögliche Cache-Dauer.\u003c/p\u003e\n\u003cp\u003eFür die Architektur bedeutet das: DNS definiert den öffentlichen Namen und die daraus resultierende Erreichbarkeitsinformation. Es ist eine Kontrollplane für Namensauflösung, nicht die Datenpfad-Entscheidung für jede Anfrage. In der ayedo Edge Cloud gehören Anycast DNS und Multi-Provider-DNS zu dieser vorgelagerten Ebene.\u003c/p\u003e\n\u003ch2 id=\"2-anycast-routing-bestimmt-den-netzwerkpfad\"\u003e2. Anycast-Routing bestimmt den Netzwerkpfad\u003c/h2\u003e\n\u003cp\u003eBei Anycast wird dieselbe IP-Adresse von mehreren Netzwerkstandorten angekündigt. Das Routing im Internet führt Pakete typischerweise zu dem aus Netzwerksicht passenden erreichbaren Standort. Diese Auswahl basiert auf Routinginformationen und Netzwerktopologie, nicht auf dem Inhalt einer HTTP-Anfrage und nicht auf dem aktuellen Zustand einzelner Backend-Instanzen.\u003c/p\u003e\n\u003cp\u003eAnycast Routing beantwortet somit die Frage: An welchem Edge-Standort soll der Netzwerkverkehr in die Plattform eintreten? Es ersetzt weder DNS noch einen Loadbalancer. Fällt ein Standort oder ein Dienstpfad aus, kann die Ankündigung angepasst werden, sodass der Verkehr einen anderen erreichbaren Standort nutzt. Wie schnell und in welchem Umfang diese Änderung wirksam wird, hängt vom Routing und den beteiligten Netzen ab.\u003c/p\u003e\n\u003cp\u003eFür den Betrieb schafft Anycast einen verteilten Eingangspunkt. Die ayedo Edge Cloud nutzt dafür eine eigene Netzwerk-Infrastruktur und ein eigenes Autonomous System in einer verteilten Multi-PoP-Architektur. Das Aktiv-Aktiv-Prinzip ermöglicht, eingehenden Traffic grundsätzlich über mehrere aktive Edge-Standorte anzunehmen, statt einen einzelnen zentralen Eingang als zwingenden Engpass zu planen.\u003c/p\u003e\n\u003ch2 id=\"3-loadbalancing-verteilt-verbindungen-und-anfragen\"\u003e3. Loadbalancing verteilt Verbindungen und Anfragen\u003c/h2\u003e\n\u003cp\u003eErreicht ein Paket einen Edge-Standort, beginnt eine andere Entscheidungsebene. Layer-4-Loadbalancing arbeitet auf Transportebene und verteilt beispielsweise TCP- oder UDP-Verbindungen auf geeignete Backends. Layer-7-Loadbalancing kann bei HTTP- und HTTPS-Verkehr zusätzlich Informationen wie Hostname, Pfad oder Header auswerten. Damit lassen sich Anfragen innerhalb eines Dienstes gezielter routen als mit DNS.\u003c/p\u003e\n\u003cp\u003eDiese Verteilung ist zustands- und servicebezogen. Backend Health Checks können erkennen, ob ein Ziel erreichbar ist. Failover-Mechanismen verhindern anschließend, dass neue Verbindungen an ein nicht verfügbares Backend gehen. TLS Termination an der Edge und eine Web Application Firewall liegen ebenfalls auf der Edge-Verarbeitungsebene, nicht im DNS.\u003c/p\u003e\n\u003cp\u003eDie Trennung hat direkte Security- und Betriebsfolgen. Mit Backend Cloaking bleiben interne Zieladressen vom öffentlichen Zugriff abgeschirmt. Proxy Protocol kann relevante Verbindungsinformationen an Backends weitergeben, ohne den öffentlichen Einstiegspunkt offenzulegen. In der ayedo Edge Cloud werden diese Funktionen vor den eigentlichen Workloads gebündelt, unabhängig davon, ob die Backends in ayedo Managed \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n, einem eigenen Kubernetes-Cluster oder bei einem anderen Provider laufen.\u003c/p\u003e\n\u003ch2 id=\"4-die-ebenen-müssen-zusammenspielen-aber-getrennt-bleiben\"\u003e4. Die Ebenen müssen zusammenspielen, aber getrennt bleiben\u003c/h2\u003e\n\u003cp\u003eEine robuste Architektur modelliert DNS, Routing und Loadbalancing als Kette mit unterschiedlichen Zuständigkeiten. DNS veröffentlicht den Dienstnamen und verweist auf den öffentlichen Einstiegspunkt. Anycast Routing bringt den Traffic zu einem verfügbaren Edge-Standort. Layer-4- oder Layer-7-Loadbalancing verteilt ihn anschließend auf geeignete Backends. Health Checks und Failover beeinflussen die Backend-Auswahl, ohne dass dafür DNS-Einträge bei jeder Zustandsänderung angepasst werden müssen.\u003c/p\u003e\n\u003cp\u003eDiese Aufteilung reduziert betriebliche Kopplung. DNS kann stabil bleiben, während sich Backends, Cluster oder Provider ändern. Gleichzeitig bleibt der öffentliche Endpunkt unabhängig von einer einzelnen Compute-Umgebung. Das ist relevant für Migrationen, Multi-Cloud-Szenarien und \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n Betrieb über Providergrenzen hinweg.\u003c/p\u003e\n\u003cp\u003eFür digitale Souveränität ist dabei nicht allein die Kontrolle über DNS entscheidend. Ebenso relevant sind die Kontrolle über öffentliche IP-Erreichbarkeit, Routing, Schutzfunktionen und den Übergang zu den Backends. Die ayedo Edge Cloud bündelt diese Verantwortungsbereiche als Edge-Plattform und unterstützt dabei auch Bring Your Own IP. DNS wird dadurch nicht zum Loadbalancer; es bleibt eine klar abgegrenzte, aber integrierte Steuerungsebene.\u003c/p\u003e\n\u003ch2 id=\"praxis--und-architekturszenario\"\u003ePraxis- und Architekturszenario\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt eine API in zwei \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n Clustern bei unterschiedlichen Providern. Beide Cluster werden über denselben öffentlichen Dienstnamen angesprochen. Bei einer getrennten DNS-Lösung müsste das Unternehmen für Änderungen an den Zieladressen TTLs, Caches und Failover-Verhalten berücksichtigen. Bestehende Verbindungen würden davon nicht erfasst.\u003c/p\u003e\n\u003cp\u003eMit einem Anycast-Einstiegspunkt bleibt der DNS-Name stabil. Das Routing führt Clients zu einem erreichbaren Edge-Standort; dort prüfen Health Checks die Backends. Ein Layer-7-Loadbalancer kann API-Anfragen anhand definierter Regeln auf die verfügbaren Cluster verteilen. Fällt ein Backend aus, erfolgt die Reaktion auf der Loadbalancing-Ebene. DNS bleibt für Namensauflösung zuständig, statt als verzögerter Ersatz für Backend-Failover missbraucht zu werden.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"kann-dns-backend-failover-übernehmen\"\u003eKann DNS Backend-Failover übernehmen?\u003c/h3\u003e\n\u003cp\u003eDNS kann alternative Adressen veröffentlichen. Wegen Caching, TTLs und bestehender Verbindungen ist es jedoch kein präziser Mechanismus für die sofortige Verteilung oder Umschaltung einzelner Verbindungen.\u003c/p\u003e\n\u003ch3 id=\"ist-anycast-automatisch-ein-loadbalancer\"\u003eIst Anycast automatisch ein Loadbalancer?\u003c/h3\u003e\n\u003cp\u003eNein. Anycast bestimmt den Netzwerkpfad zu einem Edge-Standort. Die Verteilung auf Backends erfolgt anschließend durch Layer-4- oder Layer-7-Loadbalancing.\u003c/p\u003e\n\u003ch3 id=\"warum-dns-und-anycast-gemeinsam-planen\"\u003eWarum DNS und Anycast gemeinsam planen?\u003c/h3\u003e\n\u003cp\u003eDNS definiert den öffentlichen Dienstnamen, Anycast dessen erreichbaren Netzwerkeinstieg. Eine gemeinsame Planung verhindert widersprüchliche Zuständigkeiten und erleichtert Failover sowie Providerwechsel.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eDNS und Anycast-Routing lösen unterschiedliche Probleme: DNS veröffentlicht Erreichbarkeitsinformationen, Anycast bestimmt den Eintrittspfad, und Loadbalancing verteilt den Verkehr auf Services. Wer diese Ebenen vermischt, baut Failover- und Betriebslogik auf einen Mechanismus, der dafür nicht ausgelegt ist. Die ayedo Edge Cloud führt die Funktionen in einer Plattform zusammen, ohne ihre Zuständigkeiten aufzulösen. Genau diese Trennung schafft eine belastbare Grundlage für providerunabhängige Backends und verteilte Edge-Architekturen.\u003c/p\u003e\n",
      "summary": "\nTL;DR DNS beantwortet die Frage, unter welcher Adresse ein Dienst erreichbar ist. Anycast-Routing bestimmt, zu welchem Netzwerkstandort Pakete gelangen. Erst dort verteilen Layer-4- oder Layer-7-Loadbalancer Verbindungen und Anfragen auf Backends. Eine belastbare Edge-Architektur trennt diese Ebenen, verbindet sie aber kontrolliert.\nEinleitung Ein häufiger Architekturfehler besteht darin, DNS als eigentliche Traffic-Steuerung zu behandeln. Ändert ein Unternehmen einen DNS-Eintrag, wird damit nicht automatisch jede bestehende Verbindung umgeleitet oder die Last innerhalb eines Dienstes verteilt. DNS liefert Namensauflösung; Routing sorgt für die Erreichbarkeit; Loadbalancing entscheidet über die Verteilung eingehender Verbindungen oder HTTP-Anfragen. Diese Unterschiede sind für Failover, Security und Betrieb entscheidend. Die ayedo Edge Cloud verbindet autoritative DNS-Funktionen, Anycast-Netzwerkzugang und Layer-4- beziehungsweise Layer-7-Loadbalancing in einer Plattform. Die Funktionen erfüllen dabei unterschiedliche Aufgaben und sollten auch getrennt geplant werden.\n",
      "image": "https://ayedo.de/dns-steuerung-und-anycast-routing-klar-trennen.png",
      "date_published": "2026-09-02T14:04:53Z",
      "date_modified": "2026-09-02T14:04:53Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["security","development","kubernetes","cloud-native","digital-sovereignty"],
      "language": "de"
    },{
      "id": "https://ayedo.de/posts/dns-zonen-per-api-und-terraform-konsistent-verwalten/",
      "url": "https://ayedo.de/posts/dns-zonen-per-api-und-terraform-konsistent-verwalten/",
      "title": "DNS-Zonen per API und Terraform konsistent verwalten",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/dns-zonen-per-api-und-terraform-konsistent-verwalten/dns-zonen-per-api-und-terraform-konsistent-verwalten.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eDNS-Änderungen gehören in denselben kontrollierten Prozess wie andere Infrastrukturänderungen. Mit der ayedo Edge Cloud lassen sich externe DNS-Zonen über API und \u003ca href=\"/kubernetes/\"\u003eTerraform\u003c/a\u003e\n deklarativ verwalten. Versionskontrolle, Reviews und reproduzierbare Ausführung reduzieren manuelle Fehler und schaffen klare Verantwortlichkeiten zwischen Plattform- und Anwendungsteams.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eDNS wird in vielen Unternehmen noch direkt im Webinterface gepflegt. Das funktioniert, solange wenige Personen einzelne Einträge ändern. Mit wachsender Anzahl von Services, Umgebungen und Teams entstehen jedoch schwer nachvollziehbare Zustände: Ein Record wurde manuell angepasst, eine Änderung nicht dokumentiert oder zwischen Test und Produktion unterschiedlich umgesetzt. Der technische Fehler liegt meist nicht im DNS selbst, sondern im fehlenden Änderungsprozess. Wer DNS mit \u003ca href=\"/kubernetes/\"\u003eTerraform\u003c/a\u003e\n verwalten will, behandelt Zonen und Records als versionierte Infrastruktur. Die DNS-API der ayedo Edge Cloud bildet dabei die technische Schnittstelle, während \u003ca href=\"/kubernetes/\"\u003eTerraform\u003c/a\u003e\n die gewünschte Konfiguration beschreibt und ihre Umsetzung in bestehende Platform-Engineering-Prozesse integriert.\u003c/p\u003e\n\u003ch2 id=\"1-dns-zonen-als-deklarativen-infrastrukturzustand-beschreiben\"\u003e1. DNS-Zonen als deklarativen Infrastrukturzustand beschreiben\u003c/h2\u003e\n\u003cp\u003eBei einer imperativen Änderung wird ein einzelner DNS-Record direkt angelegt, verändert oder gelöscht. Der Operator denkt in Aktionen: „Erzeuge diesen Eintrag.“ Eine deklarative Konfiguration beschreibt dagegen den gewünschten Zustand. \u003ca href=\"/kubernetes/\"\u003eTerraform\u003c/a\u003e\n vergleicht diesen Zustand mit der vorhandenen Konfiguration und ermittelt daraus die erforderlichen Änderungen.\u003c/p\u003e\n\u003cp\u003eFür DNS-Zonen ist dieser Unterschied relevant, weil Records nicht isoliert betrachtet werden sollten. Namen, Typen, Zielwerte und weitere Eigenschaften bilden gemeinsam die Konfiguration einer Zone. Eine deklarative Verwaltung macht sichtbar, welche Einträge existieren sollen und welche nicht mehr vorgesehen sind. Das erleichtert Reviews und reduziert das Risiko, dass veraltete Records unbemerkt bestehen bleiben.\u003c/p\u003e\n\u003cp\u003eDie ayedo Edge Cloud stellt für die Verwaltung externer DNS-Zonen eine API bereit, die über \u003ca href=\"/kubernetes/\"\u003eTerraform\u003c/a\u003e\n genutzt werden kann. Damit wird DNS nicht zu einem Sonderprozess neben der übrigen Infrastruktur. Zonen können wie andere Ressourcen beschrieben, geplant und kontrolliert ausgerollt werden. Die konkrete Konfiguration bleibt dabei im Repository und nicht ausschließlich im Zustand eines einzelnen Webinterfaces.\u003c/p\u003e\n\u003ch2 id=\"2-versionskontrolle-schafft-nachvollziehbare-änderungen\"\u003e2. Versionskontrolle schafft nachvollziehbare Änderungen\u003c/h2\u003e\n\u003cp\u003eDer zentrale Vorteil von Infrastructure as Code ist nicht nur die Automatisierung, sondern die Nachvollziehbarkeit. Eine Änderung am DNS wird als Diff sichtbar: Welcher Record wurde ergänzt, welcher Zielwert geändert und welcher Eintrag entfernt? Diese Information gehört in den normalen Review-Prozess und kann mit einer fachlichen Begründung, einem Ticket oder einer Änderung an der zugehörigen Anwendung verknüpft werden.\u003c/p\u003e\n\u003cp\u003eFür Platform-Engineering-Teams entsteht dadurch eine klare Trennung zwischen Definition und Ausführung. Das Repository enthält die gewünschte Konfiguration. \u003ca href=\"/kubernetes/\"\u003eTerraform\u003c/a\u003e\n erzeugt daraus einen Plan. Erst nach Prüfung wird die Änderung angewendet. So lässt sich beispielsweise kontrollieren, ob ein neuer Name auf das vorgesehene Ziel zeigt oder ob ein bestehender Record versehentlich überschrieben wird.\u003c/p\u003e\n\u003cp\u003eAuch bei Störungen ist diese Historie wertvoll. Wenn eine DNS-Änderung zu unerwartetem Verhalten führt, kann das Team den Zeitpunkt und Inhalt der Änderung nachvollziehen und gezielt korrigieren. Ein Rollback ist dabei kein beliebiges Zurücksetzen, sondern die Wiederherstellung einer bekannten Konfiguration aus der Versionshistorie. Das verbessert die Betriebsfähigkeit, ersetzt aber keine fachliche Prüfung von TTLs, Delegationen oder abhängigen Systemen.\u003c/p\u003e\n\u003ch2 id=\"3-api-und-terraform-sinnvoll-in-betriebsprozesse-integrieren\"\u003e3. API und Terraform sinnvoll in Betriebsprozesse integrieren\u003c/h2\u003e\n\u003cp\u003e\u003ca href=\"/kubernetes/\"\u003eTerraform\u003c/a\u003e\n sollte nicht als weiterer manueller Zugang neben der API und dem Portal betrieben werden. Entscheidend ist eine definierte Zuständigkeit: Welche Änderungen werden ausschließlich über \u003ca href=\"/kubernetes/\"\u003eTerraform\u003c/a\u003e\n vorgenommen, und welche Fälle dürfen direkt über die API erfolgen? Ohne diese Regel entstehen zwei Wahrheiten. \u003ca href=\"/kubernetes/\"\u003eTerraform\u003c/a\u003e\n kennt dann einen Zustand, während die DNS-Zone bereits manuell verändert wurde.\u003c/p\u003e\n\u003cp\u003eFür reguläre Änderungen empfiehlt sich ein standardisierter Ablauf: Konfiguration anpassen, Plan erzeugen, Änderungen prüfen, Anwendung ausführen und Ergebnis dokumentieren. Automatisierte Prüfungen können zusätzlich Format, Namenskonventionen oder erlaubte Zonentypen kontrollieren. Der [Terraform]-State muss dabei zuverlässig und für die zuständigen Teams zugänglich verwaltet werden. Andernfalls können parallele Änderungen zu Konflikten führen.\u003c/p\u003e\n\u003cp\u003eDirekte API-Änderungen bleiben in bestimmten Situationen sinnvoll, etwa bei einer begrenzten operativen Korrektur oder wenn ein automatisierter Prozess bewusst außerhalb des [Terraform]-Lebenszyklus arbeitet. Solche Ausnahmen müssen jedoch sichtbar bleiben. Nach einer manuellen Änderung sollte die deklarative Konfiguration zeitnah angepasst werden. Sonst überschreibt der nächste [Terraform]-Lauf möglicherweise eine beabsichtigte Änderung oder entfernt sie unbeabsichtigt.\u003c/p\u003e\n\u003ch2 id=\"4-trennung-von-plattformverantwortung-und-service-lifecycle\"\u003e4. Trennung von Plattformverantwortung und Service-Lifecycle\u003c/h2\u003e\n\u003cp\u003eDNS ist häufig eng mit dem Lebenszyklus einer Anwendung verbunden, wird aber nicht immer vom selben Team betrieben. Ein Platform-Team kann die DNS-Zonen und den technischen Rahmen verwalten, während Anwendungsteams ihre benötigten Records über kontrollierte Schnittstellen oder Pull Requests einbringen. Diese Trennung reduziert direkte Zugriffe und macht Verantwortlichkeiten eindeutig.\u003c/p\u003e\n\u003cp\u003eDabei sollte die Verwaltung nicht auf ayedo Managed \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n beschränkt werden. Die ayedo Edge Cloud kann als vorgelagerte Plattform auch vor eigenen oder bei anderen Providern betriebenen [Kubernetes]-Clustern eingesetzt werden. DNS-Konfiguration und Clusterbetrieb bleiben damit getrennte Verantwortungsbereiche. Ein Service kann in einer Compute-Umgebung laufen, während sein öffentlicher DNS-Einstieg zentral über die Edge Cloud verwaltet wird.\u003c/p\u003e\n\u003cp\u003eDiese Entkopplung ist auch aus Betriebssicht relevant. Ein Clusterwechsel muss nicht automatisch eine manuelle DNS-Migration auslösen, wenn die DNS-Zone unabhängig versioniert und über die API verwaltet wird. Zugleich darf die technische Trennung nicht zu unklaren Übergaben führen: Für jeden Record sollten Zweck, Zielsystem und zuständiges Team bekannt sein. So wird DNS mit \u003ca href=\"/kubernetes/\"\u003eTerraform\u003c/a\u003e\n zu einem kontrollierten Bestandteil des Service-Lifecycles statt zu einer isolierten Administrationsaufgabe.\u003c/p\u003e\n\u003ch2 id=\"praxis--und-betriebsszenario\"\u003ePraxis- und Betriebsszenario\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt mehrere öffentliche Services in unterschiedlichen [Kubernetes]-Clustern. Die DNS-Zone wird zentral in der ayedo Edge Cloud verwaltet. Ein neuer Service benötigt einen zusätzlichen Namen und einen Record auf den vorgesehenen öffentlichen Einstieg.\u003c/p\u003e\n\u003cp\u003eDas Anwendungsteam erstellt eine Änderung im Repository. \u003ca href=\"/kubernetes/\"\u003eTerraform\u003c/a\u003e\n zeigt im Plan ausschließlich den neuen Record. Das Platform-Team prüft Ziel, Namenskonvention und die Auswirkungen auf den Service-Lifecycle. Nach dem Review wird die Änderung angewendet und ist anschließend über Git-Historie und [Terraform]-State nachvollziehbar.\u003c/p\u003e\n\u003cp\u003eWürde derselbe Record direkt im Portal angelegt, wäre der operative Effekt zunächst identisch. Der Unterschied zeigt sich später: Ohne deklarative Konfiguration fehlen standardisierte Prüfung, reproduzierbare Wiederherstellung und eine belastbare Verbindung zur Anwendungsänderung.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"kann-dns-vollständig-ohne-manuelle-änderungen-verwaltet-werden\"\u003eKann DNS vollständig ohne manuelle Änderungen verwaltet werden?\u003c/h3\u003e\n\u003cp\u003eJa, reguläre Änderungen können über \u003ca href=\"/kubernetes/\"\u003eTerraform\u003c/a\u003e\n und die ayedo Edge Cloud API automatisiert werden. Ausnahmen sollten dokumentiert und anschließend mit der deklarativen Konfiguration abgeglichen werden.\u003c/p\u003e\n\u003ch3 id=\"was-passiert-bei-einer-manuellen-änderung-außerhalb-von-terraform\"\u003eWas passiert bei einer manuellen Änderung außerhalb von \u003ca href=\"/kubernetes/\"\u003eTerraform\u003c/a\u003e\n?\u003c/h3\u003e\n\u003cp\u003e\u003ca href=\"/kubernetes/\"\u003eTerraform\u003c/a\u003e\n erkennt eine Abweichung zwischen gewünschtem und tatsächlichem Zustand. Vor dem nächsten Apply sollte geklärt werden, ob die manuelle Änderung übernommen oder zurückgesetzt werden soll.\u003c/p\u003e\n\u003ch3 id=\"ist-terraform-nur-für-ayedo-managed-kubernetes-relevant\"\u003eIst \u003ca href=\"/kubernetes/\"\u003eTerraform\u003c/a\u003e\n nur für ayedo Managed \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n relevant?\u003c/h3\u003e\n\u003cp\u003eNein. Die DNS-Verwaltung ist von der Compute-Umgebung getrennt und kann auch für eigene oder bei anderen Providern betriebene [Kubernetes]-Cluster eingesetzt werden.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eDNS mit \u003ca href=\"/kubernetes/\"\u003eTerraform\u003c/a\u003e\n zu verwalten, ist vor allem eine Entscheidung für kontrollierbare Betriebsprozesse. Die DNS-API liefert die programmierbare Schnittstelle, \u003ca href=\"/kubernetes/\"\u003eTerraform\u003c/a\u003e\n beschreibt den gewünschten Zustand, und Versionskontrolle sowie Reviews machen Änderungen nachvollziehbar. Die ayedo Edge Cloud unterstützt damit eine klare Trennung zwischen zentralem öffentlichem DNS-Einstieg und den dahinterliegenden Compute-Umgebungen. Entscheidend ist, manuelle Ausnahmen bewusst zu behandeln und nicht dauerhaft parallel zur deklarativen Konfiguration zu betreiben.\u003c/p\u003e\n",
      "summary": "\nTL;DR DNS-Änderungen gehören in denselben kontrollierten Prozess wie andere Infrastrukturänderungen. Mit der ayedo Edge Cloud lassen sich externe DNS-Zonen über API und Terraform deklarativ verwalten. Versionskontrolle, Reviews und reproduzierbare Ausführung reduzieren manuelle Fehler und schaffen klare Verantwortlichkeiten zwischen Plattform- und Anwendungsteams.\nEinleitung DNS wird in vielen Unternehmen noch direkt im Webinterface gepflegt. Das funktioniert, solange wenige Personen einzelne Einträge ändern. Mit wachsender Anzahl von Services, Umgebungen und Teams entstehen jedoch schwer nachvollziehbare Zustände: Ein Record wurde manuell angepasst, eine Änderung nicht dokumentiert oder zwischen Test und Produktion unterschiedlich umgesetzt. Der technische Fehler liegt meist nicht im DNS selbst, sondern im fehlenden Änderungsprozess. Wer DNS mit Terraform verwalten will, behandelt Zonen und Records als versionierte Infrastruktur. Die DNS-API der ayedo Edge Cloud bildet dabei die technische Schnittstelle, während Terraform die gewünschte Konfiguration beschreibt und ihre Umsetzung in bestehende Platform-Engineering-Prozesse integriert.\n",
      "image": "https://ayedo.de/dns-zonen-per-api-und-terraform-konsistent-verwalten.png",
      "date_published": "2026-09-02T14:04:53Z",
      "date_modified": "2026-09-02T14:04:53Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["platform","automation","kubernetes","development","operations"],
      "language": "de"
    },{
      "id": "https://ayedo.de/posts/dnssec-in-multi-provider-dns-sicher-planen-und-betreiben/",
      "url": "https://ayedo.de/posts/dnssec-in-multi-provider-dns-sicher-planen-und-betreiben/",
      "title": "DNSSEC in Multi-Provider-DNS sicher planen und betreiben",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/dnssec-in-multi-provider-dns-sicher-planen-und-betreiben/dnssec-in-multi-provider-dns-sicher-planen-und-betreiben.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003e\u003cstrong\u003eTL;DR:\u003c/strong\u003e\u003c/h2\u003e\n\u003cp\u003eDNSSEC erhöht die Vertrauenswürdigkeit autoritativer DNS-Antworten, macht aber jede Abweichung zwischen DNS-Providern operativ relevant. In einer Multi-Provider-Architektur müssen Zonensignierung, DNSSEC-Schlüssel, DS-Records, Delegation und Failover als zusammenhängender Prozess geplant werden. Ein redundanter DNS-Betrieb ist nur dann belastbar, wenn alle Provider validierbare und konsistente Antworten liefern.\u003c/p\u003e\n\u003cp\u003eViele DNS-Architekturen behandeln DNSSEC wie eine Option, die nach dem Aufbau von Redundanz aktiviert wird. Bei Multi-Provider-DNS ist diese Reihenfolge riskant. Sobald mehrere autoritative Systeme dieselbe Zone ausliefern, müssen nicht nur A-, AAAA- oder MX-Records synchron sein. Auch DNSKEY-, RRSIG- und gegebenenfalls NSEC- beziehungsweise NSEC3-Records müssen zum Signierungsmodell passen.\u003c/p\u003e\n\u003cp\u003eDer zentrale Trade-off lautet: Wer signiert die Zone, und wer besitzt die DNSSEC-Schlüssel? Eine gemeinsame Signaturquelle vereinfacht die Konsistenz, erhöht aber die Abhängigkeit von diesem Signer. Unabhängige Signierung stärkt die Entkopplung der Provider, erfordert jedoch präzise Abstimmung bei Delegation, Schlüsselwechseln und negativen Antworten. DNSSEC ist damit ein Bestandteil der Betriebsarchitektur – nicht nur eine zusätzliche Sicherheitsfunktion.\u003c/p\u003e\n\u003ch2 id=\"1-multi-provider-dns-braucht-ein-eindeutiges-signierungsmodell\"\u003e1. Multi-Provider-DNS braucht ein eindeutiges Signierungsmodell\u003c/h2\u003e\n\u003cp\u003eFür redundantes DNS sind zwei Modelle verbreitet. Beim Single-Signer-Modell wird eine Zone an einer zentralen Stelle signiert und anschließend von mehreren autoritativen Providern verteilt. Alle Provider liefern dann dieselben DNSSEC-Daten aus. Das vereinfacht die Schlüsselhoheit und reduziert Unterschiede bei RRSIG- und DNSKEY-Records.\u003c/p\u003e\n\u003cp\u003eBeim Multi-Signer-Modell signieren mehrere Provider die Zone unabhängig voneinander. Die Zonendaten müssen dabei inhaltlich übereinstimmen, während jeder Signer eigene Schlüssel und Signaturen verwendet. Die Delegation kann mehrere passende DS-Records enthalten. Dieses Modell reduziert die Abhängigkeit von einem einzelnen Signer, vergrößert aber die Zahl der zu koordinierenden Zustände.\u003c/p\u003e\n\u003cp\u003eEntscheidend ist, dass ein Provider nicht nur „irgendwie“ erreichbar ist. Er muss im gewählten Modell vollständige, valide und zeitlich aktuelle Antworten liefern. Anycast DNS und Multi-Provider-DNS verbessern Verfügbarkeit und Verteilung, ersetzen aber keine konsistente \u003ca href=\"/compliance/\"\u003eDNSSEC-Strategie\u003c/a\u003e\n. Im Umfeld der ayedo Edge Cloud muss deshalb vorab feststehen, welche Rolle die Edge-Plattform im Signierungs- und Bereitstellungsprozess übernimmt.\u003c/p\u003e\n\u003ch2 id=\"2-dnssec-delegation-und-schlüsselhoheit-getrennt-planen\"\u003e2. DNSSEC-Delegation und Schlüsselhoheit getrennt planen\u003c/h2\u003e\n\u003cp\u003eDie Vertrauenskette von DNSSEC beginnt beim DS-Record in der übergeordneten Zone und führt über DNSKEY-Records zur signierten Zone. Ein Schlüsselwechsel ist deshalb nicht auf die autoritative Zone beschränkt. Auch die Delegation muss passend vorbereitet und zeitlich korrekt geändert werden. Falsche oder veraltete DS-Records führen dazu, dass Resolver Antworten als ungültig verwerfen.\u003c/p\u003e\n\u003cp\u003eSchlüsselhoheit bedeutet dabei mehr als die Frage, wer Dateien speichern darf. Sie umfasst Generierung, Zugriff, Rotation, Wiederherstellung, Freigabeprozesse und den Umgang mit kompromittierten Schlüsseln. Besonders wichtig ist die Abgrenzung zwischen KSK- und ZSK-Rollen, auch wenn konkrete technische Abläufe je nach Signierungsmodell variieren.\u003c/p\u003e\n\u003cp\u003eBei einem Providerwechsel darf der bisherige DNSSEC-Schlüssel nicht vorschnell entfernt werden. TTLs, Caches und Signaturgültigkeiten müssen berücksichtigt werden. Ein sicherer Ablauf hält alte und neue Vertrauensinformationen lange genug parallel vor, bevor die Delegation bereinigt wird. Die Verantwortung für DNSSEC-Schlüssel sollte vertraglich und organisatorisch eindeutig geregelt sein – unabhängig davon, ob die Zone bei ayedo, einem anderen Provider oder mehreren Plattformen betrieben wird.\u003c/p\u003e\n\u003ch2 id=\"3-synchronisierung-entscheidet-über-die-tatsächliche-redundanz\"\u003e3. Synchronisierung entscheidet über die tatsächliche Redundanz\u003c/h2\u003e\n\u003cp\u003eDie häufigste Fehlannahme lautet, dass mehrere Nameserver automatisch ein ausfallsicheres DNS ergeben. Bei DNSSEC kann ein einzelner fehlerhafter Provider die Redundanz praktisch entwerten. Liefert ein Provider noch eine alte Zonenversion, fehlen RRSIG-Records oder passt sein DNSKEY-Set nicht zur Delegation, entstehen abhängig vom Resolver SERVFAILs oder Validierungsfehler.\u003c/p\u003e\n\u003cp\u003eFür jede autoritative Zone gehören daher mindestens folgende Prüfungen in den Betrieb:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003egleiche fachliche Zonendaten auf allen Providern,\u003c/li\u003e\n\u003cli\u003eerreichbare und vollständige DNSKEY- sowie RRSIG-Records,\u003c/li\u003e\n\u003cli\u003egültige Signaturzeiträume,\u003c/li\u003e\n\u003cli\u003ekonsistente SOA-Serien und TTLs,\u003c/li\u003e\n\u003cli\u003ekorrekte Antworten für nicht existente Namen,\u003c/li\u003e\n\u003cli\u003eerwartete Antworten über IPv4 und IPv6,\u003c/li\u003e\n\u003cli\u003eerfolgreiche Validierung aus Sicht externer Resolver.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eAuch negative DNS-Antworten sind relevant. Werden NSEC- oder NSEC3-Daten nicht konsistent ausgeliefert, können Resolver legitime Antworten ablehnen. Monitoring darf deshalb nicht bei Erreichbarkeit oder HTTP-Statuscodes enden. Es muss die DNSSEC-Kette und das Verhalten jedes autoritativen Providers einzeln prüfen. Traffic- und Nutzungsstatistiken an der Edge können den Betrieb ergänzen, ersetzen aber keine Validierung der DNS-Antworten.\u003c/p\u003e\n\u003ch2 id=\"4-failover-und-änderungen-müssen-dnssec-fähig-sein\"\u003e4. Failover und Änderungen müssen DNSSEC-fähig sein\u003c/h2\u003e\n\u003cp\u003eEin Failover zwischen Providern ist nur dann sicher, wenn beide Seiten dieselbe Vertrauensbeziehung unterstützen. Ein typischer Fehler besteht darin, bei Problemen den Traffic auf einen ungesicherten Provider umzuschalten, während der DS-Record weiterhin aktiv ist. Validierende Resolver akzeptieren diese Antwort nicht. DNSSEC bietet hier keinen Fallback auf „unsicher“, sondern erzwingt die konfigurierte Vertrauenskette.\u003c/p\u003e\n\u003cp\u003eChange-Prozesse müssen deshalb DNSSEC-spezifische Vorbedingungen enthalten. Dazu zählen Tests der vollständigen Delegation, die Prüfung von Signaturgültigkeiten und ein kontrollierter Umgang mit TTLs. Bei Änderungen an der Zone sollte zunächst die Verteilung geprüft werden, bevor ein Provider als aktiv oder bevorzugt betrachtet wird.\u003c/p\u003e\n\u003cp\u003eFür Platform- und SRE-Teams bedeutet das: DNSSEC gehört in Runbooks, Bereitschaftsprozesse und automatisierte Pre-Deployment-Checks. Zuständigkeiten zwischen DNS-Betrieb, Security und Anwendungsteams müssen klar sein. Die ayedo Edge Cloud kann als Bestandteil einer Anycast- und Multi-Provider-DNS-Architektur den öffentlichen DNS-Eingang verteilen; die konkrete Schlüsselhoheit und der Signierungsprozess müssen jedoch ausdrücklich architektonisch festgelegt werden.\u003c/p\u003e\n\u003ch3 id=\"praxis--und-betriebsszenario\"\u003ePraxis- und Betriebsszenario\u003c/h3\u003e\n\u003cp\u003eEin Unternehmen betreibt eine API-Zone über zwei autoritative DNS-Provider. Im ersten Modell signiert ein zentraler Signer die Zone und verteilt sie an beide Provider. Ein Ausfall eines Providers bleibt beherrschbar, solange der zweite dieselben signierten Daten ausliefert. Der zentrale Signer bleibt jedoch ein kritischer Betriebsbestandteil.\u003c/p\u003e\n\u003cp\u003eIm zweiten Modell signieren beide Provider unabhängig. Ein Schlüsselwechsel bei nur einem Provider kann dann zu einer funktionierenden Antwort bei einem Resolver und zu einem Validierungsfehler bei einem anderen führen, wenn DS-Records oder DNSKEY-Sets nicht abgestimmt sind. Vor einer Migration sollte das Unternehmen daher eine Testzone verwenden, beide Provider getrennt validieren und erst danach Delegation und Produktionsbetrieb ändern. Redundanz entsteht nicht durch die Anzahl der Provider, sondern durch konsistente Vertrauensketten.\u003c/p\u003e\n\u003ch3 id=\"faq\"\u003eFAQ\u003c/h3\u003e\n\u003cp\u003e\u003cstrong\u003eVerschlüsselt DNSSEC DNS-Abfragen?\u003c/strong\u003e\nNein. DNSSEC schützt Authentizität und Integrität signierter DNS-Daten. Die Abfragen selbst werden dadurch nicht vertraulich übertragen.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eKann ein ungesicherter Provider als Notfall-Fallback dienen?\u003c/strong\u003e\nNicht solange ein passender DS-Record delegiert ist. Validierende Resolver verwerfen unsignierte oder falsch signierte Antworten typischerweise als ungültig.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eWer sollte DNSSEC-Schlüssel besitzen?\u003c/strong\u003e\nDas hängt vom Signierungsmodell und den Governance-Anforderungen ab. Entscheidend sind klare Zuständigkeiten für Zugriff, Rotation, Wiederherstellung und Delegationsänderungen.\u003c/p\u003e\n\u003ch3 id=\"fazit\"\u003eFazit\u003c/h3\u003e\n\u003cp\u003eDNSSEC macht Multi-Provider-DNS nicht komplizierter, weil mehrere Nameserver existieren, sondern weil mehrere Systeme dieselbe Vertrauenskette zuverlässig abbilden müssen. Signierung, Schlüsselhoheit, Delegation, Synchronisierung und Failover gehören deshalb in ein gemeinsames Betriebsmodell. Eine Edge-Plattform wie die ayedo Edge Cloud ist in diesem Zusammenhang Teil einer verteilten DNS- und Traffic-Architektur. Ihre Redundanz entfaltet ihren Wert jedoch nur, wenn auch die \u003ca href=\"/compliance/\"\u003eDNSSEC-Antworten\u003c/a\u003e\n providerübergreifend geplant, geprüft und sicher geändert werden.\u003c/p\u003e\n",
      "summary": "\nTL;DR: DNSSEC erhöht die Vertrauenswürdigkeit autoritativer DNS-Antworten, macht aber jede Abweichung zwischen DNS-Providern operativ relevant. In einer Multi-Provider-Architektur müssen Zonensignierung, DNSSEC-Schlüssel, DS-Records, Delegation und Failover als zusammenhängender Prozess geplant werden. Ein redundanter DNS-Betrieb ist nur dann belastbar, wenn alle Provider validierbare und konsistente Antworten liefern.\nViele DNS-Architekturen behandeln DNSSEC wie eine Option, die nach dem Aufbau von Redundanz aktiviert wird. Bei Multi-Provider-DNS ist diese Reihenfolge riskant. Sobald mehrere autoritative Systeme dieselbe Zone ausliefern, müssen nicht nur A-, AAAA- oder MX-Records synchron sein. Auch DNSKEY-, RRSIG- und gegebenenfalls NSEC- beziehungsweise NSEC3-Records müssen zum Signierungsmodell passen.\n",
      "image": "https://ayedo.de/dnssec-in-multi-provider-dns-sicher-planen-und-betreiben.png",
      "date_published": "2026-09-02T14:04:53Z",
      "date_modified": "2026-09-02T14:04:53Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["security","kubernetes","hosting","cloud-native","digital-sovereignty"],
      "language": "de"
    },{
      "id": "https://ayedo.de/posts/interne-und-externe-dns-zonen-synchron-halten-im-betrieb/",
      "url": "https://ayedo.de/posts/interne-und-externe-dns-zonen-synchron-halten-im-betrieb/",
      "title": "Interne und externe DNS-Zonen synchron halten im Betrieb",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/interne-und-externe-dns-zonen-synchron-halten-im-betrieb/interne-und-externe-dns-zonen-synchron-halten-im-betrieb.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eDNS-Zonen zu synchronisieren bedeutet nicht, interne und externe Einträge vollständig zu kopieren. Entscheidend ist ein kontrolliertes gemeinsames Datenmodell: Welche Services sind öffentlich, welche bleiben intern, welche Ziele ändern sich und wer darf Änderungen auslösen? Mit klarer Zuständigkeit, definierten Synchronisierungsregeln und getrennten Sichtbarkeiten bleibt DNS konsistent, ohne interne Infrastruktur offenzulegen.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eViele DNS-Probleme entstehen nicht durch einen einzelnen fehlerhaften Record, sondern durch widersprüchliche Änderungen in mehreren Zonenwelten. Ein Service wird intern auf einen neuen Endpoint umgestellt, während die External Zone weiterhin auf das alte Ziel verweist. Oder ein öffentlich erreichbarer Name wird in der Internal Zone anders geschrieben als in der externen Zone. Solche Abweichungen führen zu schwer reproduzierbaren Fehlern: Anwendungen funktionieren aus dem Firmennetz, externe Clients erhalten andere Antworten, und Betriebsteams suchen an den falschen Stellen. DNS-Zonen synchronisieren ist deshalb vor allem eine Frage von Zuständigkeit, Sichtbarkeit und Änderungsprozessen – nicht von möglichst vollständiger Duplizierung.\u003c/p\u003e\n\u003ch2 id=\"1-internal-zone-und-external-zone-erfüllen-unterschiedliche-aufgaben\"\u003e1. Internal Zone und External Zone erfüllen unterschiedliche Aufgaben\u003c/h2\u003e\n\u003cp\u003eEine Internal Zone stellt Namen und Ziele für private Netze, Cluster oder interne Anwendungen bereit. Ihre Records können auf private IP-Adressen, interne Loadbalancer oder ausschließlich intern erreichbare Services zeigen. Eine External Zone beschreibt dagegen die öffentliche Erreichbarkeit. Sie enthält Namen, die über autoritative öffentliche DNS-Infrastrukturen aufgelöst werden, und verweist typischerweise auf öffentlich zugängliche Einstiegspunkte.\u003c/p\u003e\n\u003cp\u003eDiese Zonen dürfen unterschiedliche Antworten liefern, ohne inkonsistent zu sein. Das ist das Prinzip von Split-Horizon-DNS: Derselbe Name kann abhängig vom auflösenden Netz auf unterschiedliche Ziele zeigen. Problematisch wird es, wenn diese Unterschiede unbeabsichtigt entstehen oder niemand dokumentiert, welcher Record führend ist.\u003c/p\u003e\n\u003cp\u003eFür die DNS-Konsistenz müssen daher nicht alle Daten gleich sein. Konsistent bleiben sollten vor allem Service-Identität, Namenskonventionen, fachliche Zuordnung und der gewünschte Veröffentlichungsstatus. Zieladressen, TTLs oder Failover-Parameter können dagegen zonenspezifisch sein. Eine vollständige Zonenkopie würde diese Unterschiede verwischen und könnte interne Infrastruktur nach außen sichtbar machen.\u003c/p\u003e\n\u003ch2 id=\"2-synchronisierung-braucht-ein-gemeinsames-datenmodell\"\u003e2. Synchronisierung braucht ein gemeinsames Datenmodell\u003c/h2\u003e\n\u003cp\u003eBevor technische Automatisierung eingeführt wird, muss definiert sein, welche Informationen zwischen den Zonen synchronisiert werden. Für einen öffentlich erreichbaren Service gehören dazu beispielsweise der DNS-Name, der Record-Typ, die gewünschte Erreichbarkeit und die Zuordnung zur Anwendung. Der externe Record kann auf einen Edge-Endpunkt zeigen, während der interne Record auf einen privaten Service oder einen internen Routing-Punkt verweist.\u003c/p\u003e\n\u003cp\u003eNicht automatisch identisch sein müssen die konkreten Zielwerte. Auch TTLs, Health-Check-Verhalten und Failover-Logik können sich unterscheiden, weil interne und externe Clients andere Anforderungen haben. Ein niedriger TTL-Wert im öffentlichen DNS beschleunigt Umschaltungen, erzeugt aber mehr Abfragen und ersetzt keine saubere Änderungsplanung.\u003c/p\u003e\n\u003cp\u003eSinnvoll ist ein System of Record, das den fachlichen Service beschreibt und daraus die benötigten Zonenansichten ableitet. Alternativ können zwei Systeme bestehen, wenn ihre Verantwortungsgrenzen eindeutig sind. Entscheidend ist, dass manuelle Änderungen an abgeleiteten Records entweder verhindert oder zuverlässig erkannt werden. Sonst entsteht eine scheinbare Synchronisierung, bei der zwar Daten verteilt, aber nicht mehr nachvollziehbar kontrolliert werden.\u003c/p\u003e\n\u003ch2 id=\"3-sichtbarkeit-und-backend-schutz-müssen-getrennt-betrachtet-werden\"\u003e3. Sichtbarkeit und Backend-Schutz müssen getrennt betrachtet werden\u003c/h2\u003e\n\u003cp\u003eDie wichtigste Abgrenzung zwischen Internal Zone und External Zone ist nicht der Name des DNS-Systems, sondern die Sichtbarkeit des Ziels. Öffentliche DNS-Antworten dürfen keine privaten Adressen, internen Hostnamen oder direkten Backend-Zugänge offenlegen. Für öffentlich bereitgestellte Services sollte die External Zone auf den vorgesehenen öffentlichen Eingang zeigen. Das Backend bleibt hinter dieser Schicht verborgen.\u003c/p\u003e\n\u003cp\u003eIm Kontext der ayedo Edge Cloud kann die External Zone öffentliche DNS-Auflösung mit einem Edge-Einstiegspunkt verbinden. Die Edge übernimmt anschließend unter anderem Traffic-Annahme, TLS Termination, Schutz und Weiterleitung zu Backends. Die Internal Zone kann für interne Clients weiterhin ein anderes Ziel liefern, wenn interne Pfade oder private Service-Discovery erforderlich sind. ayedo Managed \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n ist dafür nicht zwingend Voraussetzung: Die Edge Cloud kann auch vor eigenen oder bei anderen Providern betriebenen Kubernetes-Clustern eingesetzt werden.\u003c/p\u003e\n\u003cp\u003eSynchronisiert wird damit die Service-Sicht, nicht zwangsläufig der Netzwerkpfad. Diese Unterscheidung reduziert das Risiko, dass interne Architekturdetails veröffentlicht werden, und erlaubt zugleich, öffentliche und interne Betriebsmodelle unabhängig weiterzuentwickeln.\u003c/p\u003e\n\u003ch2 id=\"4-änderungsprozesse-entscheiden-über-die-tatsächliche-konsistenz\"\u003e4. Änderungsprozesse entscheiden über die tatsächliche Konsistenz\u003c/h2\u003e\n\u003cp\u003eDNS-Konsistenz ist im Betrieb ein Prozessproblem. Jede Änderung braucht eine fachliche Quelle, eine technische Validierung und eine definierte Reihenfolge. Wird ein Service umbenannt, muss zuerst geklärt werden, ob der alte Name intern, extern oder in beiden Zonen weiter gültig bleiben soll. Bei einem Zielwechsel müssen TTL, Caching und mögliche Übergangsphasen berücksichtigt werden.\u003c/p\u003e\n\u003cp\u003eFür Änderungen an öffentlichen Records sind zusätzliche Prüfungen sinnvoll: Antwort aus autoritativen Nameservern, erwartete Sichtbarkeit aus verschiedenen Netzen und Erreichbarkeit des neuen Edge- oder Service-Ziels. Interne Tests allein reichen nicht aus. Umgekehrt darf ein erfolgreicher externer Test nicht als Nachweis gelten, dass interne Anwendungen den vorgesehenen Pfad verwenden.\u003c/p\u003e\n\u003cp\u003eDie ayedo Edge Cloud unterstützt in diesem Zusammenhang Anycast DNS und Multi-Provider-DNS als Teil einer verteilten Edge-Plattform. Das ändert nicht die Notwendigkeit eines sauberen Änderungsprozesses. Es schafft vielmehr einen öffentlichen DNS- und Traffic-Eingang, dessen Records in die eigene Governance passen müssen. Verantwortlichkeiten zwischen Plattformteam, Netzwerkbetrieb und Anwendungsteams sollten deshalb vor der Automatisierung festgelegt sein.\u003c/p\u003e\n\u003ch2 id=\"betriebsszenario-ein-service-mit-interner-und-öffentlicher-sicht\"\u003eBetriebsszenario: Ein Service mit interner und öffentlicher Sicht\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt \u003ccode\u003eapi.example.tld\u003c/code\u003e in einem \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n-Cluster bei einem externen Provider. Externe Clients sollen den Service über die ayedo Edge Cloud erreichen. Interne Anwendungen benötigen dagegen einen privaten Pfad mit geringeren Umwegen und greifen auf einen internen Service-Endpunkt zu.\u003c/p\u003e\n\u003cp\u003eDie External Zone verweist deshalb auf den öffentlichen Edge-Einstiegspunkt, während die Internal Zone denselben fachlichen Service auf das interne Ziel auflöst. Synchronisiert werden Name, Eigentümer, Service-ID und Veröffentlichungsstatus. Nicht synchronisiert werden private IP-Adresse und öffentlicher Zielwert. Bei einem Deployment wird zunächst das interne Ziel geprüft; anschließend wird der externe Edge-Pfad aktualisiert. Ein automatisierter Vergleich meldet, wenn der Service in einer Zone fehlt, unerwartet öffentlich ist oder auf ein veraltetes Ziel zeigt.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"muss-ein-dns-record-in-beiden-zonen-identisch-sein\"\u003eMuss ein DNS-Record in beiden Zonen identisch sein?\u003c/h3\u003e\n\u003cp\u003eNein. Identisch sollten fachliche Identität und gewünschter Veröffentlichungsstatus sein. Zieladresse, TTL und Routing dürfen sich unterscheiden, wenn die unterschiedlichen Netzwerkpfade bewusst vorgesehen und dokumentiert sind.\u003c/p\u003e\n\u003ch3 id=\"wann-ist-eine-vollständige-zonensynchronisierung-sinnvoll\"\u003eWann ist eine vollständige Zonensynchronisierung sinnvoll?\u003c/h3\u003e\n\u003cp\u003eNur bei Zonen mit tatsächlich gleicher Sichtbarkeit und Verantwortlichkeit. Bei Split-Horizon-DNS ist eine selektive Synchronisierung sicherer, weil sie private Ziele und interne Infrastruktur nicht versehentlich veröffentlicht.\u003c/p\u003e\n\u003ch3 id=\"wer-sollte-änderungen-an-gemeinsamen-dns-daten-freigeben\"\u003eWer sollte Änderungen an gemeinsamen DNS-Daten freigeben?\u003c/h3\u003e\n\u003cp\u003eDas hängt von der Organisation ab. Bewährt hat sich eine gemeinsame fachliche Quelle mit klaren Zuständigkeiten für Plattform, Netzwerk und Anwendung. Automatisierung verteilt Änderungen, ersetzt aber keine Freigaberegeln.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eDNS-Zonen synchronisieren heißt im professionellen Betrieb, gemeinsame Serviceinformationen konsistent zu halten und unterschiedliche Sichtbarkeiten bewusst abzubilden. Internal Zone und External Zone brauchen deshalb klare Grenzen, nicht zwingend identische Records. Ein zentral beschriebenes Datenmodell, überprüfbare Änderungsprozesse und der Schutz interner Ziele verhindern viele Namensauflösungs- und Sicherheitsprobleme. Die ayedo Edge Cloud kann dabei die öffentliche DNS- und Traffic-Schicht bilden, während interne Auflösung und Compute unabhängig organisiert bleiben.\u003c/p\u003e\n",
      "summary": "\nTL;DR DNS-Zonen zu synchronisieren bedeutet nicht, interne und externe Einträge vollständig zu kopieren. Entscheidend ist ein kontrolliertes gemeinsames Datenmodell: Welche Services sind öffentlich, welche bleiben intern, welche Ziele ändern sich und wer darf Änderungen auslösen? Mit klarer Zuständigkeit, definierten Synchronisierungsregeln und getrennten Sichtbarkeiten bleibt DNS konsistent, ohne interne Infrastruktur offenzulegen.\nEinleitung Viele DNS-Probleme entstehen nicht durch einen einzelnen fehlerhaften Record, sondern durch widersprüchliche Änderungen in mehreren Zonenwelten. Ein Service wird intern auf einen neuen Endpoint umgestellt, während die External Zone weiterhin auf das alte Ziel verweist. Oder ein öffentlich erreichbarer Name wird in der Internal Zone anders geschrieben als in der externen Zone. Solche Abweichungen führen zu schwer reproduzierbaren Fehlern: Anwendungen funktionieren aus dem Firmennetz, externe Clients erhalten andere Antworten, und Betriebsteams suchen an den falschen Stellen. DNS-Zonen synchronisieren ist deshalb vor allem eine Frage von Zuständigkeit, Sichtbarkeit und Änderungsprozessen – nicht von möglichst vollständiger Duplizierung.\n",
      "image": "https://ayedo.de/interne-und-externe-dns-zonen-synchron-halten-im-betrieb.png",
      "date_published": "2026-09-02T14:04:53Z",
      "date_modified": "2026-09-02T14:04:53Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["operations","kubernetes","cloud-native","digital-sovereignty","software-delivery"],
      "language": "de"
    },{
      "id": "https://ayedo.de/posts/internal-und-external-zones-zentral-verwalten-mit-dnssec/",
      "url": "https://ayedo.de/posts/internal-und-external-zones-zentral-verwalten-mit-dnssec/",
      "title": "Internal und External Zones zentral verwalten mit DNSSEC",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/internal-und-external-zones-zentral-verwalten-mit-dnssec/internal-und-external-zones-zentral-verwalten-mit-dnssec.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eInternal und External Zones sollten organisatorisch und technisch getrennt behandelt werden, auch wenn sie zu derselben DNS-Domäne gehören. Ein klares Zonenmodell definiert Verantwortlichkeiten, reduziert Fehlkonfigurationen und erleichtert \u003ca href=\"/compliance/\"\u003eDNSSEC\u003c/a\u003e\n. Eine zentrale Verwaltung in der ayedo Edge Cloud kann autoritative DNS-Prozesse bündeln, ohne interne Namensräume öffentlich bereitzustellen.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eViele DNS-Probleme entstehen nicht durch fehlende Technologie, sondern durch unklare Zuständigkeiten. Werden interne und öffentliche Namensräume in einer gemeinsamen Zone gepflegt, können Änderungen für Anwendungen, Security und Betrieb schwer nachvollziehbar werden. Eine Trennung in Internal und External Zones schafft dagegen klare Verantwortungsgrenzen: Interne Einträge bleiben auf private Auflösung beschränkt, öffentliche Records werden ausschließlich über autoritative externe DNS-Dienste veröffentlicht. Diese Trennung muss jedoch mit einem konsistenten Zonenmodell, abgestimmten Änderungsprozessen und einer belastbaren \u003ca href=\"/compliance/\"\u003eDNSSEC\u003c/a\u003e\n-Strategie umgesetzt werden. Sonst entsteht statt mehr Kontrolle lediglich ein zweites, widersprüchliches DNS-System.\u003c/p\u003e\n\u003ch2 id=\"1-internal-und-external-zones-beginnen-mit-dem-zonenmodell\"\u003e1. Internal und External Zones beginnen mit dem Zonenmodell\u003c/h2\u003e\n\u003cp\u003eEine DNS-Zone ist nicht automatisch gleichbedeutend mit einer gesamten Domäne. Für eine Domäne wie \u003ccode\u003eexample.com\u003c/code\u003e kann es eine externe autoritative Zone für öffentlich erreichbare Services und getrennte interne Zonen für private Anwendungen, Cluster oder Verwaltungsdienste geben. Entscheidend ist, welche Namen von welchen Resolvern beantwortet werden dürfen und welche Organisationseinheit für die Inhalte verantwortlich ist.\u003c/p\u003e\n\u003cp\u003eEin mögliches Modell trennt beispielsweise \u003ccode\u003eexample.com\u003c/code\u003e als öffentliche Zone von \u003ccode\u003ecorp.example.com\u003c/code\u003e oder \u003ccode\u003ecluster.example.com\u003c/code\u003e als internen Namensräumen. Alternativ kann eine Split-Horizon-DNS-Architektur denselben Namen intern und extern unterschiedlich auflösen. Dieser Ansatz ist leistungsfähig, erhöht aber die Anforderungen an Dokumentation, Tests und Change Management.\u003c/p\u003e\n\u003cp\u003eDie Trennung ist nicht nur eine Frage der DNS-Konfiguration. Sie definiert auch Security-Grenzen: Ein interner Backend-Name darf nicht versehentlich in einer öffentlichen Zone auftauchen. Gleichzeitig muss feststehen, wer Records anlegt, Freigaben erteilt und Änderungen nachvollzieht. Ohne diese Verantwortungsgrenzen bleibt zentrale DNS-Zonenverwaltung organisatorisch unvollständig.\u003c/p\u003e\n\u003ch2 id=\"2-zentrale-verwaltung-bündelt-zuständigkeiten-nicht-namensräume\"\u003e2. Zentrale Verwaltung bündelt Zuständigkeiten, nicht Namensräume\u003c/h2\u003e\n\u003cp\u003eZentrale DNS-Zonenverwaltung bedeutet nicht, dass alle Zonen technisch gleich behandelt oder in einer gemeinsamen Zone zusammengeführt werden. Sie bedeutet, dass Regeln, Zuständigkeiten und autoritative Dienste an einer kontrollierten Stelle organisiert werden. Internal und External Zones bleiben dabei logisch getrennt und können unterschiedlichen Zugriffspfaden, Delegationen und Freigabeprozessen folgen.\u003c/p\u003e\n\u003cp\u003eIn der ayedo Edge Cloud lässt sich die Verwaltung autoritativer DNS-Zonen zentral an der Edge organisieren. Anycast DNS und Multi-Provider-DNS sind dabei für öffentliche Namensauflösung und Ausfallszenarien relevant. Die Edge Cloud bildet den öffentlichen Eingang zu Anwendungen und APIs; interne Zonen müssen deshalb nicht automatisch öffentlich über diese Ebene publiziert werden. Für private Namensräume bleiben interne Resolver und deren Zugriffskontrollen zuständig.\u003c/p\u003e\n\u003cp\u003eWichtig ist die klare Trennung zwischen Zone und Dienst: Ein öffentlicher DNS-Record kann auf einen über die Edge erreichbaren Service zeigen, während interne Service-Namen ausschließlich innerhalb des Unternehmens oder Clusters aufgelöst werden. Diese Struktur erleichtert Audits, reduziert unbeabsichtigte Veröffentlichungen und verhindert, dass Backend-Informationen über öffentliche DNS-Antworten sichtbar werden.\u003c/p\u003e\n\u003ch2 id=\"3-dnssec-muss-pro-zone-und-vertrauenskette-geplant-werden\"\u003e3. \u003ca href=\"/compliance/\"\u003eDNSSEC\u003c/a\u003e\n muss pro Zone und Vertrauenskette geplant werden\u003c/h2\u003e\n\u003cp\u003eDNSSEC schützt DNS-Antworten vor Manipulation, indem Signaturen die Authentizität und Integrität von Records prüfbar machen. Die technische Herausforderung liegt nicht allein im Signieren der Zone. Entscheidend ist eine vollständige Vertrauenskette vom Trust Anchor über den DS-Record der übergeordneten Zone bis zum DNSKEY- und RRSIG-Satz der untergeordneten Zone.\u003c/p\u003e\n\u003cp\u003eBei External Zones ist diese Kette besonders relevant, weil öffentliche Resolver DNSSEC-Validierung durchführen können. Änderungen an Delegationen, Key Rollovers oder Providerwechseln müssen deshalb mit der DS-Konfiguration abgestimmt werden. Ein veralteter DS-Record kann eine ansonsten korrekt signierte Zone für Validierer unerreichbar machen.\u003c/p\u003e\n\u003cp\u003eFür Internal Zones hängt die [DNSSEC]-Strategie von der Resolver-Landschaft und den Sicherheitsanforderungen ab. Auch interne Zonen können signiert werden, müssen dann aber von den zuständigen Resolvern validiert werden können. Bei Split Horizon sind interne und externe Versionen derselben Zone getrennt zu betrachten. Schlüsselmaterial, Signaturprozesse und Delegationen dürfen nicht unkontrolliert zwischen beiden Ebenen vermischt werden. Die zentrale Verwaltung sollte daher DNSSEC-Zuständigkeiten sichtbar machen, nicht deren technische Unterschiede verschleiern.\u003c/p\u003e\n\u003ch2 id=\"4-betrieb-und-verantwortlichkeiten-entscheiden-über-konsistenz\"\u003e4. Betrieb und Verantwortlichkeiten entscheiden über Konsistenz\u003c/h2\u003e\n\u003cp\u003eEin robustes Zonenmodell braucht verbindliche Betriebsprozesse. Dazu gehören eine Zone Ownership, definierte Freigaben für kritische Records, getrennte Berechtigungen für Internal und External Zones sowie automatisierte Prüfungen gegen unerwünschte Veröffentlichungen. Besonders relevant sind Änderungen an NS-, CNAME-, MX-, TXT- und DS-Records, weil sie Delegation, E-Mail-Zustellung, Verifikation oder DNSSEC-Vertrauen beeinflussen können.\u003c/p\u003e\n\u003cp\u003eAuch die Ausfallplanung muss zum Zonenmodell passen. Öffentliche Zonen können über Anycast DNS und Multi-Provider-DNS verteilt und redundant bereitgestellt werden. Interne Zonen benötigen dagegen Resolver- und Netzwerkpfade, die für private Nutzer, Standorte oder Cluster erreichbar sind. Ein gemeinsames Änderungsfenster darf diese Bereiche nicht zwangsläufig koppeln.\u003c/p\u003e\n\u003cp\u003eFür Unternehmen entsteht daraus ein wirtschaftlicher Effekt: Klare Grenzen senken das Risiko falsch gerouteter Anfragen, vermeidbarer Ausfälle und aufwendiger manueller Korrekturen. Eine zentrale Plattform wie die ayedo Edge Cloud kann öffentliche autoritative DNS-Funktionen bündeln. Sie ersetzt jedoch nicht die fachliche Entscheidung, welche Zone intern bleibt, wer sie betreibt und wie \u003ca href=\"/compliance/\"\u003eDNSSEC\u003c/a\u003e\n dafür validiert wird.\u003c/p\u003e\n\u003ch2 id=\"praxis--und-betriebsszenario\"\u003ePraxis- und Betriebsszenario\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt eine öffentliche API unter \u003ccode\u003eapi.example.com\u003c/code\u003e und interne Backends unter \u003ccode\u003epayments.corp.example.com\u003c/code\u003e. Die External Zone enthält ausschließlich öffentlich notwendige Records und wird zentral über autoritatives DNS verwaltet. Die Internal Zone wird von internen Resolvern beantwortet und enthält private Adressen sowie Service-Namen. Der API-Endpunkt zeigt auf die Edge, während Backend Cloaking verhindert, dass die eigentlichen Backend-Adressen öffentlich benötigt werden.\u003c/p\u003e\n\u003cp\u003eBei \u003ca href=\"/compliance/\"\u003eDNSSEC\u003c/a\u003e\n wird die External Zone signiert und ihre DS-Verknüpfung mit der übergeordneten Zone kontrolliert. Für die Internal Zone entscheidet das Unternehmen abhängig von Resolvern und Sicherheitsmodell über Signierung und Validierung. Ein gemeinsamer Zonenbestand wäre hier unnötig riskant: Ein interner Record könnte versehentlich veröffentlicht werden, während ein externer DNSSEC-Fehler den öffentlichen API-Zugriff beeinträchtigt.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"sind-internal-und-external-zones-immer-getrennte-dns-domänen\"\u003eSind Internal und External Zones immer getrennte DNS-Domänen?\u003c/h3\u003e\n\u003cp\u003eNein. Sie können unter derselben übergeordneten Domäne liegen. Entscheidend sind getrennte Zonen, Resolver-Pfade, Berechtigungen und Veröffentlichungsregeln.\u003c/p\u003e\n\u003ch3 id=\"muss-jede-internal-zone-mit-dnssec-signiert-werden\"\u003eMuss jede Internal Zone mit \u003ca href=\"/compliance/\"\u003eDNSSEC\u003c/a\u003e\n signiert werden?\u003c/h3\u003e\n\u003cp\u003eNicht zwingend. Maßgeblich sind das interne Bedrohungsmodell, die eingesetzten Resolver und die Fähigkeit zur DNSSEC-Validierung. Die Entscheidung sollte dokumentiert und getestet werden.\u003c/p\u003e\n\u003ch3 id=\"welche-rolle-spielt-die-ayedo-edge-cloud\"\u003eWelche Rolle spielt die ayedo Edge Cloud?\u003c/h3\u003e\n\u003cp\u003eSie kann öffentliche autoritative DNS-Funktionen zentral organisieren. Interne Namensräume bleiben davon logisch getrennt und müssen nicht öffentlich über die Edge aufgelöst werden.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eInternal und External Zones sind vor allem ein Modell für Verantwortungsgrenzen. Die technische Trennung schützt interne Namen, vereinfacht Freigaben und macht \u003ca href=\"/compliance/\"\u003eDNSSEC\u003c/a\u003e\n planbar. Zentrale DNS-Zonenverwaltung ist dann sinnvoll, wenn sie unterschiedliche Sicherheits- und Betriebsanforderungen abbildet, statt sie zu vereinheitlichen. Die ayedo Edge Cloud unterstützt diesen Ansatz für öffentliche autoritative DNS-Strukturen mit Anycast DNS und Multi-Provider-DNS, während interne Auflösung und ihre Validierung im jeweiligen privaten Betriebsmodell verbleiben.\u003c/p\u003e\n",
      "summary": "\nTL;DR Internal und External Zones sollten organisatorisch und technisch getrennt behandelt werden, auch wenn sie zu derselben DNS-Domäne gehören. Ein klares Zonenmodell definiert Verantwortlichkeiten, reduziert Fehlkonfigurationen und erleichtert DNSSEC . Eine zentrale Verwaltung in der ayedo Edge Cloud kann autoritative DNS-Prozesse bündeln, ohne interne Namensräume öffentlich bereitzustellen.\nEinleitung Viele DNS-Probleme entstehen nicht durch fehlende Technologie, sondern durch unklare Zuständigkeiten. Werden interne und öffentliche Namensräume in einer gemeinsamen Zone gepflegt, können Änderungen für Anwendungen, Security und Betrieb schwer nachvollziehbar werden. Eine Trennung in Internal und External Zones schafft dagegen klare Verantwortungsgrenzen: Interne Einträge bleiben auf private Auflösung beschränkt, öffentliche Records werden ausschließlich über autoritative externe DNS-Dienste veröffentlicht. Diese Trennung muss jedoch mit einem konsistenten Zonenmodell, abgestimmten Änderungsprozessen und einer belastbaren DNSSEC -Strategie umgesetzt werden. Sonst entsteht statt mehr Kontrolle lediglich ein zweites, widersprüchliches DNS-System.\n",
      "image": "https://ayedo.de/internal-und-external-zones-zentral-verwalten-mit-dnssec.png",
      "date_published": "2026-09-02T14:04:52Z",
      "date_modified": "2026-09-02T14:04:52Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["security","kubernetes","cloud-native","digital-sovereignty","software-delivery"],
      "language": "de"
    },{
      "id": "https://ayedo.de/posts/multi-provider-dns-fur-robuste-autoritative-zonen/",
      "url": "https://ayedo.de/posts/multi-provider-dns-fur-robuste-autoritative-zonen/",
      "title": "Multi-Provider-DNS für robuste autoritative Zonen",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/multi-provider-dns-fur-robuste-autoritative-zonen/multi-provider-dns-fur-robuste-autoritative-zonen.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eMulti-Provider-DNS verteilt die Verantwortung für autoritative DNS-Zonen auf mehrere unabhängige Anbieter. Das erhöht die DNS-Ausfallsicherheit, erzeugt aber zusätzliche Anforderungen an Delegation, Zonenkonsistenz, Änderungen und Monitoring. Eine zentrale Steuerung muss deshalb nicht alle DNS-Server ersetzen, sondern vor allem Zuständigkeiten und Konfigurationen kontrollierbar machen.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eEin einzelner autoritativer DNS-Anbieter ist einfach zu betreiben, konzentriert aber Verfügbarkeit, Routing und Änderungsprozesse in einer Abhängigkeit. Fällt diese Ebene aus oder ist eine Zone fehlerhaft konfiguriert, kann die Anwendung trotz verfügbarer Backends nicht mehr zuverlässig gefunden werden. Multi-Provider-DNS adressiert dieses Risiko, indem eine autoritative External Zone bei mehreren DNS-Providern betrieben wird. Damit entsteht jedoch kein automatischer Sicherheitsgewinn: Unterschiedliche Zonenversionen, unklare Zuständigkeiten oder fehlerhafte Delegationen können die Ausfallsicherheit sogar beeinträchtigen. Entscheidend ist daher eine Architektur mit klarer Ownership, kontrollierter Synchronisation und einem belastbaren Betriebsmodell.\u003c/p\u003e\n\u003ch2 id=\"1-einzelner-dns-provider-einfache-zuständigkeit-konzentriertes-risiko\"\u003e1. Einzelner DNS-Provider: einfache Zuständigkeit, konzentriertes Risiko\u003c/h2\u003e\n\u003cp\u003eBei einem einzelnen autoritativen DNS-Provider liegen Zonendaten, Nameserver-Infrastruktur und Änderungsprozesse in einer gemeinsamen administrativen Domäne. Das vereinfacht die Konfiguration: Ein Record wird geändert, die Zone erhält eine neue Version, und die autoritativen Nameserver des Providers veröffentlichen diese Information. Monitoring und Incident Response können sich auf einen Betreiber konzentrieren.\u003c/p\u003e\n\u003cp\u003eDiese Einfachheit ist zugleich die zentrale Schwachstelle. Ein Ausfall des Providers, eine Störung seiner Netzwerk-Infrastruktur oder ein Fehler in der Zonenauslieferung betrifft die gesamte autoritative Ebene. Caching Resolver können Antworten abhängig von ihrem TTL noch eine Zeit lang verwenden; bei neuen Abfragen oder abgelaufenen Einträgen ist die Erreichbarkeit der autoritativen Server jedoch entscheidend.\u003c/p\u003e\n\u003cp\u003eAuch organisatorisch entsteht eine Abhängigkeit. Änderungen an DNS-Zonen, Eskalationswege und Wiederanlaufverfahren sind an einen Provider gebunden. Für kritische External Zones kann das akzeptabel sein, wenn die Abhängigkeit bewusst bewertet, überwacht und vertraglich abgesichert wird. Sie sollte aber nicht als inhärent robuste Architektur gelten.\u003c/p\u003e\n\u003ch2 id=\"2-multi-provider-dns-redundanz-durch-getrennte-verantwortungsbereiche\"\u003e2. Multi-Provider-DNS: Redundanz durch getrennte Verantwortungsbereiche\u003c/h2\u003e\n\u003cp\u003eBei Multi-Provider-DNS werden autoritative Nameserver mindestens zweier unabhängiger DNS-Provider in der Delegation einer Domain hinterlegt. Resolver können dadurch auf einen anderen Provider ausweichen, wenn ein Teil der autoritativen Infrastruktur nicht antwortet. Die DNS-Ausfallsicherheit steigt, weil nicht mehr eine einzelne Provider-Infrastruktur den gesamten autoritativen Dienst bestimmt.\u003c/p\u003e\n\u003cp\u003eDie Redundanz funktioniert nur, wenn die Provider tatsächlich unabhängige Fehlerdomänen bilden. Zwei DNS-Angebote, die auf derselben zugrunde liegenden Infrastruktur oder denselben Netzwerkabhängigkeiten basieren, reduzieren das gemeinsame Ausfallrisiko weniger als zwei getrennte Betreiber. Zusätzlich muss die Delegation vollständig und korrekt sein: Nameserver, Glue Records bei relevanten Delegationssituationen und autoritative Antworten müssen zusammenpassen.\u003c/p\u003e\n\u003cp\u003eMit der Verteilung entstehen neue Zuständigkeiten. Jeder Provider verantwortet die Verfügbarkeit seiner Nameserver, während der Betreiber der Zone für fachlich korrekte und konsistente Zonendaten verantwortlich bleibt. Diese Trennung muss dokumentiert werden. Sonst ist im Incident unklar, ob ein Fehler aus der Delegation, einer einzelnen Provider-Zone oder der zentralen Änderungssteuerung stammt.\u003c/p\u003e\n\u003ch2 id=\"3-zentrale-steuerung-und-zonenkonsistenz\"\u003e3. Zentrale Steuerung und Zonenkonsistenz\u003c/h2\u003e\n\u003cp\u003eEine Multi-Provider-Architektur braucht eine zentrale Sicht auf die autoritative External Zone. Das bedeutet nicht zwingend, dass alle Provider technisch identisch arbeiten. Entscheidend ist, dass Änderungen an Records, TTLs und weiteren Zoneneigenschaften aus einem kontrollierten Prozess heraus erfolgen und anschließend bei allen autoritativen Providern wirksam werden.\u003c/p\u003e\n\u003cp\u003eBesonders kritisch ist die Konsistenz. Weichen A- oder AAAA-Records, CNAMEs, MX-Einträge oder TTL-Werte zwischen Providern ab, erhalten Resolver abhängig vom ausgewählten Nameserver unterschiedliche Antworten. Das kann zu partieller Erreichbarkeit, schwer reproduzierbaren Fehlern oder inkonsistentem Failover führen. Eine scheinbar verfügbare Zone ist dann fachlich nicht zuverlässig.\u003c/p\u003e\n\u003cp\u003eDie Steuerung sollte deshalb Änderungen versionieren, Verantwortlichkeiten abbilden und die erfolgreiche Veröffentlichung bei jedem Provider prüfen. Monitoring muss sowohl die Erreichbarkeit als auch den Inhalt autoritativer Antworten testen. Ein Provider kann technisch erreichbar sein und trotzdem veraltete oder fehlerhafte Daten liefern. DNS-Ausfallsicherheit ist daher nicht nur eine Frage von Nameserver-Uptime, sondern auch von Datenintegrität und Änderungsprozessen.\u003c/p\u003e\n\u003ch2 id=\"4-einordnung-der-ayedo-edge-cloud\"\u003e4. Einordnung der ayedo Edge Cloud\u003c/h2\u003e\n\u003cp\u003eDie ayedo Edge Cloud unterstützt mit Anycast DNS und Multi-Provider-DNS eine Architektur, in der autoritative DNS-Funktionen providerübergreifend organisiert werden können. Relevant ist das insbesondere für External Zones, deren DNS nicht an einen einzelnen Infrastruktur- oder Cloud-Provider gebunden sein soll. Die Edge Cloud bildet dabei nicht nur eine DNS-Schicht, sondern eine öffentliche Edge für Anwendungen und APIs mit Routing-, Schutz- und Verteilungsfunktionen.\u003c/p\u003e\n\u003cp\u003eFür die Architekturplanung ist die Trennung der Verantwortungsbereiche entscheidend: DNS beantwortet die Frage, wie ein Dienst gefunden wird; die Edge Cloud verarbeitet anschließend den eingehenden Traffic und kann ihn zu geeigneten Backends weiterleiten. Backend Cloaking verhindert dabei, dass interne Zielsysteme als öffentliche Einstiegspunkte sichtbar sein müssen.\u003c/p\u003e\n\u003cp\u003eDie Nutzung ist nicht auf ayedo Managed \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n beschränkt. Eine autoritative DNS-Architektur kann ebenso vor eigenen Kubernetes-Clustern oder Workloads bei anderen Providern eingesetzt werden. Das eigene Autonomous System und die eigene Netzwerk-Infrastruktur der ayedo Edge Cloud sind dabei Teil einer providerübergreifenden Edge-Architektur, nicht bloß ein zusätzlicher Loadbalancer vor einem einzelnen Cluster.\u003c/p\u003e\n\u003ch2 id=\"praxisszenario-external-zone-mit-zwei-autoritativen-providern\"\u003ePraxisszenario: External Zone mit zwei autoritativen Providern\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt eine öffentliche API in mehreren Umgebungen. Die Anwendung liegt teilweise in einem eigenen Kubernetes-Cluster und teilweise bei einem externen Cloud-Provider. Die External Zone soll nicht von der DNS-Verfügbarkeit eines einzelnen Providers abhängen.\u003c/p\u003e\n\u003cp\u003eDie Delegation verweist deshalb auf Nameserver zweier unabhängiger DNS-Anbieter. Eine zentrale Änderungssteuerung veröffentlicht die fachlich definierte Zone bei beiden Providern. Nach jeder Änderung prüfen automatisierte Tests SOA-Informationen und wichtige Service-Records gegen alle autoritativen Quellen. Die ayedo Edge Cloud übernimmt anschließend Anycast DNS sowie den öffentlichen Eingang vor den APIs. Fällt ein DNS-Provider aus, können Resolver weiterhin die autoritativen Server des anderen erreichen. Fällt dagegen nur ein Backend aus, greifen Health Checks und Failover auf der Edge-Ebene. DNS- und Anwendungsfailover bleiben damit getrennte, überprüfbare Mechanismen.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"ist-multi-provider-dns-dasselbe-wie-dns-failover\"\u003eIst Multi-Provider-DNS dasselbe wie DNS-Failover?\u003c/h3\u003e\n\u003cp\u003eNein. Multi-Provider-DNS redundiert die autoritativen Nameserver. DNS-Failover verändert abhängig vom Zustand eines Dienstes Antworten oder Ziele. Beide Mechanismen können kombiniert werden, lösen aber unterschiedliche Probleme.\u003c/p\u003e\n\u003ch3 id=\"müssen-alle-provider-identische-dns-technologien-verwenden\"\u003eMüssen alle Provider identische DNS-Technologien verwenden?\u003c/h3\u003e\n\u003cp\u003eNein. Sie müssen jedoch die erforderlichen autoritativen Funktionen, Delegationen und Zonendaten konsistent bereitstellen. Unterschiedliche Betriebsmodelle erhöhen den Prüf- und Dokumentationsaufwand.\u003c/p\u003e\n\u003ch3 id=\"wann-reicht-ein-einzelner-dns-provider-aus\"\u003eWann reicht ein einzelner DNS-Provider aus?\u003c/h3\u003e\n\u003cp\u003eWenn die Abhängigkeit bewusst akzeptiert wird, die Verfügbarkeit angemessen überwacht ist und Wiederanlaufprozesse belastbar sind. Multi-Provider-DNS ist kein Standardzwang, sondern eine Entscheidung für zusätzliche Unabhängigkeit.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eMulti-Provider-DNS erhöht die DNS-Ausfallsicherheit nicht allein durch mehrere Nameserver. Der entscheidende Aufwand liegt in sauberer Delegation, konsistenter Zonenauslieferung, unabhängigen Fehlerdomänen und klarer Betriebsverantwortung. Die ayedo Edge Cloud ordnet diese DNS-Funktion in eine umfassendere Edge-Architektur mit Anycast, Traffic-Verteilung und Schutz der Backends ein. Für Unternehmen entsteht daraus ein providerübergreifender öffentlicher Einstieg, der DNS- und Anwendungsbetrieb technisch getrennt, aber zusammenhängend steuerbar macht.\u003c/p\u003e\n",
      "summary": "\nTL;DR Multi-Provider-DNS verteilt die Verantwortung für autoritative DNS-Zonen auf mehrere unabhängige Anbieter. Das erhöht die DNS-Ausfallsicherheit, erzeugt aber zusätzliche Anforderungen an Delegation, Zonenkonsistenz, Änderungen und Monitoring. Eine zentrale Steuerung muss deshalb nicht alle DNS-Server ersetzen, sondern vor allem Zuständigkeiten und Konfigurationen kontrollierbar machen.\nEinleitung Ein einzelner autoritativer DNS-Anbieter ist einfach zu betreiben, konzentriert aber Verfügbarkeit, Routing und Änderungsprozesse in einer Abhängigkeit. Fällt diese Ebene aus oder ist eine Zone fehlerhaft konfiguriert, kann die Anwendung trotz verfügbarer Backends nicht mehr zuverlässig gefunden werden. Multi-Provider-DNS adressiert dieses Risiko, indem eine autoritative External Zone bei mehreren DNS-Providern betrieben wird. Damit entsteht jedoch kein automatischer Sicherheitsgewinn: Unterschiedliche Zonenversionen, unklare Zuständigkeiten oder fehlerhafte Delegationen können die Ausfallsicherheit sogar beeinträchtigen. Entscheidend ist daher eine Architektur mit klarer Ownership, kontrollierter Synchronisation und einem belastbaren Betriebsmodell.\n",
      "image": "https://ayedo.de/multi-provider-dns-fur-robuste-autoritative-zonen.png",
      "date_published": "2026-09-02T14:04:52Z",
      "date_modified": "2026-09-02T14:04:52Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["operations","security","kubernetes","hosting","cloud-native"],
      "language": "de"
    },{
      "id": "https://ayedo.de/posts/autoritative-dns-zonen-zwischen-intern-und-extern-trennen/",
      "url": "https://ayedo.de/posts/autoritative-dns-zonen-zwischen-intern-und-extern-trennen/",
      "title": "Autoritative DNS-Zonen zwischen intern und extern trennen",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/autoritative-dns-zonen-zwischen-intern-und-extern-trennen/autoritative-dns-zonen-zwischen-intern-und-extern-trennen.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eEin belastbares DNS-Namenskonzept trennt interne Auflösung von öffentlich autoritativen Edge-Diensten. Internal und External DNS Zones haben unterschiedliche Sichtbarkeiten, Auflösungswege und Sicherheitsgrenzen. Statt Zonen nachträglich zu synchronisieren, sollten Unternehmen Namensräume, Verantwortlichkeiten und Datenflüsse frühzeitig getrennt definieren.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eDer häufigste Fehler bei der DNS-Architektur ist nicht ein falscher Record, sondern ein unklarer Verantwortungsbereich. Wenn interne Service-Namen, administrative Endpunkte und öffentliche Anwendungen in derselben autoritativen Zone liegen, wird jede Änderung zur Sicherheits- und Betriebsfrage. Ein interner Name kann versehentlich öffentlich sichtbar werden; ein öffentlicher Record kann von internen Resolvern über einen unerwarteten Weg beantwortet werden. Die zentrale Architekturentscheidung lautet deshalb: Welche Zone ist intern maßgeblich, welche Zone wird für öffentliche Edge-Dienste autoritativ bereitgestellt – und wo verlaufen die DNS-Sicherheitsgrenzen?\u003c/p\u003e\n\u003ch2 id=\"1-namensräume-nach-sichtbarkeit-statt-nach-organisation-schneiden\"\u003e1. Namensräume nach Sichtbarkeit statt nach Organisation schneiden\u003c/h2\u003e\n\u003cp\u003eInternal DNS Zones und External DNS Zones sollten nicht lediglich unterschiedliche Ansichten derselben Datenbank sein. Sie erfüllen unterschiedliche Aufgaben. Eine interne Zone enthält beispielsweise Namen für Cluster-Endpunkte, private Backends, Verwaltungsdienste oder Service Discovery. Diese Informationen benötigen interne Resolver und sollen nicht Teil der öffentlichen DNS-Antworten sein.\u003c/p\u003e\n\u003cp\u003eExternal Zones enthalten dagegen Namen, die aus dem Internet auflösbar sein müssen. Dazu gehören etwa öffentliche Webanwendungen, APIs oder Mail- und Verifikations-Records. Für diese Namen ist ein öffentlich autoritativer Dienst zuständig, der Anfragen unabhängig von internen Resolvern beantworten kann.\u003c/p\u003e\n\u003cp\u003eEin sauberes DNS-Namenskonzept trennt daher nicht nur Records, sondern möglichst auch Domänen oder Subdomänen. \u003ccode\u003eapi.example.com\u003c/code\u003e kann öffentlich auf die Edge zeigen, während \u003ccode\u003eapi.internal.example.com\u003c/code\u003e ausschließlich intern auflösbar ist. Die Namensgebung transportiert damit eine technische Eigenschaft: Sichtbarkeit und Zuständigkeit.\u003c/p\u003e\n\u003ch2 id=\"2-auflösungswege-als-sicherheitsgrenze-definieren\"\u003e2. Auflösungswege als Sicherheitsgrenze definieren\u003c/h2\u003e\n\u003cp\u003eSplit-Horizon-DNS wird problematisch, wenn es nur als Komfortfunktion für unterschiedliche Antworten verstanden wird. Entscheidend ist der Auflösungsweg. Interne Resolver sollten interne Zonen direkt oder über klar definierte Weiterleitungen erreichen. Öffentliche Resolver dürfen dagegen ausschließlich die External Zones sehen, die für Internetdienste bestimmt sind.\u003c/p\u003e\n\u003cp\u003eDiese Trennung reduziert das Risiko, dass interne Zieladressen, Hostnamen oder Infrastrukturinformationen nach außen gelangen. Sie verhindert zugleich, dass interne Clients für öffentliche Namen einen unnötigen Umweg über interne Spezialregeln nehmen. Ein öffentlicher Dienst sollte aus internen Netzen entweder über den vorgesehenen öffentlichen Namen und die Edge erreichbar sein oder über einen ausdrücklich definierten internen Namen. Beides ungeplant zu vermischen, erschwert Fehlersuche und Sicherheitsbewertung.\u003c/p\u003e\n\u003cp\u003eFür die ayedo Edge Cloud ist diese Unterscheidung relevant, weil Anycast DNS und Multi-Provider-DNS den öffentlichen autoritativen Pfad bilden können. Die External Zone stellt dabei die Namen für öffentliche Edge-Dienste bereit. Interne Zonen bleiben in der eigenen DNS-Verantwortung und werden nicht automatisch Bestandteil dieses öffentlichen Namensraums.\u003c/p\u003e\n\u003ch2 id=\"3-autoritative-daten-bewusst-zuordnen\"\u003e3. Autoritative Daten bewusst zuordnen\u003c/h2\u003e\n\u003cp\u003eDie Frage „Welche Zone enthält den Record?“ sollte durch eine Zuständigkeitsentscheidung beantwortet werden, nicht durch technische Bequemlichkeit. Records für öffentliche Services gehören in die External Zone, wenn ihre Auflösung zur Erreichbarkeit über die Edge erforderlich ist. Dazu zählen beispielsweise Namen, die auf öffentliche Anycast-Endpunkte zeigen oder für TLS- und Domainvalidierung benötigt werden.\u003c/p\u003e\n\u003cp\u003eInterne Backend-Namen, private Adressen und clusterinterne Service-Namen gehören dagegen in Internal Zones. Sie werden nicht veröffentlicht, nur weil ein öffentlicher Dienst technisch auf sie zugreift. Die Edge Cloud benötigt für die externe Erreichbarkeit nicht zwangsläufig die interne Namensstruktur. Backend Cloaking unterstützt genau diese Entkopplung: Der öffentliche DNS-Name verweist auf die Edge, während die eigentliche Backend-Topologie verborgen bleibt.\u003c/p\u003e\n\u003cp\u003eWichtig ist außerdem, Änderungen nicht über eine nachträgliche Synchronisierung beider Zonen zu organisieren. Synchronisierung kann divergierende Zustände, unklare Löschverantwortung und unbeabsichtigte Veröffentlichungen erzeugen. Besser ist eine eindeutige Quelle pro Record-Kategorie und ein klarer Übergang zwischen öffentlichem Frontend und internem Backend.\u003c/p\u003e\n\u003ch2 id=\"4-betrieb-und-governance-an-der-zonengrenze\"\u003e4. Betrieb und Governance an der Zonengrenze\u003c/h2\u003e\n\u003cp\u003eDie Trennung der Zonen wirkt sich direkt auf den Betrieb aus. Für External Zones müssen TTLs, Failover-Verhalten, DNSSEC- oder Providerkonzepte und Änderungen an öffentlichen Services berücksichtigt werden. Interne Zonen folgen dagegen den Anforderungen von Plattformbetrieb, Service Discovery und privaten Netzwerken. Beide Bereiche haben unterschiedliche Änderungsfrequenzen und unterschiedliche Ausfallfolgen.\u003c/p\u003e\n\u003cp\u003eAuch Berechtigungen sollten an der Zonengrenze ausgerichtet werden. Ein Team, das einen öffentlichen API-Endpunkt betreibt, benötigt nicht automatisch Zugriff auf interne Infrastrukturzonen. Umgekehrt sollte ein Plattformteam interne Namen verwalten können, ohne öffentliche DNS-Änderungen direkt auszuführen. Diese Trennung verbessert Nachvollziehbarkeit und reduziert den Einfluss fehlerhafter Automatisierung.\u003c/p\u003e\n\u003cp\u003eBei mehreren DNS-Anbietern oder einer Edge-Plattform wie ayedo müssen außerdem die autoritativen Zuständigkeiten explizit dokumentiert sein. Multi-Provider-DNS kann die Verfügbarkeit des öffentlichen Pfads erhöhen; es ersetzt aber kein Namenskonzept. Die technische Redundanz ist nur dann belastbar, wenn alle beteiligten autoritativen Systeme dieselbe klar abgegrenzte External Zone bedienen.\u003c/p\u003e\n\u003ch2 id=\"praxisszenario-öffentliche-api-mit-privatem-backend\"\u003ePraxisszenario: Öffentliche API mit privatem Backend\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt eine API in einem \u003ca href=\"/kubernetes/\"\u003eKubernetes-Cluster\u003c/a\u003e\n bei einem externen Provider. Intern existieren Namen wie \u003ccode\u003eorders-api.cluster.internal.example.com\u003c/code\u003e und mehrere private Backend-Adressen. Öffentlich soll ausschließlich \u003ccode\u003eapi.example.com\u003c/code\u003e sichtbar sein.\u003c/p\u003e\n\u003cp\u003eIn der External Zone zeigt \u003ccode\u003eapi.example.com\u003c/code\u003e auf die ayedo Edge Cloud. Dort können TLS Termination, WAF, DDoS Protection und Loadbalancing erfolgen. Die Backend-Adresse und interne Namensstruktur werden nicht veröffentlicht. Interne Clients verwenden entweder ebenfalls den öffentlichen Namen über den vorgesehenen Edge-Pfad oder einen separaten internen Namen – abhängig von Routing- und Sicherheitsanforderungen. Entscheidend ist, dass beide Pfade bewusst modelliert werden. Ein automatisch synchronisierter Recordbestand wäre hier keine Vereinfachung, sondern eine zusätzliche Fehlerquelle.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"ist-split-horizon-dns-immer-erforderlich\"\u003eIst Split-Horizon-DNS immer erforderlich?\u003c/h3\u003e\n\u003cp\u003eNein. Separate Domänen oder Subdomänen sind oft einfacher. Split-Horizon-DNS ist sinnvoll, wenn derselbe Name abhängig vom Anfragekontext unterschiedliche Antworten benötigt.\u003c/p\u003e\n\u003ch3 id=\"gehören-backend-records-in-die-external-zone\"\u003eGehören Backend-Records in die External Zone?\u003c/h3\u003e\n\u003cp\u003eNein. Öffentlich erforderlich ist der Frontend-Name. Backend-Namen und private Adressen sollten in Internal Zones verbleiben und nicht aus der öffentlichen Zone ableitbar sein.\u003c/p\u003e\n\u003ch3 id=\"kann-die-edge-cloud-interne-dns-zonen-ersetzen\"\u003eKann die Edge Cloud interne DNS-Zonen ersetzen?\u003c/h3\u003e\n\u003cp\u003eNein. Die Edge Cloud stellt den öffentlichen DNS- und Traffic-Pfad bereit. Interne Namensauflösung, Service Discovery und private Zonen bleiben eine separate Architekturverantwortung.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eInternal und External DNS Zones sind keine bloßen Kopien mit unterschiedlichen Antworten, sondern getrennte Verantwortungsbereiche. Ein bewusstes DNS-Namenskonzept definiert Sichtbarkeit, Auflösungswege und Zuständigkeiten bereits vor dem Betrieb. Die ayedo Edge Cloud kann dabei den autoritativen öffentlichen Pfad für Edge-Dienste bilden, während interne Zonen und Backend-Namen abgeschirmt bleiben. So entstehen klarere Sicherheitsgrenzen, weniger Synchronisationsrisiken und besser kontrollierbare Betriebsprozesse.\u003c/p\u003e\n",
      "summary": "\nTL;DR Ein belastbares DNS-Namenskonzept trennt interne Auflösung von öffentlich autoritativen Edge-Diensten. Internal und External DNS Zones haben unterschiedliche Sichtbarkeiten, Auflösungswege und Sicherheitsgrenzen. Statt Zonen nachträglich zu synchronisieren, sollten Unternehmen Namensräume, Verantwortlichkeiten und Datenflüsse frühzeitig getrennt definieren.\nEinleitung Der häufigste Fehler bei der DNS-Architektur ist nicht ein falscher Record, sondern ein unklarer Verantwortungsbereich. Wenn interne Service-Namen, administrative Endpunkte und öffentliche Anwendungen in derselben autoritativen Zone liegen, wird jede Änderung zur Sicherheits- und Betriebsfrage. Ein interner Name kann versehentlich öffentlich sichtbar werden; ein öffentlicher Record kann von internen Resolvern über einen unerwarteten Weg beantwortet werden. Die zentrale Architekturentscheidung lautet deshalb: Welche Zone ist intern maßgeblich, welche Zone wird für öffentliche Edge-Dienste autoritativ bereitgestellt – und wo verlaufen die DNS-Sicherheitsgrenzen?\n",
      "image": "https://ayedo.de/autoritative-dns-zonen-zwischen-intern-und-extern-trennen.png",
      "date_published": "2026-09-02T14:04:43Z",
      "date_modified": "2026-09-02T14:04:43Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["security","development","kubernetes","cloud-native","digital-sovereignty"],
      "language": "de"
    },{
      "id": "https://ayedo.de/posts/kubernetes-dns-und-externe-zonen-sauber-zusammendenken/",
      "url": "https://ayedo.de/posts/kubernetes-dns-und-externe-zonen-sauber-zusammendenken/",
      "title": "Kubernetes-DNS und externe Zonen sauber zusammendenken",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/kubernetes-dns-und-externe-zonen-sauber-zusammendenken/kubernetes-dns-und-externe-zonen-sauber-zusammendenken.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eKubernetes-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.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eEin häufiger Architekturfehler besteht darin, interne \u003ca href=\"https://kubernetes/\" target=\"_blank\" rel=\"noopener\"\u003eKubernetes\u003c/a\u003e\n Namen und öffentliche Anwendungsdomains als zwei Varianten desselben DNS-Problems zu behandeln. \u003ccode\u003eService\u003c/code\u003e-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.\u003c/p\u003e\n\u003ch2 id=\"1-kubernetes-dns-ist-zunächst-ein-internes-kommunikationssystem\"\u003e1. Kubernetes-DNS ist zunächst ein internes Kommunikationssystem\u003c/h2\u003e\n\u003cp\u003eKubernetes-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.\u003c/p\u003e\n\u003cp\u003eDiese 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.\u003c/p\u003e\n\u003cp\u003eFü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.\u003c/p\u003e\n\u003ch2 id=\"2-externe-zonen-definieren-den-öffentlichen-eingang\"\u003e2. Externe Zonen definieren den öffentlichen Eingang\u003c/h2\u003e\n\u003cp\u003eEine 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.\u003c/p\u003e\n\u003cp\u003eBei 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.\u003c/p\u003e\n\u003cp\u003eAnycast 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.\u003c/p\u003e\n\u003ch2 id=\"3-die-übergabe-zwischen-cluster-und-edge-muss-explizit-sein\"\u003e3. Die Übergabe zwischen Cluster und Edge muss explizit sein\u003c/h2\u003e\n\u003cp\u003eTechnisch 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.\u003c/p\u003e\n\u003cp\u003eDiese Ü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.\u003c/p\u003e\n\u003cp\u003eSecurity 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.\u003c/p\u003e\n\u003ch2 id=\"4-providerunabhängigkeit-ist-eine-architekturentscheidung\"\u003e4. Providerunabhängigkeit ist eine Architekturentscheidung\u003c/h2\u003e\n\u003cp\u003eKubernetes-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.\u003c/p\u003e\n\u003cp\u003eEine 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.\u003c/p\u003e\n\u003cp\u003eDie 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.\u003c/p\u003e\n\u003ch2 id=\"praxis--und-betriebsszenario\"\u003ePraxis- und Betriebsszenario\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt eine API in zwei Kubernetes-Clustern: einen Cluster bei einem Cloudprovider und einen weiteren in einer eigenen Infrastruktur. Intern verwenden die Workloads \u003ca href=\"https://kubernetes/\" target=\"_blank\" rel=\"noopener\"\u003eKubernetes\u003c/a\u003e\n -DNS für die Kommunikation. Die öffentliche Domain \u003ccode\u003eapi.example.com\u003c/code\u003e 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.\u003c/p\u003e\n\u003cp\u003eFä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 \u003ca href=\"https://kubernetes/\" target=\"_blank\" rel=\"noopener\"\u003eKubernetes\u003c/a\u003e\n -Service Discovery behalten damit ihre jeweils eigene Zuständigkeit.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"ist-kubernetes-dns-für-öffentliche-domains-geeignet\"\u003eIst Kubernetes-DNS für öffentliche Domains geeignet?\u003c/h3\u003e\n\u003cp\u003eNein. 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.\u003c/p\u003e\n\u003ch3 id=\"muss-die-externe-dns-zone-beim-kubernetes-provider-liegen\"\u003eMuss die externe DNS-Zone beim Kubernetes-Provider liegen?\u003c/h3\u003e\n\u003cp\u003eNein. 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.\u003c/p\u003e\n\u003ch3 id=\"was-passiert-bei-mehreren-kubernetes-clustern\"\u003eWas passiert bei mehreren Kubernetes-Clustern?\u003c/h3\u003e\n\u003cp\u003eDie 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.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eKubernetes-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.\u003c/p\u003e\n",
      "summary": "\nTL;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.\nEinleitung 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.\n",
      "image": "https://ayedo.de/kubernetes-dns-und-externe-zonen-sauber-zusammendenken.png",
      "date_published": "2026-09-02T14:04:43Z",
      "date_modified": "2026-09-02T14:04:43Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["kubernetes","hosting","cloud-native","digital-sovereignty","software-delivery"],
      "language": "de"
    },{
      "id": "https://ayedo.de/posts/dns-verwaltung-per-api-in-der-edge-cloud-automatisieren/",
      "url": "https://ayedo.de/posts/dns-verwaltung-per-api-in-der-edge-cloud-automatisieren/",
      "title": "DNS-Verwaltung per API in der Edge Cloud automatisieren",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/dns-verwaltung-per-api-in-der-edge-cloud-automatisieren/dns-verwaltung-per-api-in-der-edge-cloud-automatisieren.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eEine DNS API macht Zonenänderungen zu reproduzierbaren Betriebsprozessen statt zu manuellen Einzelschritten. Für External Zones und Internal Zones sind deklarative Konfigurationen, Validierung, Freigaben und idempotente Ausführung entscheidend. Erst die Verbindung mit \u003ca href=\"/kubernetes/\"\u003eInfrastructure as Code\u003c/a\u003e\n, CI/CD und nachvollziehbaren Änderungen schafft einen kontrollierbaren DNS-Betrieb.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eDNS wird in vielen Organisationen noch immer separat von Anwendungen und Infrastruktur verwaltet. Genau dadurch entstehen Risiken: Ein Deployment ändert einen Endpoint, die zugehörige Zone wird manuell angepasst, und später ist nicht mehr eindeutig nachvollziehbar, welcher Stand tatsächlich aktiv ist. Eine DNS API löst dieses Problem nicht automatisch. Sie schafft zunächst nur eine programmierbare Schnittstelle. Der entscheidende Schritt besteht darin, DNS-Konfigurationen als deklarative Plattformressourcen zu behandeln und in bestehende Delivery- und Freigabeprozesse einzubinden. Für External Zones und Internal Zones gelten dabei dieselben Grundprinzipien, aber nicht zwingend dieselben Zuständigkeiten und Prüfregeln.\u003c/p\u003e\n\u003ch2 id=\"1-zonenverwaltung-als-deklarativer-zustand\"\u003e1. Zonenverwaltung als deklarativer Zustand\u003c/h2\u003e\n\u003cp\u003eBei einer deklarativen DNS-Verwaltung beschreibt ein Repository den gewünschten Zustand einer Zone. Dazu gehören beispielsweise Records, Zielwerte, TTLs und die Zuordnung zu einer External Zone oder Internal Zone. Die Automatisierung vergleicht diesen Zustand mit der aktuell verwalteten Konfiguration und führt nur die erforderlichen Änderungen über die DNS API aus.\u003c/p\u003e\n\u003cp\u003eDer Vorteil liegt nicht allein in der Geschwindigkeit. Ein deklaratives Modell macht Änderungen reproduzierbar und reduziert die Abhängigkeit von individuellem Wissen. Ein neuer Service-Endpoint wird nicht durch eine manuelle Checkliste veröffentlicht, sondern durch eine versionierte Änderung an der Zonenkonfiguration. Das gilt auch für Rücknahmen: Wird ein Eintrag aus dem Soll-Zustand entfernt, kann der Prozess diese Abweichung gezielt behandeln.\u003c/p\u003e\n\u003cp\u003eExternal Zones und Internal Zones sollten dabei getrennt modelliert werden. Sie können unterschiedliche Verantwortlichkeiten, Freigabestufen und Sicherheitsanforderungen haben. Eine gemeinsame Automatisierungslogik ist möglich, solange Zonengrenzen und Zielumgebungen explizit bleiben. Die ayedo Edge Cloud stellt für beide Zonentypen API-basierte Verwaltung bereit; die fachliche Qualität entsteht durch das darüberliegende Betriebsmodell.\u003c/p\u003e\n\u003ch2 id=\"2-validierung-vor-der-ausführung\"\u003e2. Validierung vor der Ausführung\u003c/h2\u003e\n\u003cp\u003eEine DNS API sollte nicht der erste Ort sein, an dem eine Änderung auf Plausibilität geprüft wird. Vor dem API-Aufruf braucht es eine technische Validierung der deklarativen Konfiguration. Dabei lassen sich Syntax, erlaubte Record-Typen, Namenskonventionen, Pflichtfelder und widersprüchliche Einträge prüfen. Zusätzlich sollte die Pipeline erkennen, ob eine Änderung eine External Zone oder Internal Zone betrifft.\u003c/p\u003e\n\u003cp\u003eWichtig ist die Unterscheidung zwischen syntaktischer und semantischer Validierung. Ein gültiger DNS-Record kann trotzdem betrieblich falsch sein: etwa durch ein unerwartetes Ziel, eine zu niedrige TTL oder die unbeabsichtigte Änderung eines bereits genutzten Namens. Solche Regeln gehören in Policy Checks und nicht in nachgelagerte manuelle Kontrollen.\u003c/p\u003e\n\u003cp\u003eFreigaben sollten sich an der Risikoklasse orientieren. Änderungen an einer Entwicklungszone können automatisiert ausgerollt werden, während produktive External Zones eine zusätzliche Prüfung benötigen. Entscheidend ist, dass der erzeugte Änderungsumfang vor der Freigabe sichtbar ist. Ein Plan- oder Diff-Schritt zwischen Pull Request und Ausführung schafft diese Transparenz und verhindert, dass ein Operator die tatsächliche Wirkung erst nach dem API-Aufruf erkennt.\u003c/p\u003e\n\u003ch2 id=\"3-idempotenz-als-betriebsanforderung\"\u003e3. Idempotenz als Betriebsanforderung\u003c/h2\u003e\n\u003cp\u003eDNS-Automatisierung muss idempotent arbeiten. Wird dieselbe Konfiguration mehrfach angewendet, darf sie nicht bei jedem Lauf neue oder doppelte Einträge erzeugen. Ein erfolgreicher Lauf muss denselben Zielzustand hinterlassen wie ein wiederholter Lauf. Das ist besonders relevant, wenn Pipelines wiederholt gestartet werden, ein Deployment nach einem Timeout erneut versucht wird oder mehrere Betriebsprozesse denselben Zustand prüfen.\u003c/p\u003e\n\u003cp\u003eDafür muss die Automatisierung den gewünschten Zustand eindeutig identifizieren. Records dürfen nicht nur als einzelne Befehle betrachtet werden, sondern als verwaltete Ressourcen mit klaren Schlüsseln und definierten Eigenschaften. Änderungen an TTL, Zielwert oder Record-Typ müssen als kontrollierte Differenz erkennbar sein. Ebenso muss festgelegt werden, wie mit Einträgen umgegangen wird, die außerhalb des deklarativen Modells existieren.\u003c/p\u003e\n\u003cp\u003eEine sichere Ausführung berücksichtigt außerdem Teilfehler. Wenn eine Änderung an mehreren Zonen oder Records nur teilweise erfolgreich ist, braucht der Prozess einen erkennbaren Status und eine Wiederholungsstrategie. Die DNS API der ayedo Edge Cloud kann dabei in standardisierte Automatisierungsprozesse eingebunden werden. Die Verantwortung für Reihenfolge, Retries, Konfliktbehandlung und Abbruchlogik bleibt jedoch Bestandteil der jeweiligen Pipeline.\u003c/p\u003e\n\u003ch2 id=\"4-nachvollziehbarkeit-über-den-gesamten-lebenszyklus\"\u003e4. Nachvollziehbarkeit über den gesamten Lebenszyklus\u003c/h2\u003e\n\u003cp\u003eNachvollziehbarkeit entsteht nicht erst durch ein nachträgliches Protokoll des API-Aufrufs. Sie beginnt bei einer versionierten Konfigurationsänderung und reicht über Review, Freigabe und Ausführung bis zur Prüfung des resultierenden Zustands. Ein belastbarer Prozess kann deshalb beantworten, wer eine Zonenkonfiguration geändert hat, warum die Änderung erforderlich war, welche Einträge betroffen waren und wann sie angewendet wurde.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"/kubernetes/\"\u003eInfrastructure as Code\u003c/a\u003e\n schafft dafür die organisatorische Grundlage. DNS-Konfigurationen werden gemeinsam mit Anwendung oder Plattform versioniert, können reproduziert und bei Bedarf auf einen früheren Stand zurückgeführt werden. Für Internal Zones ist zusätzlich die Trennung von Plattform- und Anwendungsteams wichtig: Nicht jede Anwendung sollte beliebige interne Namen verändern dürfen. Rollen und Repository-Strukturen müssen den tatsächlichen Zuständigkeiten entsprechen.\u003c/p\u003e\n\u003cp\u003eFür External Zones kommt die öffentliche Erreichbarkeit als zusätzliche Betriebsdimension hinzu. In Verbindung mit Anycast DNS und den weiteren Edge-Funktionen der ayedo Edge Cloud wird DNS Teil des öffentlichen Zugangspfads zu Anwendungen und APIs. Eine Änderung sollte daher nicht isoliert als Record-Update betrachtet werden, sondern als kontrollierte Änderung an einer gemeinsam betriebenen Edge-Plattform.\u003c/p\u003e\n\u003ch2 id=\"praxis--und-betriebsszenario\"\u003ePraxis- und Betriebsszenario\u003c/h2\u003e\n\u003cp\u003eEin Plattformteam verwaltet die External Zone eines API-Portals und mehrere Internal Zones für serviceinterne Namensauflösung. Ein neues Backend erhält zunächst eine deklarative Konfiguration im Repository. Die Pipeline prüft Zonenzuordnung, Record-Struktur und Policy-Regeln und erzeugt anschließend einen Diff. Nach der Freigabe wendet sie die Änderung über die DNS API an und speichert den Ausführungsstatus zusammen mit Commit und Änderungsgrund.\u003c/p\u003e\n\u003cp\u003eEin manueller Prozess würde dieselben Schritte über verschiedene Werkzeuge verteilen. Dadurch könnten Review, tatsächlicher DNS-Zustand und Deployment auseinanderlaufen. Im API-basierten Modell bleibt die Konfiguration reproduzierbar. Ein erneuter Lauf führt bei unverändertem Soll-Zustand zu keiner weiteren Änderung; bei einer Korrektur entsteht ein neuer, prüfbarer Änderungsdatensatz.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"was-ist-der-unterschied-zwischen-dns-api-und-infrastructure-as-code\"\u003eWas ist der Unterschied zwischen DNS API und Infrastructure as Code?\u003c/h3\u003e\n\u003cp\u003eDie DNS API ist die programmierbare Schnittstelle zur Änderung des Zustands. \u003ca href=\"/kubernetes/\"\u003eInfrastructure as Code\u003c/a\u003e\n beschreibt diesen Zustand versioniert und verbindet ihn mit Validierung, Review, Freigabe und automatisierter Ausführung.\u003c/p\u003e\n\u003ch3 id=\"müssen-external-zones-und-internal-zones-getrennt-automatisiert-werden\"\u003eMüssen External Zones und Internal Zones getrennt automatisiert werden?\u003c/h3\u003e\n\u003cp\u003eNicht zwingend durch unterschiedliche Werkzeuge. Sie sollten jedoch getrennte Modelle, Berechtigungen und Freigaberegeln unterstützen, weil öffentliche und interne Namensräume unterschiedliche Betriebs- und Sicherheitsanforderungen haben.\u003c/p\u003e\n\u003ch3 id=\"wie-verhindert-idempotenz-unkontrollierte-dns-änderungen\"\u003eWie verhindert Idempotenz unkontrollierte DNS-Änderungen?\u003c/h3\u003e\n\u003cp\u003eDie Automatisierung vergleicht Soll- und Ist-Zustand und wendet nur echte Differenzen an. Wiederholte Läufe erzeugen keine zusätzlichen Änderungen, sofern die deklarative Konfiguration unverändert bleibt.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eDNS-Verwaltung per API ist erst dann ein belastbarer Betriebsprozess, wenn sie mit deklarativen Konfigurationen, Policy Checks, Freigaben und idempotenter Ausführung verbunden wird. External Zones und Internal Zones werden dadurch nicht zu manuellen Sonderfällen, sondern zu kontrollierbaren Plattformressourcen. Die ayedo Edge Cloud bietet mit API-basierter Zonenverwaltung, Anycast DNS und Multi-Provider-DNS den technischen Kontext für dieses Modell. Entscheidend bleibt die Qualität des umgebenden Delivery- und Governance-Prozesses.\u003c/p\u003e\n",
      "summary": "\nTL;DR Eine DNS API macht Zonenänderungen zu reproduzierbaren Betriebsprozessen statt zu manuellen Einzelschritten. Für External Zones und Internal Zones sind deklarative Konfigurationen, Validierung, Freigaben und idempotente Ausführung entscheidend. Erst die Verbindung mit Infrastructure as Code , CI/CD und nachvollziehbaren Änderungen schafft einen kontrollierbaren DNS-Betrieb.\nEinleitung DNS wird in vielen Organisationen noch immer separat von Anwendungen und Infrastruktur verwaltet. Genau dadurch entstehen Risiken: Ein Deployment ändert einen Endpoint, die zugehörige Zone wird manuell angepasst, und später ist nicht mehr eindeutig nachvollziehbar, welcher Stand tatsächlich aktiv ist. Eine DNS API löst dieses Problem nicht automatisch. Sie schafft zunächst nur eine programmierbare Schnittstelle. Der entscheidende Schritt besteht darin, DNS-Konfigurationen als deklarative Plattformressourcen zu behandeln und in bestehende Delivery- und Freigabeprozesse einzubinden. Für External Zones und Internal Zones gelten dabei dieselben Grundprinzipien, aber nicht zwingend dieselben Zuständigkeiten und Prüfregeln.\n",
      "image": "https://ayedo.de/dns-verwaltung-per-api-in-der-edge-cloud-automatisieren.png",
      "date_published": "2026-09-02T14:04:42Z",
      "date_modified": "2026-09-02T14:04:42Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["software-delivery","automation","operations","kubernetes","cloud-native"],
      "language": "de"
    },{
      "id": "https://ayedo.de/posts/dns-zonen-mit-terraform-reproduzierbar-bereitstellen/",
      "url": "https://ayedo.de/posts/dns-zonen-mit-terraform-reproduzierbar-bereitstellen/",
      "title": "DNS-Zonen mit Terraform reproduzierbar bereitstellen",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/dns-zonen-mit-terraform-reproduzierbar-bereitstellen/dns-zonen-mit-terraform-reproduzierbar-bereitstellen.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eDNS-Konfiguration ist produktionsrelevante Infrastruktur und sollte nicht von manuellen Änderungen in einzelnen Oberflächen abhängen. Mit \u003ca href=\"/kubernetes/\"\u003eTerraform\u003c/a\u003e\n lassen sich Zonen und DNS Records deklarativ verwalten, prüfen und reproduzierbar ausrollen. Voraussetzung sind ein sauberer State, klare Zuständigkeiten, kontrollierte Änderungen und ein Prozess für Abweichungen zwischen Code und tatsächlicher Konfiguration.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eManuell angelegte DNS Records erzeugen selten sofort Probleme. Kritisch wird es, wenn mehrere Umgebungen, Teams oder Zonen beteiligt sind und niemand mehr sicher sagen kann, welche Konfiguration maßgeblich ist. Ein vergessener Record, eine abweichende TTL oder eine Änderung direkt in der Plattform kann dann erst beim nächsten Rollout auffallen. DNS mit \u003ca href=\"/kubernetes/\"\u003eTerraform\u003c/a\u003e\n behandelt Zonen nicht als einmalige Einstellungen, sondern als versionierte Infrastruktur. Das verbessert Nachvollziehbarkeit und Wiederholbarkeit, verschiebt die Verantwortung aber zugleich in den Bereitstellungsprozess: State, Reviews, Abhängigkeiten und Abweichungen müssen bewusst betrieben werden.\u003c/p\u003e\n\u003ch2 id=\"1-dns-als-deklarative-infrastruktur-modellieren\"\u003e1. DNS als deklarative Infrastruktur modellieren\u003c/h2\u003e\n\u003cp\u003e\u003ca href=\"/kubernetes/\"\u003eTerraform\u003c/a\u003e\n beschreibt den gewünschten Zustand einer DNS-Zone in Konfigurationsdateien. Dazu gehören beispielsweise die Zone selbst sowie A-, AAAA-, CNAME-, MX- oder TXT-Records. Entscheidend ist die Trennung zwischen gewünschter Konfiguration und einzelnen Änderungsbefehlen. Ein Eintrag wird nicht „jetzt angelegt“, sondern als Bestandteil des Zielzustands definiert.\u003c/p\u003e\n\u003cp\u003eDer Terraform-Plan vergleicht diesen Zielzustand mit dem gespeicherten State und der aktuell erreichbaren Plattformkonfiguration. Dadurch werden geplante Änderungen sichtbar, bevor sie angewendet werden. Das ist besonders relevant für DNS Records, weil ein technisch kleiner Eingriff direkte Auswirkungen auf Erreichbarkeit, Zertifikatsvalidierung oder E-Mail-Zustellung haben kann.\u003c/p\u003e\n\u003cp\u003eIn der ayedo Edge Cloud betrifft diese Verwaltung den öffentlichen DNS-Einstieg vor Anwendungen und APIs. Zonen und Records können damit in denselben kontrollierten Änderungsprozess eingebunden werden wie andere Infrastrukturkomponenten. Die Edge Cloud stellt anschließend die DNS-Funktion bereit; \u003ca href=\"/kubernetes/\"\u003eTerraform\u003c/a\u003e\n definiert, welche Konfiguration dort gelten soll.\u003c/p\u003e\n\u003ch2 id=\"2-state-plan-und-apply-sind-betriebsprozesse\"\u003e2. State, Plan und Apply sind Betriebsprozesse\u003c/h2\u003e\n\u003cp\u003eDer [Terraform]-State ist keine nebensächliche Arbeitsdatei. Er bildet die Zuordnung zwischen Ressourcen im Code und Objekten in der ayedo Edge Cloud ab. Wird er verloren, überschrieben oder von mehreren Prozessen unkoordiniert verändert, kann \u003ca href=\"/kubernetes/\"\u003eTerraform\u003c/a\u003e\n den tatsächlichen Zustand nicht mehr zuverlässig bewerten. Der State muss deshalb geschützt, versioniert beziehungsweise zentral verwaltet und für parallele Änderungen gesperrt werden.\u003c/p\u003e\n\u003cp\u003eDer Plan ist eine Kontrollstufe, kein optionaler Probelauf. In einem Review sollte er zeigen, welche Zone oder welche DNS Records geändert, gelöscht oder neu angelegt werden. Erst danach folgt Apply in der vorgesehenen Umgebung. Für produktive Zonen ist ein automatisierter Apply ohne Prüfung riskant, insbesondere wenn Records mit kurzer TTL oder Failover-relevanter Bedeutung betroffen sind.\u003c/p\u003e\n\u003cp\u003eEin robuster Prozess trennt Zuständigkeiten: Änderungen werden im Repository vorgenommen, geprüft und nachvollziehbar freigegeben. Zugangsdaten gehören nicht in die [Terraform]-Dateien. Außerdem sollte der Prozess erkennen lassen, ob ein Plan auf dem aktuellen State basiert. Veraltete Pläne können sonst Änderungen ausführen, die auf einer inzwischen überholten Grundlage entstanden sind.\u003c/p\u003e\n\u003ch2 id=\"3-abhängigkeiten-und-mehrere-umgebungen-sauber-abbilden\"\u003e3. Abhängigkeiten und mehrere Umgebungen sauber abbilden\u003c/h2\u003e\n\u003cp\u003eDNS-Konfiguration besteht häufig aus Abhängigkeiten. Ein Record verweist auf einen externen Dienst, eine Subdomain delegiert an eine weitere Zone oder ein Eintrag wird erst sinnvoll, wenn ein Zielsystem bereitsteht. \u003ca href=\"/kubernetes/\"\u003eTerraform\u003c/a\u003e\n kann Abhängigkeiten aus Ressourcenreferenzen ableiten. Wo diese Beziehungen nicht direkt im Modell sichtbar sind, muss die Konfiguration sie explizit und verständlich abbilden.\u003c/p\u003e\n\u003cp\u003eFür mehrere Umgebungen sollte nicht einfach eine gemeinsame Zone mit wechselnden Werten verwendet werden. Besser sind klar getrennte Variablen, Zustände oder Konfigurationsbereiche für Entwicklung, Staging und Produktion. So wird verhindert, dass ein Apply für eine Testumgebung versehentlich produktive DNS Records verändert. Gleichzeitig muss definiert sein, welche Teile zentral sind: Delegationen und gemeinsame Basiszonen können anders verwaltet werden als umgebungsspezifische Subdomains.\u003c/p\u003e\n\u003cp\u003eDie ayedo Edge Cloud kann dabei als providerunabhängiger öffentlicher Einstieg genutzt werden, während Backends in ayedo Managed \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n, einem eigenen Cluster oder bei einem anderen Provider liegen. Diese Trennung macht die DNS-Konfiguration nicht einfacher, aber eindeutiger: \u003ca href=\"/kubernetes/\"\u003eTerraform\u003c/a\u003e\n verwaltet den gewünschten öffentlichen Namensraum, die Backend-Infrastruktur bleibt eine separate Zuständigkeit.\u003c/p\u003e\n\u003ch2 id=\"4-manuelle-änderungen-als-kontrollierte-ausnahme-behandeln\"\u003e4. Manuelle Änderungen als kontrollierte Ausnahme behandeln\u003c/h2\u003e\n\u003cp\u003eEine direkte Änderung in der DNS-Plattform ist nicht automatisch falsch. Sie wird zum Problem, wenn sie außerhalb des vorgesehenen Änderungsprozesses dauerhaft bestehen bleibt. \u003ca href=\"/kubernetes/\"\u003eTerraform\u003c/a\u003e\n erkennt eine solche Abweichung beim nächsten Plan als Drift. Je nach Konfiguration kann der Plan den manuellen Wert zurücksetzen, übernehmen oder zur Korrektur auffordern. Keine dieser Optionen ist sicher, wenn das Team die Ursache der Abweichung nicht kennt.\u003c/p\u003e\n\u003cp\u003eFür Notfalländerungen braucht es deshalb eine klare Regel: Wer darf sie durchführen, wie werden sie dokumentiert und wann werden sie in den Code überführt? Ein manueller Record, der dauerhaft im System bleibt, ist keine belastbare Lösung. Wird eine Änderung absichtlich außerhalb von \u003ca href=\"/kubernetes/\"\u003eTerraform\u003c/a\u003e\n verwaltet, muss diese Zuständigkeit ausdrücklich modelliert werden, etwa durch getrennte Zonen oder definierte Ausschlüsse.\u003c/p\u003e\n\u003cp\u003eDas gilt auch für ayedo Edge Cloud und Multi-Provider-DNS-Szenarien. Je mehr Systeme an der Namensauflösung beteiligt sind, desto wichtiger sind eindeutige Eigentümer und eine erkennbare Quelle der Wahrheit. Reproduzierbarkeit bedeutet nicht, jede Änderung zu automatisieren. Sie bedeutet, dass ein definierter Zustand jederzeit nachvollziehbar erneut hergestellt werden kann.\u003c/p\u003e\n\u003ch2 id=\"praxis--und-betriebsszenario\"\u003ePraxis- und Betriebsszenario\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt die Anwendung \u003ccode\u003eapp.example.com\u003c/code\u003e in Produktion und eine separate Staging-Umgebung. Die produktive Zone wird in einem eigenen [Terraform]-State verwaltet, die Staging-Subdomain in einem zweiten. Ein Release benötigt zusätzlich einen TXT-Record für eine Validierung. Dieser Record wird als abhängige Ressource definiert und erst gemeinsam mit dem Release freigegeben.\u003c/p\u003e\n\u003cp\u003eEin Administrator ändert den produktiven CNAME Record manuell, weil ein Backend kurzfristig verschoben wurde. Der nächste Plan zeigt die Abweichung. Das Team prüft zunächst, ob die Änderung dauerhaft gelten soll. Falls ja, wird der [Terraform]-Code angepasst und erneut geplant. Falls nein, stellt Apply den dokumentierten Zielzustand wieder her. Ohne diesen Prozess bliebe unklar, welche Konfiguration beim nächsten Deployment gewinnt.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"kann-terraform-dns-records-sofort-und-ohne-prüfung-ändern\"\u003eKann \u003ca href=\"/kubernetes/\"\u003eTerraform\u003c/a\u003e\n DNS Records sofort und ohne Prüfung ändern?\u003c/h3\u003e\n\u003cp\u003eTechnisch kann ein Apply Änderungen automatisieren. Für produktive Zonen sollte der Plan jedoch geprüft und freigegeben werden, weil auch kleine Änderungen Erreichbarkeit und abhängige Dienste beeinflussen können.\u003c/p\u003e\n\u003ch3 id=\"was-passiert-bei-einer-manuellen-änderung\"\u003eWas passiert bei einer manuellen Änderung?\u003c/h3\u003e\n\u003cp\u003e\u003ca href=\"/kubernetes/\"\u003eTerraform\u003c/a\u003e\n erkennt die Abweichung als Drift, sofern die Ressource im State verwaltet wird. Der nächste Plan zeigt, ob die Änderung zurückgesetzt oder im Code nachvollziehbar übernommen werden soll.\u003c/p\u003e\n\u003ch3 id=\"braucht-jede-umgebung-einen-eigenen-terraform-state\"\u003eBraucht jede Umgebung einen eigenen [Terraform]-State?\u003c/h3\u003e\n\u003cp\u003eNicht zwingend, aber getrennte Zustände reduzieren das Risiko unbeabsichtigter Änderungen. Besonders Produktion und nichtproduktive Umgebungen sollten klar voneinander isoliert werden.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eDNS mit \u003ca href=\"/kubernetes/\"\u003eTerraform\u003c/a\u003e\n ist vor allem eine Entscheidung für nachvollziehbare Betriebsprozesse. Der technische Nutzen entsteht nicht allein durch deklarative Dateien, sondern durch geschützten State, geprüfte Pläne, saubere Umgebungsgrenzen und einen definierten Umgang mit manueller Drift. Für DNS-Zonen in der ayedo Edge Cloud schafft dieser Ansatz eine reproduzierbare Grundlage, unabhängig davon, wo die eigentlichen Backends betrieben werden. Damit wird DNS von einer schwer überprüfbaren Einzelkonfiguration zu einem kontrollierten Bestandteil der Plattformarchitektur.\u003c/p\u003e\n",
      "summary": "\nTL;DR DNS-Konfiguration ist produktionsrelevante Infrastruktur und sollte nicht von manuellen Änderungen in einzelnen Oberflächen abhängen. Mit Terraform lassen sich Zonen und DNS Records deklarativ verwalten, prüfen und reproduzierbar ausrollen. Voraussetzung sind ein sauberer State, klare Zuständigkeiten, kontrollierte Änderungen und ein Prozess für Abweichungen zwischen Code und tatsächlicher Konfiguration.\nEinleitung Manuell angelegte DNS Records erzeugen selten sofort Probleme. Kritisch wird es, wenn mehrere Umgebungen, Teams oder Zonen beteiligt sind und niemand mehr sicher sagen kann, welche Konfiguration maßgeblich ist. Ein vergessener Record, eine abweichende TTL oder eine Änderung direkt in der Plattform kann dann erst beim nächsten Rollout auffallen. DNS mit Terraform behandelt Zonen nicht als einmalige Einstellungen, sondern als versionierte Infrastruktur. Das verbessert Nachvollziehbarkeit und Wiederholbarkeit, verschiebt die Verantwortung aber zugleich in den Bereitstellungsprozess: State, Reviews, Abhängigkeiten und Abweichungen müssen bewusst betrieben werden.\n",
      "image": "https://ayedo.de/dns-zonen-mit-terraform-reproduzierbar-bereitstellen.png",
      "date_published": "2026-09-02T14:04:42Z",
      "date_modified": "2026-09-02T14:04:42Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["operations","automation","kubernetes","cloud-native","digital-sovereignty"],
      "language": "de"
    },{
      "id": "https://ayedo.de/posts/dnssec-in-verteilten-autoritativen-dns-architekturen-betreiben/",
      "url": "https://ayedo.de/posts/dnssec-in-verteilten-autoritativen-dns-architekturen-betreiben/",
      "title": "DNSSEC in verteilten autoritativen DNS-Architekturen betreiben",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/dnssec-in-verteilten-autoritativen-dns-architekturen-betreiben/dnssec-in-verteilten-autoritativen-dns-architekturen-betreiben.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eDNSSEC ist kein Schalter, sondern ein laufender Betriebsprozess. In verteilten autoritativen DNS-Architekturen müssen Zonensignierung, Schlüsselwechsel, Vertrauenskette und Synchronisierung zusammenpassen. Fehler bei Timing, TTLs oder Zonentransfer können dazu führen, dass Resolver Antworten als ungültig verwerfen – obwohl der DNS-Dienst grundsätzlich erreichbar ist.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eDNSSEC schützt DNS nicht durch Verschlüsselung, sondern durch die kryptografische Prüfung von Authentizität und Integrität. Der betriebliche Fehler liegt häufig darin, DNSSEC einmal zu aktivieren und anschließend wie eine statische Konfiguration zu behandeln. In einer verteilten autoritativen Architektur vervielfacht sich jedoch die Verantwortung: Jede Instanz muss konsistente signierte Zonen ausliefern, Schlüsselwechsel müssen kontrolliert erfolgen und Änderungen dürfen die Vertrauenskette nicht unterbrechen. Für External Zones vor Anwendungen und APIs ist das besonders relevant, weil ein DNSSEC-Fehler nicht nur einzelne Records betrifft, sondern die Erreichbarkeit kompletter Dienste beeinträchtigen kann.\u003c/p\u003e\n\u003ch2 id=\"1-dnssec-bildet-eine-vertrauenskette\"\u003e1. DNSSEC bildet eine Vertrauenskette\u003c/h2\u003e\n\u003cp\u003eDie Vertrauenskette beginnt beim Root-Schlüssel und führt über die DS-Records der übergeordneten Zone zum DNSKEY der autoritativen Zone. Mit diesem Schlüssel lassen sich RRSIG-Signaturen und damit die Authentizität der Zonendaten prüfen. Ein validierender Resolver akzeptiert eine Antwort nur, wenn Signatur, Schlüssel und zeitliche Gültigkeit zusammenpassen.\u003c/p\u003e\n\u003cp\u003eAutoritative Server validieren DNSSEC normalerweise nicht für ihre eigenen Antworten. Sie signieren Zonen und liefern die dafür notwendigen Records aus. Resolver übernehmen anschließend die Validierung. Daraus entsteht eine klare Abhängigkeit: Eine korrekte Signatur allein genügt nicht, wenn der DS-Record beim Registrar fehlt, veraltet ist oder nicht zum veröffentlichten DNSKEY passt.\u003c/p\u003e\n\u003cp\u003eFür den Betrieb bedeutet das, DNSSEC als Ende-zu-Ende-Kette zu betrachten. Änderungen an der Zone, am Schlüsselmaterial und bei der Delegation müssen gemeinsam geplant und überprüft werden. Anycast DNS oder Multi-Provider-DNS erhöhen die Verfügbarkeit des autoritativen Dienstes, ersetzen aber nicht die kryptografische Konsistenz der ausgelieferten Daten.\u003c/p\u003e\n\u003ch2 id=\"2-zonensignierung-ist-ein-kontinuierlicher-prozess\"\u003e2. Zonensignierung ist ein kontinuierlicher Prozess\u003c/h2\u003e\n\u003cp\u003eEine signierte Zone enthält neben den fachlichen Records zusätzliche DNSSEC-Daten wie DNSKEY, RRSIG und NSEC beziehungsweise NSEC3. Jede relevante Änderung kann neue Signaturen erfordern. Signaturen besitzen eine begrenzte Gültigkeit und müssen rechtzeitig erneuert werden. Fällt dieser Prozess aus, liefern autoritative Server möglicherweise weiterhin Antworten, die Resolver wegen abgelaufener RRSIGs verwerfen.\u003c/p\u003e\n\u003cp\u003eDie Signierung muss deshalb in den normalen Änderungsprozess integriert werden. Dazu gehören reproduzierbare Abläufe für Zonenänderungen, Prüfungen der Signaturabdeckung und Monitoring für ablaufende Signaturen. Auch negative Antworten, etwa für nicht vorhandene Records, müssen durch DNSSEC abgesichert werden. Andernfalls bleibt die Vertrauenskette für positive Antworten intakt, während Negativantworten nicht zuverlässig validierbar sind.\u003c/p\u003e\n\u003cp\u003eIn einer Edge-Plattform wie der ayedo Edge Cloud ist diese Perspektive besonders wichtig: Autoritative DNS-Funktionen bilden einen öffentlichen Einstiegspunkt, der unabhängig von einem einzelnen Compute-Cluster betrieben werden kann. DNSSEC muss daher als Plattformprozess für External Zones behandelt werden, nicht als nachgelagerte Option einer einzelnen Anwendung.\u003c/p\u003e\n\u003ch2 id=\"3-schlüsselwechsel-erfordert-kontrolliertes-timing\"\u003e3. Schlüsselwechsel erfordert kontrolliertes Timing\u003c/h2\u003e\n\u003cp\u003eDNSSEC-Schlüssel haben unterschiedliche Aufgaben. Der Zone Signing Key signiert Zonendaten, während der Key Signing Key die DNSKEY-Kette absichert. Je nach Betriebsmodell können weitere Schlüsselrollen hinzukommen. Entscheidend ist nicht die Bezeichnung, sondern die Reihenfolge der Veröffentlichung und Entfernung.\u003c/p\u003e\n\u003cp\u003eBei einem Wechsel darf ein alter Schlüssel nicht verschwinden, bevor Resolver die neuen Daten und Delegationsinformationen kennen können. TTLs, Caching und Signaturlebensdauer bestimmen, wie lange alte Zustände im Internet sichtbar bleiben. Ein sicherer Wechsel verwendet deshalb Übergangsphasen, in denen alter und neuer Schlüssel beziehungsweise passende Signaturen gleichzeitig verfügbar sind. Erst nach Ablauf relevanter Cache-Zeiten wird der alte Zustand entfernt.\u003c/p\u003e\n\u003cp\u003eBesonders kritisch ist der KSK-Wechsel, weil dabei der DS-Record der übergeordneten Zone beteiligt ist. Ein nicht abgestimmter DS-Wechsel kann die gesamte Zone als „bogus“ erscheinen lassen. Schlüsselrotation braucht daher Verantwortlichkeiten, Freigaben, Ablaufüberwachung und einen getesteten Rückfallpfad. Sie ist ein Betriebsverfahren mit Abhängigkeiten zu Registrar, DNS-Betreiber und Änderungsmanagement.\u003c/p\u003e\n\u003ch2 id=\"4-zonensynchronisierung-entscheidet-über-konsistenz\"\u003e4. Zonensynchronisierung entscheidet über Konsistenz\u003c/h2\u003e\n\u003cp\u003eVerteilte autoritative DNS-Systeme müssen nicht nur erreichbar, sondern inhaltlich konsistent sein. Liefert ein Standort einen neuen A-Record mit gültiger Signatur aus, während ein anderer noch eine alte Version oder abgelaufene RRSIGs liefert, entstehen schwer reproduzierbare Validierungsfehler. Anycast kann solche Unterschiede für Clients unsichtbar machen, aber nicht technisch lösen.\u003c/p\u003e\n\u003cp\u003eDie Synchronisierung muss deshalb signierte Zonen und DNSSEC-Metadaten vollständig berücksichtigen. Dazu gehören Seriennummern, Signaturen, DNSKEY-Records und die korrekte Behandlung negativer Antworten. Ein Betriebsmodell sollte klären, ob an einer zentralen Stelle signiert und anschließend verteilt wird oder ob mehrere autoritative Systeme signieren. Beide Ansätze haben Trade-offs bei Konsistenz, Ausfallverhalten und Änderungsfreigaben.\u003c/p\u003e\n\u003cp\u003eFür die ayedo Edge Cloud ist dieser Zusammenhang im Kontext einer verteilten Multi-PoP- und Aktiv-Aktiv-Architektur relevant. Die Edge Cloud kann autoritativen DNS als providerunabhängige Eingangsschicht bereitstellen; die fachliche Verantwortung bleibt jedoch an überprüfbare Prozesse gebunden. Health Checks für DNSSEC müssen daher nicht nur Erreichbarkeit, sondern auch Validierbarkeit und Übereinstimmung der ausgelieferten Zone prüfen.\u003c/p\u003e\n\u003ch2 id=\"praxis--und-betriebsszenario\"\u003ePraxis- und Betriebsszenario\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt eine External Zone für eine API, deren Traffic über mehrere autoritative DNS-Systeme verteilt wird. Vor einer geplanten KSK-Rotation wird der neue DNSKEY veröffentlicht, die DS-Anpassung vorbereitet und die Zone über alle autoritativen Systeme synchronisiert. Anschließend prüft das Team von verschiedenen Resolvern aus die vollständige Vertrauenskette. Erst wenn neue und alte Pfade konsistent validieren, wird der DS-Record umgestellt. Nach ausreichender Cache-Zeit werden der alte Schlüssel und die alten Signaturen entfernt. Ein solcher Ablauf dauert länger als eine normale DNS-Änderung, reduziert aber das Risiko eines flächigen Erreichbarkeitsverlusts.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"ist-dnssec-eine-verschlüsselung-des-dns-verkehrs\"\u003eIst DNSSEC eine Verschlüsselung des DNS-Verkehrs?\u003c/h3\u003e\n\u003cp\u003eNein. DNSSEC signiert DNS-Daten und ermöglicht deren Validierung. Die Inhalte bleiben lesbar. Vertraulichkeit und Transportverschlüsselung sind Aufgaben anderer Mechanismen.\u003c/p\u003e\n\u003ch3 id=\"wer-prüft-die-dnssec-signaturen\"\u003eWer prüft die DNSSEC-Signaturen?\u003c/h3\u003e\n\u003cp\u003eValidierende rekursive Resolver prüfen Signaturen und die Vertrauenskette. Autoritative Server stellen signierte Daten und Schlüsselmaterial bereit.\u003c/p\u003e\n\u003ch3 id=\"was-passiert-bei-einer-fehlerhaften-signatur\"\u003eWas passiert bei einer fehlerhaften Signatur?\u003c/h3\u003e\n\u003cp\u003eEin validierender Resolver kann die Antwort als ungültig verwerfen. Für Clients wirkt das häufig wie ein DNS-Ausfall, obwohl die autoritativen Server technisch erreichbar sind.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eDNSSEC ist eine laufende Betriebsdisziplin aus Signierung, Schlüsselmanagement, Delegationspflege und Synchronisierung. In verteilten autoritativen Architekturen müssen diese Prozesse über alle Auslieferungspunkte konsistent funktionieren. Die ayedo Edge Cloud ist in diesem Zusammenhang nicht nur Transportweg für DNS-Anfragen, sondern Teil einer öffentlichen, verteilten Edge-Infrastruktur. Entscheidend ist daher ein überprüfbarer Prozess, der kryptografische Gültigkeit ebenso überwacht wie Erreichbarkeit.\u003c/p\u003e\n",
      "summary": "\nTL;DR DNSSEC ist kein Schalter, sondern ein laufender Betriebsprozess. In verteilten autoritativen DNS-Architekturen müssen Zonensignierung, Schlüsselwechsel, Vertrauenskette und Synchronisierung zusammenpassen. Fehler bei Timing, TTLs oder Zonentransfer können dazu führen, dass Resolver Antworten als ungültig verwerfen – obwohl der DNS-Dienst grundsätzlich erreichbar ist.\nEinleitung DNSSEC schützt DNS nicht durch Verschlüsselung, sondern durch die kryptografische Prüfung von Authentizität und Integrität. Der betriebliche Fehler liegt häufig darin, DNSSEC einmal zu aktivieren und anschließend wie eine statische Konfiguration zu behandeln. In einer verteilten autoritativen Architektur vervielfacht sich jedoch die Verantwortung: Jede Instanz muss konsistente signierte Zonen ausliefern, Schlüsselwechsel müssen kontrolliert erfolgen und Änderungen dürfen die Vertrauenskette nicht unterbrechen. Für External Zones vor Anwendungen und APIs ist das besonders relevant, weil ein DNSSEC-Fehler nicht nur einzelne Records betrifft, sondern die Erreichbarkeit kompletter Dienste beeinträchtigen kann.\n",
      "image": "https://ayedo.de/dnssec-in-verteilten-autoritativen-dns-architekturen-betreiben.png",
      "date_published": "2026-09-02T14:04:42Z",
      "date_modified": "2026-09-02T14:04:42Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["development","kubernetes","digital-sovereignty","cloud-native","software-delivery"],
      "language": "de"
    },{
      "id": "https://ayedo.de/posts/externe-dns-zonen-zentral-und-kontrolliert-verwalten/",
      "url": "https://ayedo.de/posts/externe-dns-zonen-zentral-und-kontrolliert-verwalten/",
      "title": "Externe DNS-Zonen zentral und kontrolliert verwalten",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/externe-dns-zonen-zentral-und-kontrolliert-verwalten/externe-dns-zonen-zentral-und-kontrolliert-verwalten.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eExterne DNS-Zonen zu verwalten ist eine Governance-Aufgabe, nicht nur eine technische Routine. Eine zentrale Instanz schafft klare Zuständigkeiten, kontrollierte Änderungen und nachvollziehbare Zonengrenzen. Die ayedo Edge Cloud stellt dafür Anycast DNS und Multi-Provider-DNS bereit. DNS-Steuerung und Traffic-Verteilung bleiben dabei getrennte Verantwortungsbereiche.\u003c/p\u003e\n\u003cp\u003eExterne DNS-Zonen werden häufig dort geändert, wo gerade technischer Bedarf entsteht: im Anwendungsteam, beim Hosting-Provider, im Netzwerkbetrieb oder direkt beim Registrar. Das wirkt zunächst flexibel, erzeugt aber verteilte Zuständigkeiten, uneinheitliche Freigaben und schwer nachvollziehbare Abhängigkeiten. Besonders problematisch wird dieses Modell, wenn dieselbe Domain mehrere Anwendungen, Umgebungen oder Provider verbindet.\u003c/p\u003e\n\u003cp\u003eDie zentrale Verwaltung externer DNS-Zonen ist deshalb vor allem eine Betriebs- und Kontrollentscheidung. Sie legt fest, wer Zonen betreiben darf, welche Änderungen zulässig sind und wo die Verantwortung für Delegationen endet. Ein autoritativer DNS-Dienst kann diese Regeln technisch konsistent umsetzen. Er ersetzt jedoch weder ein fachliches Freigabemodell noch die nachgelagerte Steuerung von Traffic und Backends.\u003c/p\u003e\n\u003ch2 id=\"1-dns-verantwortung-beginnt-mit-klaren-zonengrenzen\"\u003e1. DNS-Verantwortung beginnt mit klaren Zonengrenzen\u003c/h2\u003e\n\u003cp\u003eEine DNS-Zone ist nicht automatisch eine organisatorische Einheit. Die Zone \u003ccode\u003eexample.com\u003c/code\u003e kann mehrere Produkte, Teams und Infrastrukturplattformen abbilden. Werden Einträge direkt von unterschiedlichen Stellen verwaltet, vermischen sich technische Zuständigkeiten mit Domänenverantwortung. Änderungen an einem Teilbereich können dann Auswirkungen auf andere Services haben.\u003c/p\u003e\n\u003cp\u003eEin kontrolliertes Modell definiert deshalb zunächst Zonengrenzen. Die zentrale Plattform kann beispielsweise die übergeordnete Zone verwalten, während klar abgegrenzte Subdomains an bestimmte Verantwortliche delegiert werden. Entscheidend ist, dass diese Delegation bewusst erfolgt und dokumentiert bleibt. Alternativ verbleiben sämtliche Einträge in einer zentral verantworteten Zone, wenn eine konsistente Kontrolle wichtiger ist als dezentrale Änderungsfreiheit.\u003c/p\u003e\n\u003cp\u003eFür die Governance zählen dabei nicht nur Nameserver und Records, sondern auch Eigentümer, Freigaberegeln, Änderungsfenster und Eskalationswege. Die ayedo Edge Cloud kann als zentraler autoritativer DNS-Dienst mit Anycast DNS und Multi-Provider-DNS in ein solches Modell eingebunden werden. Welche Personen oder Teams Änderungen freigeben, ist dagegen eine organisatorische Festlegung und kein automatisch gegebenes Plattformmerkmal.\u003c/p\u003e\n\u003ch2 id=\"2-zentrale-dns-verwaltung-reduziert-betriebliche-unklarheit\"\u003e2. Zentrale DNS-Verwaltung reduziert betriebliche Unklarheit\u003c/h2\u003e\n\u003cp\u003eVerteilte DNS-Konfigurationen erhöhen den Aufwand bei jeder Änderung. Ein Team muss zunächst herausfinden, welcher Provider autoritativ ist, wer Zugriff besitzt und ob ein Eintrag manuell, per Automatisierung oder über einen anderen Dienst gepflegt wird. Bei Störungen verlängert diese Suche die Diagnose, weil technische und organisatorische Zuständigkeiten auseinanderfallen.\u003c/p\u003e\n\u003cp\u003eEin zentraler DNS-Betrieb schafft einen eindeutigen Kontrollpunkt für externe Zonen. Änderungen können einem definierten Prozess folgen: Antrag, technische Prüfung, Freigabe, Umsetzung und Nachvollziehbarkeit. Das ist besonders relevant für produktive Domains, Zertifikatsvalidierungen, Mail-DNS und Einträge, die auf externe SaaS- oder Cloud-Dienste zeigen.\u003c/p\u003e\n\u003cp\u003eZentralisierung bedeutet dabei nicht, jeden Record manuell durch ein einzelnes Team pflegen zu lassen. Sie kann ebenso bedeuten, dass Automatisierung und dezentrale Fachverantwortung über eine gemeinsame autoritative Instanz laufen. Wichtig ist die einheitliche Kontrolle über die Zone. Anycast DNS und Multi-Provider-DNS der ayedo Edge Cloud adressieren die Verteilung und Verfügbarkeit des DNS-Betriebs; sie ersetzen nicht die internen Regeln für Change-Management und Zugriff.\u003c/p\u003e\n\u003ch2 id=\"3-dns-steuerung-ist-nicht-traffic-verteilung\"\u003e3. DNS-Steuerung ist nicht Traffic-Verteilung\u003c/h2\u003e\n\u003cp\u003eEin häufiger Architekturfehler besteht darin, DNS als vollständige Routing- oder Loadbalancing-Schicht zu behandeln. DNS liefert Antworten auf Namensauflösungen. Die eigentliche Verteilung von Verbindungen, die Prüfung von Backends, TLS-Terminierung oder der Schutz von HTTP- und HTTPS-Traffic liegen in anderen Schichten.\u003c/p\u003e\n\u003cp\u003eDiese Trennung ist für Verantwortlichkeiten entscheidend. Das DNS-Team kann festlegen, auf welchen öffentlichen Einstieg ein Name zeigt. Die Edge-Plattform entscheidet anschließend, wie eingehender Traffic an Backends verteilt wird, welche Gesundheitsprüfungen gelten und ob Failover ausgelöst wird. Werden beide Aufgaben vermischt, sind Änderungen schwerer zu bewerten: Ein DNS-Record kann dann fälschlich als Ersatz für eine kontrollierte Traffic-Steuerung dienen.\u003c/p\u003e\n\u003cp\u003eIn der ayedo Edge Cloud bilden Anycast DNS und die Edge-Funktionen deshalb unterschiedliche, aber verbundene Ebenen. DNS kann zentral betrieben werden, während Layer-4- und Layer-7-Loadbalancing, Backend Health Checks, Failover oder Backend Cloaking separat betrachtet werden. Diese Architektur verhindert, dass die DNS-Verantwortung automatisch auf Backend- oder Applikationsverantwortung übergreift.\u003c/p\u003e\n\u003ch2 id=\"4-freigaben-müssen-technische-risiken-sichtbar-machen\"\u003e4. Freigaben müssen technische Risiken sichtbar machen\u003c/h2\u003e\n\u003cp\u003eNicht jede DNS-Änderung hat dasselbe Risiko. Ein TXT-Record für eine Verifikation ist anders zu bewerten als die Änderung eines MX-Records oder eines A- beziehungsweise AAAA-Records für einen produktiven Dienst. Ein belastbares Governance-Modell klassifiziert Änderungen nach Auswirkungen und definiert dafür passende Prüfungen.\u003c/p\u003e\n\u003cp\u003eFür produktive Zonen sind insbesondere folgende Fragen relevant: Wird die bestehende Auflösung unterbrochen? Ändert sich der öffentliche Einstieg? Ist der Zielservice unter fremder organisatorischer Kontrolle? Welche TTL gilt, und wie schnell kann eine Fehlkonfiguration korrigiert werden? Auch die Delegation einer Subdomain sollte geprüft werden, weil damit ein separater Verantwortungsbereich entsteht.\u003c/p\u003e\n\u003cp\u003eDie zentrale Verwaltung unterstützt diese Kontrolle, wenn Zonenbesitz und Änderungsrechte eindeutig zugeordnet sind. Wirtschaftlich reduziert das vor allem Koordinations- und Störungskosten: weniger Suchaufwand, klarere Eskalation und geringeres Risiko widersprüchlicher Konfigurationen. Sie schafft aber keine automatische Sicherheit. Fehlende Freigaben, unklare Eigentümer oder unkontrollierte Zugänge bleiben Governance-Probleme, unabhängig vom verwendeten DNS-Dienst.\u003c/p\u003e\n\u003ch2 id=\"praxis--und-betriebsszenario\"\u003ePraxis- und Betriebsszenario\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt \u003ccode\u003eexample.com\u003c/code\u003e für mehrere Produkte. Das Plattformteam verantwortet den autoritativen DNS-Betrieb. Produktteams dürfen definierte Subdomains beantragen, während Änderungen an der Hauptzone eine zusätzliche Prüfung durch Netzwerk- oder Security-Verantwortliche erfordern. Ein SaaS-Anbieter erhält nur die Delegation für \u003ccode\u003evendor.example.com\u003c/code\u003e, nicht für die gesamte Zone.\u003c/p\u003e\n\u003cp\u003eDie ayedo Edge Cloud übernimmt in diesem Modell die zentrale DNS-Ebene. Ein Record kann auf einen öffentlichen Edge-Einstieg zeigen; die anschließende Traffic-Verteilung und das Backend-Failover werden separat in der Edge-Konfiguration gesteuert. Fällt ein Backend aus, muss nicht zwangsläufig die DNS-Zone geändert werden. Dadurch bleiben DNS-Freigaben, Routing-Entscheidungen und Backend-Betrieb getrennte Prozesse mit klaren Verantwortungsgrenzen.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"ist-zentrale-dns-verwaltung-dasselbe-wie-dns-loadbalancing\"\u003eIst zentrale DNS-Verwaltung dasselbe wie DNS-Loadbalancing?\u003c/h3\u003e\n\u003cp\u003eNein. DNS beantwortet Namensanfragen. Loadbalancing verteilt Verbindungen oder Requests und berücksichtigt typischerweise Backends, Gesundheitszustände und Failover-Regeln.\u003c/p\u003e\n\u003ch3 id=\"wann-sind-subdomain-delegationen-sinnvoll\"\u003eWann sind Subdomain-Delegationen sinnvoll?\u003c/h3\u003e\n\u003cp\u003eWenn ein Team oder externer Dienst einen klar abgegrenzten Namensraum eigenständig betreiben soll. Die Delegation muss dokumentiert, technisch begrenzt und organisatorisch verantwortet werden.\u003c/p\u003e\n\u003ch3 id=\"ersetzt-anycast-dns-ein-internes-change-management\"\u003eErsetzt Anycast DNS ein internes Change-Management?\u003c/h3\u003e\n\u003cp\u003eNein. Anycast verbessert die verteilte Bereitstellung des DNS-Dienstes. Freigaben, Zugriffskontrolle, Zoneneigentum und Nachvollziehbarkeit müssen weiterhin organisatorisch und betrieblich definiert werden.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eExterne DNS-Zonen zu verwalten bedeutet, Verantwortlichkeiten und technische Eingriffspunkte bewusst zu ordnen. Eine zentrale autoritative DNS-Ebene reduziert verteilte Zuständigkeiten, darf aber nicht mit Traffic-Steuerung oder Backend-Betrieb verwechselt werden. Die ayedo Edge Cloud verbindet \u003ca href=\"/kubernetes/\"\u003eAnycast DNS\u003c/a\u003e\n und \u003ca href=\"/kubernetes/\"\u003eMulti-Provider-DNS\u003c/a\u003e\n mit einer Edge-Architektur, in der DNS, Routing und Schutz getrennt bewertet und kontrolliert betrieben werden können.\u003c/p\u003e\n",
      "summary": "\nTL;DR Externe DNS-Zonen zu verwalten ist eine Governance-Aufgabe, nicht nur eine technische Routine. Eine zentrale Instanz schafft klare Zuständigkeiten, kontrollierte Änderungen und nachvollziehbare Zonengrenzen. Die ayedo Edge Cloud stellt dafür Anycast DNS und Multi-Provider-DNS bereit. DNS-Steuerung und Traffic-Verteilung bleiben dabei getrennte Verantwortungsbereiche.\nExterne DNS-Zonen werden häufig dort geändert, wo gerade technischer Bedarf entsteht: im Anwendungsteam, beim Hosting-Provider, im Netzwerkbetrieb oder direkt beim Registrar. Das wirkt zunächst flexibel, erzeugt aber verteilte Zuständigkeiten, uneinheitliche Freigaben und schwer nachvollziehbare Abhängigkeiten. Besonders problematisch wird dieses Modell, wenn dieselbe Domain mehrere Anwendungen, Umgebungen oder Provider verbindet.\n",
      "image": "https://ayedo.de/externe-dns-zonen-zentral-und-kontrolliert-verwalten.png",
      "date_published": "2026-09-02T14:04:42Z",
      "date_modified": "2026-09-02T14:04:42Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["hosting","security","operations","kubernetes","cloud-native"],
      "language": "de"
    },{
      "id": "https://ayedo.de/posts/anycast-dns-als-baustein-hochverfugbarer-edge-architekturen/",
      "url": "https://ayedo.de/posts/anycast-dns-als-baustein-hochverfugbarer-edge-architekturen/",
      "title": "Anycast DNS als Baustein hochverfügbarer Edge-Architekturen",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/anycast-dns-als-baustein-hochverfugbarer-edge-architekturen/anycast-dns-als-baustein-hochverfugbarer-edge-architekturen.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eAnycast DNS ist mehr als eine alternative Verteilungsmethode für DNS-Anfragen. Als autoritativer Dienst bildet es eine eigenständige, verteilte Eingangsschicht der Edge-Architektur. Es verbessert Erreichbarkeit und Ausfallsicherheit der Namensauflösung, ersetzt jedoch weder Routing noch Loadbalancing. Diese Aufgaben müssen architektonisch getrennt betrachtet werden.\u003c/p\u003e\n\u003cp\u003eDie Verfügbarkeit einer Anwendung beginnt vor dem ersten TCP- oder HTTP-Paket. Kann ein Client den autoritativen DNS-Dienst nicht zuverlässig erreichen oder erhält er veraltete beziehungsweise unpassende Antworten, greifen nachgelagerte Schutz- und Routingmechanismen nicht. DNS ist deshalb keine bloße Konfigurationskomponente eines Loadbalancers, sondern eine eigene Infrastrukturstufe mit eigenen Ausfallmodellen.\u003c/p\u003e\n\u003cp\u003eIn klassischen Architekturen liegt DNS häufig bei einem einzelnen Provider oder wird gemeinsam mit dem Loadbalancer verwaltet. Das kann organisatorisch einfach sein, koppelt jedoch Namensauflösung, Traffic-Verteilung und Betriebsverantwortung eng miteinander. Eine hochverfügbare Edge-Architektur muss diese Abhängigkeiten sichtbar machen und getrennt bewerten.\u003c/p\u003e\n\u003ch2 id=\"anycast-dns-als-verteilte-eingangsschicht\"\u003eAnycast DNS als verteilte Eingangsschicht\u003c/h2\u003e\n\u003cp\u003eBei Anycast verwenden mehrere geografisch und netzwerktechnisch verteilte Standorte dieselbe IP-Adresse oder denselben Adressraum. Das Routing im Internet führt eine DNS-Anfrage zu einem erreichbaren Standort, typischerweise über die aus Netzsicht passende Route. Fällt ein Standort oder ein Teil des Pfads aus, kann die Anforderung über eine andere verfügbare Route beantwortet werden.\u003c/p\u003e\n\u003cp\u003eFür einen autoritativen DNS-Dienst bedeutet das: Die Erreichbarkeit der Zone hängt nicht an einem einzelnen Standort oder einer einzelnen Netzwerkverbindung. Die DNS-Infrastruktur wird selbst zu einem verteilten Edge-Dienst. Das reduziert die Wahrscheinlichkeit, dass ein lokaler Ausfall die Namensauflösung global unterbricht.\u003c/p\u003e\n\u003cp\u003eAnycast löst allerdings nicht automatisch jedes DNS-Problem. Zonen müssen konsistent bereitgestellt werden, Routingänderungen müssen kontrolliert erfolgen, und Resolver-Caches beeinflussen, wann Änderungen wirksam werden. Hochverfügbarkeit entsteht aus dem Zusammenspiel von Verteilung, konsistentem Betrieb und klar definierten Failover-Mechanismen – nicht allein aus der Verwendung einer gemeinsamen IP-Adresse.\u003c/p\u003e\n\u003ch2 id=\"aktiv-aktiv-statt-primärer-und-sekundärer-einzelpfade\"\u003eAktiv-Aktiv statt primärer und sekundärer Einzelpfade\u003c/h2\u003e\n\u003cp\u003eDie Aktiv-Aktiv-Ausrichtung verändert das Ausfallmodell. Mehrere Edge-Standorte nehmen gleichzeitig DNS-Anfragen entgegen, anstatt dass ein primärer Standort den Normalbetrieb übernimmt und ein sekundärer nur im Fehlerfall aktiviert wird. Dadurch wird die verfügbare Infrastruktur kontinuierlich genutzt und im laufenden Betrieb geprüft.\u003c/p\u003e\n\u003cp\u003eFür den Betrieb hat das zwei Konsequenzen. Erstens müssen Konfigurationen und Zonenänderungen über die aktiven Standorte konsistent sein. Zweitens ist ein Ausfall kein außergewöhnlicher Umschaltvorgang, sondern eine Veränderung der verfügbaren Pfade innerhalb eines laufenden Systems. Das kann Failover-Prozesse vereinfachen, verlangt aber belastbares Monitoring und kontrollierte Änderungen.\u003c/p\u003e\n\u003cp\u003eIm Kontext der ayedo Edge Cloud ist Anycast DNS Teil einer verteilten Multi-PoP-Architektur mit eigenem Autonomous System und eigener Netzwerk-Infrastruktur. Die Aktiv-Aktiv-Ausrichtung betrifft dabei die Edge als Plattform: DNS-Anfragen werden verteilt beantwortet, während die Edge zugleich weitere Aufgaben wie Traffic-Annahme und Schutz der nachgelagerten Services übernimmt.\u003c/p\u003e\n\u003ch2 id=\"dns-verteilung-ist-nicht-anwendungsrouting\"\u003eDNS-Verteilung ist nicht Anwendungsrouting\u003c/h2\u003e\n\u003cp\u003eEine DNS-Antwort und das anschließende Routing des Anwendungstraffics sind zwei unterschiedliche Vorgänge. Der autoritative DNS-Dienst beantwortet die Frage, welche Adresse ein Resolver für einen Namen erhalten soll. Erst danach baut der Client eine Verbindung zu dieser Adresse auf. Die Auswahl des DNS-Standorts bestimmt daher nicht automatisch, an welchem Backend die Anwendung ausgeführt wird.\u003c/p\u003e\n\u003cp\u003eDiese Trennung ist für die Architektur entscheidend. Anycast DNS kann die Erreichbarkeit der Namensauflösung verbessern, während Anycast-Layer-4- oder Layer-7-Loadbalancing den eingehenden Traffic an die geeigneten Backends verteilt. Health Checks, Failover, TLS Termination, WAF und DDoS Protection wirken in nachgelagerten Schichten und erfüllen andere Aufgaben.\u003c/p\u003e\n\u003cp\u003eEine DNS-basierte Umschaltung kann durch TTLs und Resolver-Caches verzögert sichtbar werden. Für zeitkritische Backend-Entscheidungen ist sie deshalb nicht immer ausreichend. Eine Edge-Plattform sollte DNS und Traffic-Steuerung als zusammenhängende, aber getrennte Kontroll- und Datenpfade betreiben. Genau diese Abgrenzung verhindert falsche Erwartungen an DNS-Failover.\u003c/p\u003e\n\u003ch2 id=\"providerunabhängigkeit-und-betriebliche-konsequenzen\"\u003eProviderunabhängigkeit und betriebliche Konsequenzen\u003c/h2\u003e\n\u003cp\u003eEin autoritativer DNS-Dienst ist ein zentraler Abhängigkeitspunkt für jede öffentlich erreichbare Anwendung. Wird er beim selben Provider wie Compute, Loadbalancer und Netzwerkanbindung betrieben, können Störungen oder Fehlkonfigurationen mehrere Schichten gleichzeitig betreffen. Multi-Provider-DNS kann diese Kopplung reduzieren, ersetzt aber nicht die Notwendigkeit einer konsistenten Zonenverwaltung.\u003c/p\u003e\n\u003cp\u003eFür Unternehmen ist daher zu klären, welche Funktionen beim DNS liegen und welche an der Edge. DNS muss autoritativ, verlässlich und unabhängig von einzelnen nachgelagerten Workloads funktionieren. Die Edge muss anschließend entscheiden können, wie Traffic geschützt, terminiert und auf verfügbare Backends verteilt wird – auch wenn diese Backends in eigenen Rechenzentren, bei anderen Cloud-Providern oder in unterschiedlichen \u003ca href=\"https://www.kubernetes/\" target=\"_blank\" rel=\"noopener\"\u003eKubernetes\u003c/a\u003e\n Clustern betrieben werden.\u003c/p\u003e\n\u003cp\u003eDie ayedo Edge Cloud unterstützt diese providerunabhängige Perspektive durch Anycast DNS und Multi-Provider-DNS. Kubernetes-Integration ist dabei nicht auf ayedo Managed Kubernetes beschränkt. Entscheidend ist die Trennung: DNS und öffentliche Edge-Funktionen können zentral betrieben werden, während Compute dort verbleibt, wo es aus technischen, regulatorischen oder wirtschaftlichen Gründen sinnvoll ist.\u003c/p\u003e\n\u003ch2 id=\"praxis--und-architekturszenario\"\u003ePraxis- und Architekturszenario\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt eine API in zwei \u003ca href=\"https://www.kubernetes/\" target=\"_blank\" rel=\"noopener\"\u003eKubernetes\u003c/a\u003e\n Clustern bei unterschiedlichen Providern. In einer einfachen Architektur zeigt der autoritative DNS-Dienst direkt auf einen Provider-Loadbalancer. Fällt dessen DNS- oder Netzwerkpfad aus, erreicht der Client möglicherweise weder die alternative API-Instanz noch einen funktionierenden Failover-Pfad.\u003c/p\u003e\n\u003cp\u003eIn einer getrennten Edge-Architektur beantwortet Anycast DNS die Zone über mehrere aktive Edge-Standorte. Die DNS-Schicht bleibt unabhängig von den Clustern erreichbar. Der anschließend eintreffende API-Traffic wird an der Edge geprüft und über Loadbalancing, Health Checks und Failover an verfügbare Backends verteilt. DNS stellt damit die Erreichbarkeit des Namens sicher; die Edge entscheidet über den weiteren Traffic-Pfad.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"ist-anycast-dns-dasselbe-wie-dns-loadbalancing\"\u003eIst Anycast DNS dasselbe wie DNS-Loadbalancing?\u003c/h3\u003e\n\u003cp\u003eNein. Anycast verteilt DNS-Anfragen zu erreichbaren autoritativen Standorten. DNS-Loadbalancing verändert Antworten anhand definierter Kriterien. Beides kann kombiniert werden, erfüllt aber unterschiedliche Aufgaben.\u003c/p\u003e\n\u003ch3 id=\"kann-anycast-dns-einen-backend-ausfall-automatisch-kompensieren\"\u003eKann Anycast DNS einen Backend-Ausfall automatisch kompensieren?\u003c/h3\u003e\n\u003cp\u003eNicht unmittelbar. Anycast DNS schützt primär die Erreichbarkeit des DNS-Dienstes. Backend-Failover erfolgt über nachgelagerte Edge-Funktionen wie Health Checks und Traffic-Steuerung.\u003c/p\u003e\n\u003ch3 id=\"warum-reicht-ein-einzelner-dns-provider-oft-nicht-aus\"\u003eWarum reicht ein einzelner DNS-Provider oft nicht aus?\u003c/h3\u003e\n\u003cp\u003eEin einzelner Provider kann einen gemeinsamen Ausfall- oder Abhängigkeitspunkt für Namensauflösung und weitere Edge-Funktionen bilden. Multi-Provider-DNS reduziert diese Kopplung und verbessert die architektonische Trennung.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eAnycast DNS sollte in hochverfügbaren Edge-Architekturen als eigenständige, verteilte Infrastruktur betrachtet werden. Es erhöht die Robustheit der autoritativen Namensauflösung, ersetzt aber weder Anwendungsrouting noch Loadbalancing. Die technische Qualität entsteht durch die klare Trennung dieser Schichten und ihr kontrolliertes Zusammenspiel. Mit Anycast DNS, Multi-Provider-DNS und einer Aktiv-Aktiv-Edge bietet die ayedo Edge Cloud dafür einen providerunabhängigen Architekturrahmen – auch für Backends außerhalb von ayedo Managed \u003ca href=\"https://www.kubernetes/\" target=\"_blank\" rel=\"noopener\"\u003eKubernetes\u003c/a\u003e\n.\u003c/p\u003e\n",
      "summary": "\nTL;DR Anycast DNS ist mehr als eine alternative Verteilungsmethode für DNS-Anfragen. Als autoritativer Dienst bildet es eine eigenständige, verteilte Eingangsschicht der Edge-Architektur. Es verbessert Erreichbarkeit und Ausfallsicherheit der Namensauflösung, ersetzt jedoch weder Routing noch Loadbalancing. Diese Aufgaben müssen architektonisch getrennt betrachtet werden.\nDie Verfügbarkeit einer Anwendung beginnt vor dem ersten TCP- oder HTTP-Paket. Kann ein Client den autoritativen DNS-Dienst nicht zuverlässig erreichen oder erhält er veraltete beziehungsweise unpassende Antworten, greifen nachgelagerte Schutz- und Routingmechanismen nicht. DNS ist deshalb keine bloße Konfigurationskomponente eines Loadbalancers, sondern eine eigene Infrastrukturstufe mit eigenen Ausfallmodellen.\n",
      "image": "https://ayedo.de/anycast-dns-als-baustein-hochverfugbarer-edge-architekturen.png",
      "date_published": "2026-09-02T14:04:41Z",
      "date_modified": "2026-09-02T14:04:41Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["kubernetes","security","ai","cloud-native","operations"],
      "language": "de"
    },{
      "id": "https://ayedo.de/posts/anycast-dns-routing-und-loadbalancing-klar-abgegrenzt/",
      "url": "https://ayedo.de/posts/anycast-dns-routing-und-loadbalancing-klar-abgegrenzt/",
      "title": "Anycast DNS, Routing und Loadbalancing klar abgegrenzt",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/anycast-dns-routing-und-loadbalancing-klar-abgegrenzt/anycast-dns-routing-und-loadbalancing-klar-abgegrenzt.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eAnycast DNS entscheidet, welche IP-Adresse ein Client für einen Dienst erhält. Es verteilt jedoch keine einzelnen TCP-Verbindungen oder HTTP-Anfragen. Diese Aufgaben beginnen erst nach der DNS-Auflösung: Anycast Routing führt den Traffic zu einem Edge-Standort, Layer 4 verteilt Verbindungen, Layer 7 bewertet HTTP-Anfragen. Diese Trennung ist Grundlage einer belastbaren Edge-Architektur.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eDie Annahme, Anycast DNS verteile automatisch jede Verbindung oder HTTP-Anfrage zum optimalen Backend, führt zu falschen Architekturentscheidungen. DNS arbeitet vor dem eigentlichen Verbindungsaufbau und liefert Antworten, die von rekursiven Resolvern und Clients zwischengespeichert werden. Danach entscheidet das IP-Routing, welchen Edge-Standort die Pakete erreichen. Erst dort können Layer-4- oder Layer-7-Komponenten Verbindungen und Anfragen auf Backends verteilen. Anycast DNS, Anycast Routing und Loadbalancing liegen damit auf unterschiedlichen Ebenen. Wer diese Ebenen vermischt, überschätzt die Steuerungsmöglichkeiten von DNS und unterschätzt die Bedeutung des öffentlichen Eingangs vor den Anwendungen.\u003c/p\u003e\n\u003ch2 id=\"1-anycast-dns-entscheidet-über-die-erreichbare-zieladresse\"\u003e1. Anycast DNS entscheidet über die erreichbare Zieladresse\u003c/h2\u003e\n\u003cp\u003eAnycast DNS stellt denselben Dienst über mehrere geografisch und netzwerktechnisch verteilte DNS-Standorte bereit. Für eine DNS-Anfrage existiert damit nicht zwingend nur ein einzelner autoritativer Server als Ziel. Das Internet-Routing führt die Anfrage zu einem erreichbaren Standort, der eine DNS-Antwort liefert. Diese Antwort enthält typischerweise eine oder mehrere IP-Adressen für den angefragten Dienst.\u003c/p\u003e\n\u003cp\u003eDamit ist die Aufgabe von Anycast DNS zunächst beendet. DNS bestimmt, welche Adresse ein Client verwenden soll, nicht, welches Backend eine einzelne HTTP-Anfrage verarbeitet. Außerdem kontrolliert die autoritative DNS-Infrastruktur nicht zuverlässig den Zeitpunkt jeder späteren Verbindung: Resolver und Betriebssysteme verwenden Caches gemäß den DNS-Parametern. Eine Änderung der Antwort wirkt daher nicht sofort bei allen Clients.\u003c/p\u003e\n\u003cp\u003eIn der ayedo Edge Cloud gehört Anycast DNS zusammen mit Multi-Provider-DNS zur öffentlichen Erreichbarkeit der Plattform. Das schafft Redundanz auf DNS-Ebene, ersetzt aber weder das Routing des anschließenden Traffics noch das Loadbalancing vor den Anwendungen.\u003c/p\u003e\n\u003ch2 id=\"2-anycast-routing-führt-pakete-zur-edge\"\u003e2. Anycast Routing führt Pakete zur Edge\u003c/h2\u003e\n\u003cp\u003eNach der DNS-Auflösung baut der Client eine Verbindung zur zurückgelieferten IP-Adresse auf. Nun greift nicht mehr DNS, sondern das IP-Routing. Bei Anycast können mehrere Edge-Standorte dieselbe IP-Adresse ankündigen. Router im Internet wählen anhand ihrer Routingentscheidung einen erreichbaren Pfad zu einem dieser Standorte. Diese Auswahl ist topologisch und netzwerkseitig geprägt, nicht das Ergebnis einer Bewertung jeder einzelnen HTTP-Anfrage.\u003c/p\u003e\n\u003cp\u003eAnycast Routing kann Traffic bei Ausfällen oder Änderungen der Erreichbarkeit zu einem anderen Edge-Standort führen. Es garantiert jedoch nicht, dass alle Pakete einer Anwendungssitzung weltweit denselben Weg nehmen oder dass der geografisch nächste Standort ausgewählt wird. Routing folgt den verfügbaren Pfaden und deren Präferenzen. Für die Stabilität höherer Protokolle bleibt deshalb entscheidend, wie die Edge-Verbindungen verarbeitet werden.\u003c/p\u003e\n\u003cp\u003eDie ayedo Edge Cloud nutzt eine eigene Netzwerk-Infrastruktur, ein eigenes Autonomous System sowie eine verteilte Multi-PoP-Architektur im Aktiv-Aktiv-Prinzip. Diese Eigenschaften verankern den öffentlichen Eingang netzwerkseitig vor den Backends. Sie sind aber nicht mit der Entscheidung gleichzusetzen, welches konkrete Backend eine Verbindung oder Anfrage erhält.\u003c/p\u003e\n\u003ch2 id=\"3-layer-4-verteilt-verbindungen-layer-7-versteht-anfragen\"\u003e3. Layer 4 verteilt Verbindungen, Layer 7 versteht Anfragen\u003c/h2\u003e\n\u003cp\u003eErreicht eine Verbindung die Edge, beginnen die Aufgaben des Loadbalancings. Layer-4-Loadbalancing arbeitet auf Transportebene, beispielsweise mit TCP oder UDP. Es kann eingehende Verbindungen auf verfügbare Backends verteilen, ohne den Inhalt einer HTTP-Anfrage analysieren zu müssen. Das ist für Protokolle und Dienste relevant, die nicht auf HTTP basieren oder bei denen eine Transportentscheidung genügt.\u003c/p\u003e\n\u003cp\u003eLayer-7-Loadbalancing arbeitet dagegen auf Anwendungsebene. Bei HTTP oder HTTPS können Eigenschaften wie Hostname, Pfad oder Header in Routingentscheidungen einfließen. Dafür muss die Edge den Anwendungsverkehr verstehen; bei HTTPS ist häufig eine TLS Termination an der Edge erforderlich. Layer 7 bietet damit mehr Steuerungsmöglichkeiten, erhöht aber auch die Komplexität und die Verantwortung für korrekte Protokollverarbeitung.\u003c/p\u003e\n\u003cp\u003eDie ayedo Edge Cloud unterstützt Anycast-basiertes Layer-4- und Layer-7-Loadbalancing. Backend Health Checks und Failover ermöglichen, nicht verfügbare Ziele aus der Verteilung herauszunehmen. Backend Cloaking trennt dabei den öffentlichen Eingang von den direkt erreichbaren Backend-Adressen. DNS liefert also den Zugangspunkt; die eigentliche Verbindungs- und Anfrageverteilung erfolgt erst innerhalb der Edge.\u003c/p\u003e\n\u003ch2 id=\"4-die-ebenen-müssen-in-der-architektur-zusammenpassen\"\u003e4. Die Ebenen müssen in der Architektur zusammenpassen\u003c/h2\u003e\n\u003cp\u003eDie vier Ebenen erfüllen unterschiedliche Aufgaben: DNS veröffentlicht Erreichbarkeit, Anycast Routing führt Pakete zu einem Edge-Standort, Layer 4 verarbeitet Transportverbindungen und Layer 7 bewertet Anwendungsanfragen. Diese Kette ist nicht beliebig austauschbar. Ein niedriger TTL-Wert macht DNS beispielsweise nicht zu einem Request-Router. Ebenso kann Layer-7-Loadbalancing keine Entscheidung treffen, wenn der Traffic die Edge aufgrund eines vorgelagerten Netzwerkproblems nicht erreicht.\u003c/p\u003e\n\u003cp\u003eFür den Betrieb bedeutet die Trennung, dass Fehler systematisch eingegrenzt werden müssen. Eine fehlerhafte DNS-Antwort, ein Routingproblem, ein nicht erreichbarer Edge-Standort und ein ausgefallenes Backend erzeugen unterschiedliche Symptome. Metriken und Traffic-Statistiken sollten deshalb den Pfad vom DNS-Ergebnis bis zur Backend-Verarbeitung nachvollziehbar machen.\u003c/p\u003e\n\u003cp\u003eDiese Architektur ist providerunabhängig nutzbar. Die ayedo Edge Cloud kann ayedo Managed \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n, eigene \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n–Cluster oder Cluster bei anderen Providern als Backends anbinden. Dadurch bleibt der öffentliche Eingang mit DNS, Anycast Routing und Loadbalancing von der Wahl der Compute-Infrastruktur getrennt.\u003c/p\u003e\n\u003ch2 id=\"praxis--und-betriebsszenario\"\u003ePraxis- und Betriebsszenario\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt eine API in zwei \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n-Clustern bei unterschiedlichen Providern. Der DNS-Name zeigt auf eine von der Edge bereitgestellte Anycast-Adresse. Ein Client fragt diese Adresse über seinen Resolver ab. Die DNS-Antwort wird gecacht; eine einzelne spätere API-Anfrage löst daher nicht zwingend eine neue DNS-Abfrage aus.\u003c/p\u003e\n\u003cp\u003eBeim Verbindungsaufbau führt Anycast Routing den Traffic zu einem erreichbaren Edge-Standort. Für TCP kann Layer 4 eine Verbindung an einen gesunden Cluster weiterleiten. Bei HTTP kann Layer 7 zusätzlich anhand des Hostnamens oder Pfads routen. Meldet ein Health Check einen Backend-Ausfall, greift Failover innerhalb der Edge-Verarbeitung. DNS musste dafür nicht jede einzelne Anfrage neu verteilen.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"verteilt-anycast-dns-einzelne-http-anfragen\"\u003eVerteilt Anycast DNS einzelne HTTP-Anfragen?\u003c/h3\u003e\n\u003cp\u003eNein. DNS liefert Adressen und wird durch Caches entkoppelt. Die Verteilung einzelner Verbindungen oder HTTP-Anfragen erfolgt erst nach dem Verbindungsaufbau durch Layer-4- beziehungsweise Layer-7-Komponenten.\u003c/p\u003e\n\u003ch3 id=\"ist-anycast-routing-dasselbe-wie-loadbalancing\"\u003eIst Anycast Routing dasselbe wie Loadbalancing?\u003c/h3\u003e\n\u003cp\u003eNein. Anycast Routing wählt einen erreichbaren Netzwerkpfad zu einem Edge-Standort. Loadbalancing verteilt Verbindungen oder Anfragen anschließend auf Backends.\u003c/p\u003e\n\u003ch3 id=\"wann-ist-layer-7-loadbalancing-erforderlich\"\u003eWann ist Layer-7-Loadbalancing erforderlich?\u003c/h3\u003e\n\u003cp\u003eWenn Routingentscheidungen vom HTTP-Kontext abhängen, etwa von Hostname oder Pfad. Für reine Transportverteilung oder Nicht-HTTP-Dienste kann Layer 4 ausreichend sein.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eAnycast DNS, Anycast Routing und Loadbalancing bilden eine Abfolge, aber keine Synonyme. DNS entscheidet über die veröffentlichte Zieladresse, das Internet-Routing über den erreichbaren Edge-Pfad und Layer 4 oder Layer 7 über die Verarbeitung des Traffics. Für Unternehmen ist diese Abgrenzung relevant, weil sie Failover, Observability und Betriebsverantwortung präzise zuordnet. Die ayedo Edge Cloud verbindet diese Ebenen vor Anwendungen und APIs, ohne sie architektonisch zu vermischen.\u003c/p\u003e\n",
      "summary": "\nTL;DR Anycast DNS entscheidet, welche IP-Adresse ein Client für einen Dienst erhält. Es verteilt jedoch keine einzelnen TCP-Verbindungen oder HTTP-Anfragen. Diese Aufgaben beginnen erst nach der DNS-Auflösung: Anycast Routing führt den Traffic zu einem Edge-Standort, Layer 4 verteilt Verbindungen, Layer 7 bewertet HTTP-Anfragen. Diese Trennung ist Grundlage einer belastbaren Edge-Architektur.\nEinleitung Die Annahme, Anycast DNS verteile automatisch jede Verbindung oder HTTP-Anfrage zum optimalen Backend, führt zu falschen Architekturentscheidungen. DNS arbeitet vor dem eigentlichen Verbindungsaufbau und liefert Antworten, die von rekursiven Resolvern und Clients zwischengespeichert werden. Danach entscheidet das IP-Routing, welchen Edge-Standort die Pakete erreichen. Erst dort können Layer-4- oder Layer-7-Komponenten Verbindungen und Anfragen auf Backends verteilen. Anycast DNS, Anycast Routing und Loadbalancing liegen damit auf unterschiedlichen Ebenen. Wer diese Ebenen vermischt, überschätzt die Steuerungsmöglichkeiten von DNS und unterschätzt die Bedeutung des öffentlichen Eingangs vor den Anwendungen.\n",
      "image": "https://ayedo.de/anycast-dns-routing-und-loadbalancing-klar-abgegrenzt.png",
      "date_published": "2026-09-02T14:04:41Z",
      "date_modified": "2026-09-02T14:04:41Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["operations","kubernetes","cloud-native","digital-sovereignty","software-delivery"],
      "language": "de"
    },{
      "id": "https://ayedo.de/posts/internal-und-external-zones-konsistent-synchronisieren/",
      "url": "https://ayedo.de/posts/internal-und-external-zones-konsistent-synchronisieren/",
      "title": "Internal und External Zones konsistent synchronisieren",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/internal-und-external-zones-konsistent-synchronisieren/internal-und-external-zones-konsistent-synchronisieren.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eGetrennte Internal Zones und External Zones lösen unterschiedliche Sichtbarkeits- und Sicherheitsanforderungen, erzeugen aber ein erhebliches Konsistenzrisiko. Eine belastbare DNS-Zonensynchronisierung benötigt deshalb klare Datenverantwortung, kontrollierte Änderungsprozesse, automatisierte Vergleiche und definierte Ausnahmen. Entscheidend ist nicht identischer Inhalt, sondern widerspruchsfreie Antworten je Auflösungsweg.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eDie häufigste Fehlannahme bei getrennten DNS-Zonen lautet: Wenn interne und öffentliche Auflösungen unterschiedliche Antworten liefern, sei das automatisch ein Fehler. Tatsächlich dürfen Internal Zones und External Zones bewusst voneinander abweichen. Problematisch wird es, wenn diese Abweichungen unbeabsichtigt entstehen oder dieselbe Anwendung unter gleichem Namen auf inkonsistente Ziele zeigt. Dann treffen Nutzer, Monitoring, Automatisierung und externe Clients auf unterschiedliche Realitäten. Eine DNS-Zonensynchronisierung muss daher nicht einfach Datensätze kopieren. Sie muss festlegen, welche Informationen geteilt werden, welche Sichtbarkeit gilt und wie Änderungen kontrolliert in beide Zonen gelangen.\u003c/p\u003e\n\u003ch2 id=\"1-unterschiedliche-sichtbarkeit-ist-ein-architekturprinzip\"\u003e1. Unterschiedliche Sichtbarkeit ist ein Architekturprinzip\u003c/h2\u003e\n\u003cp\u003eInternal Zones und External Zones bilden typischerweise ein Split-Horizon-DNS-Modell. Ein Name wie \u003ccode\u003eapi.example.tld\u003c/code\u003e kann intern auf eine private Adresse oder einen internen Einstiegspunkt zeigen, während externe Clients eine öffentliche Adresse erhalten. Diese Trennung reduziert die Offenlegung interner Strukturen und erlaubt unterschiedliche Routing- oder Sicherheitsmodelle.\u003c/p\u003e\n\u003cp\u003eDie Zonen sind deshalb nicht zwingend identisch. Gemeinsam sein müssen vor allem die fachlichen Beziehungen: Der Name muss existieren, die Zielrolle muss korrekt abgebildet sein und Änderungen dürfen keine widersprüchlichen Betriebszustände erzeugen. Ein Datensatz kann in der External Zone bewusst fehlen, obwohl er intern benötigt wird. Umgekehrt sollte ein öffentlich erreichbarer Dienst nicht versehentlich nur in der Internal Zone aktualisiert werden.\u003c/p\u003e\n\u003cp\u003eFür die ayedo Edge Cloud ist diese Unterscheidung relevant, weil sie als öffentlicher Eingang vor Anwendungen und APIs arbeitet. External Zones steuern dabei öffentliche Auflösungswege, während Internal Zones interne Zugriffe und Namensauflösungen abbilden können. Die Edge Cloud darf nicht als einfache Kopierstelle zwischen beiden Zonen verstanden werden.\u003c/p\u003e\n\u003ch2 id=\"2-ein-gemeinsames-datenmodell-verhindert-drift\"\u003e2. Ein gemeinsames Datenmodell verhindert Drift\u003c/h2\u003e\n\u003cp\u003eDNS-Konsistenz beginnt nicht mit dem Zonentransfer, sondern mit einer eindeutigen Quelle für fachliche Informationen. Ohne definierte Datenverantwortung entstehen parallele Änderungen: Ein Team aktualisiert einen Backend-Namen intern, ein anderes ändert den öffentlichen Eintrag separat. Beide Zonen bleiben formal gültig, beschreiben aber unterschiedliche Zustände.\u003c/p\u003e\n\u003cp\u003eEin praktikables Modell trennt deshalb gemeinsame Attribute von sichtbarkeitsspezifischen Attributen. Gemeinsame Attribute können Name, Dienstidentität, Zielrolle oder gewünschter Zustand sein. Sichtbarkeitsspezifisch sind beispielsweise öffentliche beziehungsweise interne Zieladressen, TTLs oder die Frage, ob ein Record überhaupt veröffentlicht wird. Aus diesem Modell werden die jeweiligen Zonen abgeleitet oder kontrolliert synchronisiert.\u003c/p\u003e\n\u003cp\u003eWichtig ist, Ausnahmen explizit zu dokumentieren. Ein Eintrag, der absichtlich nur intern auflösbar ist, darf nicht wie ein fehlender Synchronisationsschritt behandelt werden. Ebenso braucht jeder Eintrag eine erkennbare Zuständigkeit. In einer Edge-Plattform mit Anycast DNS und Multi-Provider-DNS betrifft das nicht nur Zonendaten, sondern auch die Frage, welche autoritativen Auflösungswege denselben fachlichen Zustand liefern sollen.\u003c/p\u003e\n\u003ch2 id=\"3-änderungen-brauchen-validierung-und-reihenfolge\"\u003e3. Änderungen brauchen Validierung und Reihenfolge\u003c/h2\u003e\n\u003cp\u003eDie meisten Inkonsistenzen entstehen während Änderungen, nicht im stabilen Betrieb. Ein neuer Service wird zuerst intern angelegt, der öffentliche Record folgt später. Oder ein Ziel wird extern umgestellt, während die Internal Zone noch auf ein altes Backend zeigt. Solche Zwischenzustände können bei unterschiedlichen TTLs und Caches länger sichtbar bleiben als erwartet.\u003c/p\u003e\n\u003cp\u003eEin kontrollierter Änderungsprozess prüft daher vor der Veröffentlichung mindestens Namenskonflikte, erlaubte Sichtbarkeit, Zieltyp, TTL und Abhängigkeiten. Ein Vergleich zwischen Internal Zone und External Zone sollte nicht nur identische Records suchen, sondern erwartete Unterschiede gegen eine Regelmenge prüfen. Ein Unterschied ist dann entweder zulässig, etwa wegen einer privaten Zieladresse, oder ein Fehler.\u003c/p\u003e\n\u003cp\u003eAuch die Reihenfolge ist relevant. Wird ein Ziel neu eingeführt, muss es zunächst erreichbar und validiert sein, bevor der entsprechende DNS-Eintrag veröffentlicht wird. Bei einer Entfernung gilt das umgekehrte Prinzip: Erst Traffic und Abhängigkeiten umstellen, dann alte Records entfernen. Die ayedo Edge Cloud kann in diesem Zusammenhang als zentrale Edge für öffentliche Auflösung, Routing und Backend-Anbindung dienen; die fachliche Freigabe der Zonenzustände bleibt jedoch ein eigener Betriebsprozess.\u003c/p\u003e\n\u003ch2 id=\"4-betriebskontrollen-müssen-antworten-vergleichen\"\u003e4. Betriebskontrollen müssen Antworten vergleichen\u003c/h2\u003e\n\u003cp\u003eEine Zone kann syntaktisch korrekt sein und trotzdem fachlich falsche Antworten liefern. Deshalb reicht eine einmalige Prüfung beim Deployment nicht aus. Regelmäßige Kontrollen sollten die erwartete Antwort aus internen und externen Auflösungswegen vergleichen: Existiert der Name? Liefert er den vorgesehenen Record-Typ? Zeigt er auf das richtige Ziel? Entspricht die Antwort der erlaubten Sichtbarkeit?\u003c/p\u003e\n\u003cp\u003eDabei müssen Caching und negative Antworten berücksichtigt werden. Ein bereits gesetzter TTL-Wert kann bewirken, dass Resolver noch eine alte Antwort liefern, obwohl die autoritative Zone geändert wurde. Monitoring sollte deshalb zwischen autoritativer Abweichung und noch gültigem Cache-Zustand unterscheiden. Für kritische Namen sind zusätzlich synthetische Abfragen aus passenden Netzwerkpositionen sinnvoll.\u003c/p\u003e\n\u003cp\u003eOperativ braucht jede Abweichung eine Klassifikation: absichtlich, temporär oder fehlerhaft. Ohne diese Einordnung entstehen entweder unnötige Eskalationen oder übersehene DNS-Fehler. Traffic- und Usage-Statistiken sowie Backend Health Checks der ayedo Edge Cloud können die DNS-Kontrolle ergänzen, ersetzen aber nicht den Vergleich der tatsächlich veröffentlichten Antworten.\u003c/p\u003e\n\u003ch2 id=\"praxis--und-betriebsszenario\"\u003ePraxis- und Betriebsszenario\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt eine API intern über eine private Zieladresse und extern über die ayedo Edge Cloud. Beide Auflösungswege verwenden denselben Namen, aber unterschiedliche Ziele. Bei einem Backend-Wechsel wird nur der externe Record aktualisiert. Externe Requests erreichen das neue Backend, interne Systeme weiterhin das alte. Die Anwendung wirkt deshalb abhängig vom Zugriffsweg unterschiedlich verfügbar.\u003c/p\u003e\n\u003cp\u003eEin belastbares Modell führt den Dienstzustand zentral, erzeugt daraus die zulässigen internen und externen Records und markiert die unterschiedlichen Ziele als erwartete Abweichung. Vor der Veröffentlichung prüft ein automatisierter Vergleich beide Zonen. Nach der Änderung testen interne und externe Resolver die autoritativen Antworten; erst danach beginnt die kontrollierte Entfernung des alten Ziels. So wird aus einer manuellen Doppelpflege ein nachvollziehbarer Änderungsprozess.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"müssen-internal-zones-und-external-zones-immer-identisch-sein\"\u003eMüssen Internal Zones und External Zones immer identisch sein?\u003c/h3\u003e\n\u003cp\u003eNein. Unterschiedliche Ziele oder fehlende Records können fachlich erforderlich sein. Entscheidend ist, dass jede Abweichung beabsichtigt, dokumentiert und durch Regeln überprüfbar ist.\u003c/p\u003e\n\u003ch3 id=\"ist-dns-zonensynchronisierung-gleichbedeutend-mit-zonentransfer\"\u003eIst DNS-Zonensynchronisierung gleichbedeutend mit Zonentransfer?\u003c/h3\u003e\n\u003cp\u003eNein. Zonentransfer beschreibt die technische Replikation von Zonendaten. Synchronisierung umfasst zusätzlich Sichtbarkeitsregeln, Änderungsprozesse, Validierung und die Bewertung erlaubter Unterschiede.\u003c/p\u003e\n\u003ch3 id=\"welche-rolle-spielt-die-ayedo-edge-cloud\"\u003eWelche Rolle spielt die ayedo Edge Cloud?\u003c/h3\u003e\n\u003cp\u003eSie kann öffentliche DNS-Auflösung und den Edge-Einstieg für Anwendungen und APIs bereitstellen. Interne Auflösungswege und die fachliche Konsistenz der Zonendaten müssen in das übergreifende Betriebsmodell integriert werden.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eDNS-Konsistenz bedeutet nicht, Internal Zones und External Zones blind zu spiegeln. Sie bedeutet, gemeinsame Dienstinformationen eindeutig zu verwalten, Sichtbarkeitsunterschiede bewusst zu modellieren und jede Änderung gegen erwartete Antworten zu prüfen. Für die ayedo Edge Cloud ist diese Trennung besonders relevant, weil öffentliche DNS-Auflösung und Edge-Traffic einerseits, interne Namensauflösung andererseits unterschiedlichen Betriebszielen folgen. Ein kontrolliertes Synchronisationsmodell verhindert, dass daraus widersprüchliche Anwendungen und schwer erklärbare Störungen entstehen.\u003c/p\u003e\n",
      "summary": "\nTL;DR Getrennte Internal Zones und External Zones lösen unterschiedliche Sichtbarkeits- und Sicherheitsanforderungen, erzeugen aber ein erhebliches Konsistenzrisiko. Eine belastbare DNS-Zonensynchronisierung benötigt deshalb klare Datenverantwortung, kontrollierte Änderungsprozesse, automatisierte Vergleiche und definierte Ausnahmen. Entscheidend ist nicht identischer Inhalt, sondern widerspruchsfreie Antworten je Auflösungsweg.\nEinleitung Die häufigste Fehlannahme bei getrennten DNS-Zonen lautet: Wenn interne und öffentliche Auflösungen unterschiedliche Antworten liefern, sei das automatisch ein Fehler. Tatsächlich dürfen Internal Zones und External Zones bewusst voneinander abweichen. Problematisch wird es, wenn diese Abweichungen unbeabsichtigt entstehen oder dieselbe Anwendung unter gleichem Namen auf inkonsistente Ziele zeigt. Dann treffen Nutzer, Monitoring, Automatisierung und externe Clients auf unterschiedliche Realitäten. Eine DNS-Zonensynchronisierung muss daher nicht einfach Datensätze kopieren. Sie muss festlegen, welche Informationen geteilt werden, welche Sichtbarkeit gilt und wie Änderungen kontrolliert in beide Zonen gelangen.\n",
      "image": "https://ayedo.de/internal-und-external-zones-konsistent-synchronisieren.png",
      "date_published": "2026-09-02T14:04:41Z",
      "date_modified": "2026-09-02T14:04:41Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["automation","security","operations","development","kubernetes"],
      "language": "de"
    },{
      "id": "https://ayedo.de/posts/multi-provider-dns-fur-resiliente-edge-infrastrukturen/",
      "url": "https://ayedo.de/posts/multi-provider-dns-fur-resiliente-edge-infrastrukturen/",
      "title": "Multi-Provider-DNS für resiliente Edge-Infrastrukturen",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/multi-provider-dns-fur-resiliente-edge-infrastrukturen/multi-provider-dns-fur-resiliente-edge-infrastrukturen.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eMulti-Provider-DNS verteilt die autoritative DNS-Ebene auf mehrere voneinander unabhängige Infrastrukturen. Dadurch sinkt das Risiko, dass ein einzelner Ausfall die Namensauflösung und damit den Zugang zu Anwendungen unterbricht. Gleichzeitig steigen Anforderungen an Zonensynchronisierung, Verantwortlichkeiten, Tests und die Bewertung widersprüchlicher DNS-Zustände.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eDNS wird in vielen Edge-Architekturen als statische Basiskomponente behandelt. Das ist riskant: Fällt die einzige autoritative DNS-Infrastruktur aus oder wird eine Zone fehlerhaft aktualisiert, können Clients Anwendungen nicht mehr zuverlässig erreichen – selbst wenn die Backends vollständig verfügbar sind. Multi-Provider-DNS reduziert dieses Abhängigkeitsrisiko, indem autoritative Nameserver auf getrennte Betreiber und Infrastrukturen verteilt werden. Die Maßnahme ist jedoch kein automatisches Failover für jede Störung. Sie erhöht die Resilienz nur dann, wenn Delegation, Zonensynchronisierung und Änderungsprozesse konsistent gestaltet sind. Entscheidend ist daher nicht die Anzahl der DNS-Anbieter, sondern die Qualität der technischen und organisatorischen Trennung.\u003c/p\u003e\n\u003ch2 id=\"1-welche-ausfallrisiken-multi-provider-dns-reduziert\"\u003e1. Welche Ausfallrisiken Multi-Provider-DNS reduziert\u003c/h2\u003e\n\u003cp\u003eBei einer Single-Provider-DNS-Architektur konzentrieren sich mehrere Risiken an einer Stelle: Infrastrukturfehler, Routing-Probleme, Konfigurationsfehler, fehlerhafte Deployments oder eingeschränkte Erreichbarkeit der Managementsysteme. Sind alle autoritativen Nameserver von derselben Plattform abhängig, kann ein Ausfall dieser Plattform die gesamte Zone betreffen. Die Backends bleiben dann zwar online, sind aber für viele Clients nicht mehr auffindbar.\u003c/p\u003e\n\u003cp\u003eMulti-Provider-DNS verteilt die autoritative Antwortfähigkeit auf mehrere DNS-Infrastrukturen. Ein Fehler bei einem Betreiber muss nicht zwangsläufig die Namensauflösung unterbrechen, sofern Resolver weiterhin mindestens einen erreichbaren autoritativen Nameserver nutzen können. Das schützt insbesondere vor providerweiten Störungen und reduziert die Abhängigkeit von einer einzelnen Betriebsorganisation.\u003c/p\u003e\n\u003cp\u003eNicht gelöst werden damit Fehler in der Zone selbst. Eine falsche IP-Adresse, ein zu kurzer oder zu langer TTL-Wert oder eine fehlerhafte Delegation kann an mehrere Provider verteilt werden und den Ausfall sogar konsistent reproduzieren. Multi-Provider-DNS erhöht deshalb die Infrastrukturresilienz, ersetzt aber keine kontrollierte Konfigurationsqualität.\u003c/p\u003e\n\u003ch2 id=\"2-zuständigkeiten-delegation-ist-keine-zonensynchronisierung\"\u003e2. Zuständigkeiten: Delegation ist keine Zonensynchronisierung\u003c/h2\u003e\n\u003cp\u003eFür eine belastbare Architektur müssen zwei Ebenen getrennt betrachtet werden. Die Delegation beim übergeordneten Nameserver legt fest, welche autoritativen Nameserver für eine Domain zuständig sind. Die Zonendaten bestimmen anschließend, welche Antworten diese Nameserver liefern. Mehrere NS-Einträge in der Delegation schaffen allein noch keine konsistente Multi-Provider-Architektur.\u003c/p\u003e\n\u003cp\u003eDie Zonen müssen zwischen den beteiligten Providern synchron gehalten werden. Dafür braucht es einen definierten führenden Änderungsprozess, klare Verantwortlichkeiten und eine technische Prüfung, ob alle autoritativen Quellen denselben Stand ausliefern. Änderungen sollten nicht unabhängig in mehreren Portalen erfolgen. Sonst entstehen divergierende A- und AAAA-Records, unterschiedliche CNAME-Ketten oder widersprüchliche TTLs.\u003c/p\u003e\n\u003cp\u003eAuch die Zuständigkeit für den Failover muss eindeutig sein. DNS kann abhängig von TTLs und Resolver-Caches nur verzögert wirksam werden. Ein Anbieterwechsel bei einem Ausfall ist daher nicht mit einem sofortigen Umschalten auf Netzwerkebene gleichzusetzen. Die Edge-Plattform kann Traffic anschließend an verfügbare Backends verteilen, aber sie kann nicht bereits gecachte DNS-Antworten zurückholen.\u003c/p\u003e\n\u003ch2 id=\"3-multi-provider-dns-im-kontext-einer-edge-plattform\"\u003e3. Multi-Provider-DNS im Kontext einer Edge-Plattform\u003c/h2\u003e\n\u003cp\u003eEine Edge-Plattform verbindet DNS mit weiteren Funktionen des öffentlichen Traffic-Eingangs. Bei der ayedo Edge Cloud gehören Anycast DNS und Multi-Provider-DNS zu diesem Zusammenhang. Die DNS-Ebene kann damit providerübergreifend betrachtet werden, während die Edge zusätzlich Routing, Schutz und Verteilung des eingehenden Traffics übernimmt. Diese Aufgaben sollten architektonisch nicht mit der Compute-Infrastruktur vermischt werden.\u003c/p\u003e\n\u003cp\u003eFür Unternehmen mit eigenen oder bei anderen Providern betriebenen \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n Clustern ist diese Trennung besonders relevant. Die Anwendung muss nicht an den DNS- oder Compute-Betrieb eines einzigen Anbieters gekoppelt werden. Die ayedo Edge Cloud kann als öffentlicher Eingang vor solchen Backends eingesetzt werden; Kubernetes ist dabei nicht auf ayedo Managed Kubernetes beschränkt.\u003c/p\u003e\n\u003cp\u003eDie eigene Netzwerk-Infrastruktur und das eigene Autonomous System der ayedo Edge Cloud sind für die Resilienzbetrachtung ebenfalls relevant, weil die Edge nicht ausschließlich als Funktion innerhalb eines einzelnen Compute-Clusters verstanden wird. Die verteilte Multi-PoP-Architektur und das Aktiv-Aktiv-Prinzip adressieren die Erreichbarkeit der Edge selbst. Multi-Provider-DNS ergänzt diese Perspektive, indem die autoritative Namensauflösung nicht vollständig von einer einzelnen DNS-Infrastruktur abhängt.\u003c/p\u003e\n\u003ch2 id=\"4-die-betriebliche-komplexität-als-gegenleistung\"\u003e4. Die betriebliche Komplexität als Gegenleistung\u003c/h2\u003e\n\u003cp\u003eJede zusätzliche DNS-Infrastruktur erweitert die Fehlerdomäne – aber auch die Betriebsfläche. Teams müssen prüfen, ob alle Provider dieselben Records, Delegationsanforderungen und Sicherheitsparameter verwenden. Änderungen an Domains, Subdomains oder Routing-Zielen benötigen einen Prozess, der technische Validierung und nachvollziehbare Freigaben umfasst. Ohne diesen Prozess steigt die Wahrscheinlichkeit, dass ein Ausfall durch inkonsistente Daten verschärft wird.\u003c/p\u003e\n\u003cp\u003eMonitoring muss außerdem mehrere Perspektiven abdecken. Eine Zone kann bei einem Provider korrekt antworten, während ein anderer veraltete Daten ausliefert. Sinnvoll sind daher autoritative Abfragen gegen jeden Nameserver, Prüfungen aus unterschiedlichen Netzen sowie Tests der tatsächlich erwarteten Antworten. Auch die Erreichbarkeit der Nameserver und die korrekte Delegation gehören in regelmäßige Betriebsprüfungen.\u003c/p\u003e\n\u003cp\u003eOrganisatorisch muss geklärt sein, wer Änderungen auslöst, wer sie freigibt und wer bei widersprüchlichen Antworten entscheidet. Wirtschaftlich entstehen zusätzliche Betriebs- und Integrationskosten. Diese sind dann gerechtfertigt, wenn DNS-Ausfälle hohe Folgekosten verursachen oder eine einzelne Providerabhängigkeit nicht zum Risikoprofil des Unternehmens passt. Multi-Provider-DNS ist damit eine bewusste Resilienzentscheidung, kein kostenloser Standardbaustein.\u003c/p\u003e\n\u003ch2 id=\"praxis--und-betriebsszenario\"\u003ePraxis- und Betriebsszenario\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt eine API auf mehreren \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n Clustern bei unterschiedlichen Providern. Die autoritative Zone liegt zunächst vollständig bei einem DNS-Anbieter. Während eines Ausfalls bleiben die Cluster erreichbar, neue Clients können den API-Endpunkt jedoch nicht zuverlässig auflösen. In einer Multi-Provider-Architektur werden die autoritativen Nameserver auf getrennte DNS-Infrastrukturen verteilt und die Zone über einen kontrollierten Prozess synchronisiert.\u003c/p\u003e\n\u003cp\u003eVor dem produktiven Einsatz prüft das Team, ob beide Provider identische Antworten liefern, wie TTLs das Umschalten beeinflussen und ob ein einzelner Anbieter unabhängig deaktiviert werden kann. Die ayedo Edge Cloud kann anschließend als vorgelagerte Edge für die API dienen. Fällt ein Backend aus, greifen Edge-seitige Health Checks und Failover; fällt eine DNS-Infrastruktur aus, bleibt die Namensauflösung über die verbleibenden autoritativen Quellen möglich.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"ersetzt-multi-provider-dns-dns-failover\"\u003eErsetzt Multi-Provider-DNS DNS-Failover?\u003c/h3\u003e\n\u003cp\u003eNein. Es reduziert die Abhängigkeit von einer einzelnen autoritativen Infrastruktur. Das Umschalten von Traffic, Backend Health Checks und DNS-Caching sind getrennte Mechanismen und müssen gemeinsam geplant werden.\u003c/p\u003e\n\u003ch3 id=\"wie-viele-dns-provider-sind-sinnvoll\"\u003eWie viele DNS-Provider sind sinnvoll?\u003c/h3\u003e\n\u003cp\u003eEine feste Anzahl ist nicht allgemein sinnvoll. Maßgeblich sind das Ausfallrisiko, die gewünschte Unabhängigkeit, die Synchronisierungsfähigkeit und der zusätzliche Betriebsaufwand.\u003c/p\u003e\n\u003ch3 id=\"ist-multi-provider-dns-nur-für-kubernetes-relevant\"\u003eIst Multi-Provider-DNS nur für Kubernetes relevant?\u003c/h3\u003e\n\u003cp\u003eNein. Die Resilienz betrifft die autoritative Namensauflösung für öffentlich erreichbare Anwendungen und APIs unabhängig davon, ob die Backends auf \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n, virtuellen Maschinen oder anderen Plattformen laufen.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eMulti-Provider-DNS reduziert ein konkretes Risiko: die Abhängigkeit der autoritativen Namensauflösung von einer einzelnen DNS-Infrastruktur. Der Gewinn entsteht jedoch nur durch konsistente Zonendaten, getestete Delegation und klare Betriebsverantwortung. Für Edge-Architekturen ist die Trennung besonders wichtig, weil DNS, öffentlicher Traffic-Eingang und Backend-Betrieb unterschiedliche Fehlerdomänen bilden. Die ayedo Edge Cloud ordnet Multi-Provider-DNS in eine solche Edge-Plattform ein und verbindet die DNS-Perspektive mit verteilter, aktiv-aktiver Traffic-Verarbeitung vor den Backends.\u003c/p\u003e\n",
      "summary": "\nTL;DR Multi-Provider-DNS verteilt die autoritative DNS-Ebene auf mehrere voneinander unabhängige Infrastrukturen. Dadurch sinkt das Risiko, dass ein einzelner Ausfall die Namensauflösung und damit den Zugang zu Anwendungen unterbricht. Gleichzeitig steigen Anforderungen an Zonensynchronisierung, Verantwortlichkeiten, Tests und die Bewertung widersprüchlicher DNS-Zustände.\nEinleitung DNS wird in vielen Edge-Architekturen als statische Basiskomponente behandelt. Das ist riskant: Fällt die einzige autoritative DNS-Infrastruktur aus oder wird eine Zone fehlerhaft aktualisiert, können Clients Anwendungen nicht mehr zuverlässig erreichen – selbst wenn die Backends vollständig verfügbar sind. Multi-Provider-DNS reduziert dieses Abhängigkeitsrisiko, indem autoritative Nameserver auf getrennte Betreiber und Infrastrukturen verteilt werden. Die Maßnahme ist jedoch kein automatisches Failover für jede Störung. Sie erhöht die Resilienz nur dann, wenn Delegation, Zonensynchronisierung und Änderungsprozesse konsistent gestaltet sind. Entscheidend ist daher nicht die Anzahl der DNS-Anbieter, sondern die Qualität der technischen und organisatorischen Trennung.\n",
      "image": "https://ayedo.de/multi-provider-dns-fur-resiliente-edge-infrastrukturen.png",
      "date_published": "2026-09-02T14:04:41Z",
      "date_modified": "2026-09-02T14:04:41Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["cloud-native","software-delivery","operations","hosting","kubernetes"],
      "language": "de"
    },{
      "id": "https://ayedo.de/posts/edge-loadbalancing-fur-multi-cloud-backends-entwerfen/",
      "url": "https://ayedo.de/posts/edge-loadbalancing-fur-multi-cloud-backends-entwerfen/",
      "title": "Edge Loadbalancing für Multi-Cloud-Backends entwerfen",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/edge-loadbalancing-fur-multi-cloud-backends-entwerfen/edge-loadbalancing-fur-multi-cloud-backends-entwerfen.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eMulti-Cloud Loadbalancing ist mehr als die Verteilung von Anfragen auf mehrere Provider. Entscheidend sind eine zentrale Routing-Logik, verborgen gehaltene Backends, belastbare Health Checks und ein Betrieb ohne Abhängigkeit von einzelnen Cloud-Netzwerken. Eine unabhängige Edge-Schicht schafft dafür einen einheitlichen Kontrollpunkt vor heterogenen Infrastrukturen.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eEin Loadbalancer pro Cloud löst zunächst nur ein lokales Problem: Er verteilt Traffic innerhalb eines Providers. Sobald Anwendungen auf mehrere Clouds oder Provider verteilt werden, entstehen jedoch mehrere öffentliche Einstiegspunkte, unterschiedliche Routingmodelle und voneinander getrennte Betriebsprozesse. Diese Struktur erschwert Failover, Sicherheitskontrollen und Änderungen an der Backend-Topologie.\u003c/p\u003e\n\u003cp\u003eDie zentrale Architekturentscheidung lautet deshalb: Soll jede Cloud ihren eigenen Traffic verwalten, oder übernimmt eine providerunabhängige Edge-Schicht den öffentlichen Eingang? Für Multi-Cloud Loadbalancing ist diese Frage wesentlich. Sie bestimmt, wo Routing, TLS-Terminierung, Schutzmechanismen und Backend-Auswahl stattfinden – und welche Teile der Infrastruktur nach außen sichtbar bleiben.\u003c/p\u003e\n\u003ch2 id=\"1-providergebundene-loadbalancer-und-zentrale-edge-schicht\"\u003e1. Providergebundene Loadbalancer und zentrale Edge-Schicht\u003c/h2\u003e\n\u003cp\u003eProvidergebundene Loadbalancer sind eng mit dem jeweiligen Netzwerk, den IP-Adressen und den Betriebsmodellen einer Cloud verbunden. Das ist innerhalb eines einzelnen Clusters oder einer Region effizient. Über mehrere Provider hinweg müssen Unternehmen jedoch zusätzliche DNS-Mechanismen, globale Routinglogik oder eigene Failover-Prozesse etablieren. Jede Plattform bringt dabei eigene Konfigurationen und Beobachtungspunkte mit.\u003c/p\u003e\n\u003cp\u003eEine zentrale Edge-Schicht entkoppelt den öffentlichen Traffic-Eingang von den Backends. Sie kann Anfragen anhand von IP, Port, Hostname, Pfad oder anderen L7-Merkmalen an unterschiedliche Zielumgebungen verteilen. Für TCP- oder UDP-Dienste bleibt L4 relevant, wenn keine HTTP-Informationen verfügbar sind oder eine transparente Weiterleitung erforderlich ist.\u003c/p\u003e\n\u003cp\u003eDie ayedo Edge Cloud stellt dafür Anycast-basiertes L4- und L7-Loadbalancing bereit. Ihre verteilte Multi-PoP-Architektur und das Aktiv-Aktiv-Prinzip bilden einen einheitlichen Edge-Einstieg, während die eigentlichen Backends in unterschiedlichen Clouds oder bei verschiedenen Providern betrieben werden können.\u003c/p\u003e\n\u003ch2 id=\"2-backend-cloaking-als-architekturgrenze\"\u003e2. Backend Cloaking als Architekturgrenze\u003c/h2\u003e\n\u003cp\u003eMulti-Cloud Loadbalancing betrifft nicht nur die Verteilung, sondern auch die Sichtbarkeit der Zielsysteme. Werden öffentliche Cloud-Loadbalancer oder direkte Backend-Adressen in DNS, Zertifikaten oder Fehlermeldungen sichtbar, vergrößert sich die Angriffsfläche. Außerdem werden Providerwechsel und Topologieänderungen zu externen Abhängigkeiten.\u003c/p\u003e\n\u003cp\u003eBackend Cloaking setzt an dieser Grenze an: Clients kommunizieren mit der Edge, nicht mit den eigentlichen Ursprungsdiensten. Die Edge übernimmt die öffentliche Erreichbarkeit und leitet den Traffic über definierte Backend-Verbindungen weiter. Dadurch bleiben interne Adressen und die konkrete Verteilung auf Provider verborgen. Das ersetzt keine Absicherung der Backends, reduziert aber deren direkte Exponierung und vereinfacht Netzwerkregeln.\u003c/p\u003e\n\u003cp\u003eFür den Betrieb bedeutet das: Backends müssen nur Verbindungen aus den vorgesehenen Edge-Pfaden akzeptieren. TLS kann an der Edge terminiert werden, während nachgelagerte Verschlüsselung abhängig von Schutzbedarf und Backend-Architektur gestaltet wird. Proxy Protocol kann zusätzliche Informationen für nachgelagerte Systeme transportieren, sofern diese es korrekt verarbeiten.\u003c/p\u003e\n\u003ch2 id=\"3-routing-health-checks-und-failover-über-providergrenzen\"\u003e3. Routing, Health Checks und Failover über Providergrenzen\u003c/h2\u003e\n\u003cp\u003eEine zentrale Steuerung ist nur so zuverlässig wie ihre Zustandsinformationen. Health Checks müssen deshalb nicht lediglich prüfen, ob ein Port erreichbar ist. Für L7-Dienste sind HTTP-Status, Pfade oder definierte Antwortbedingungen relevant. Bei L4-Diensten stehen Erreichbarkeit und Verbindungsaufbau im Vordergrund. Die Prüfungen müssen außerdem zu den tatsächlichen Fehlerbildern passen: Ein erreichbarer Prozess kann fachlich trotzdem nicht verfügbar sein.\u003c/p\u003e\n\u003cp\u003eÜber mehrere Provider entstehen zusätzliche Routingfragen. Soll Traffic aktiv auf beide Backends verteilt werden? Ist ein Provider primär und der andere nur Failover? Wie wird mit teilweisen Störungen umgegangen, bei denen nur eine Region, ein Service oder ein Netzwerkpfad betroffen ist? Zu aggressive Umschaltungen können ebenso problematisch sein wie zu späte Reaktionen.\u003c/p\u003e\n\u003cp\u003eDie ayedo Edge Cloud unterstützt Backend Health Checks und Failover. Damit lässt sich die Auswahl der Zielsysteme an deren Verfügbarkeit koppeln, ohne DNS-Änderungen als primäres Umschaltinstrument zu verwenden. Anycast DNS und Multi-Provider-DNS können ergänzend relevant sein, ersetzen aber nicht die Prüfung und Steuerung der eigentlichen Backend-Ziele.\u003c/p\u003e\n\u003ch2 id=\"4-betriebsmodell-und-provider-unabhängigkeit\"\u003e4. Betriebsmodell und Provider-Unabhängigkeit\u003c/h2\u003e\n\u003cp\u003eEine zentrale Edge verändert den Verantwortungszuschnitt. Die Cloud- oder Plattformteams betreiben weiterhin Anwendungen, Cluster und interne Netzwerke. Die Edge verantwortet dagegen den öffentlichen Eingang, Routing, Schutz, TLS-Terminierung und die Lastverteilung. Diese Trennung verhindert, dass jeder Provider seine eigene Version des externen Zugangs modelliert.\u003c/p\u003e\n\u003cp\u003eProvider-Unabhängigkeit entsteht jedoch nicht automatisch durch zwei Backends. Routingregeln, Zertifikate, IP-Strategien, Monitoring und Änderungsprozesse müssen providerübergreifend definiert werden. Ebenso wichtig sind Rückwege, Quell-IP-Verhalten, Connection Draining und die Frage, ob eine Anwendung Zustände lokal hält. Ein globaler Loadbalancer kann keine Anwendungssynchronisation ersetzen.\u003c/p\u003e\n\u003cp\u003eFür Unternehmen ist das auch eine Kosten- und Organisationsfrage. Mehrere providergebundene Loadbalancer verursachen parallele Konfigurationen und Fachwissen. Eine zentrale Edge kann diese Funktionen bündeln, führt aber eine zusätzliche Plattform als kritische Betriebskomponente ein. Die ayedo Edge Cloud nutzt dafür eigene Netzwerk-Infrastruktur und ein eigenes Autonomous System. Sie kann mit ayedo Managed \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n ebenso wie mit selbst betriebenen oder bei anderen Providern laufenden Kubernetes-Clustern eingesetzt werden.\u003c/p\u003e\n\u003ch2 id=\"praxis--und-betriebsszenario\"\u003ePraxis- und Betriebsszenario\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt eine API in einem eigenen \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n-Cluster und hält eine zweite Instanz bei einem Cloud-Provider vor. Beide Umgebungen besitzen zunächst eigene öffentliche Loadbalancer. Bei einem Ausfall muss DNS angepasst werden; während der Umschaltung bleiben alte Verbindungen, Caches und Monitoringzustände uneinheitlich.\u003c/p\u003e\n\u003cp\u003eIn einer zentralen Edge-Architektur zeigt der öffentliche DNS-Name auf die Edge. L7-Regeln leiten Requests an beide Backends, Health Checks erkennen die Verfügbarkeit, und Failover kann ohne Änderung der Client-Endpunkte erfolgen. Die Backends sind nicht direkt öffentlich adressiert. Für nicht HTTP-basierte Dienste wird ein separater L4-Pfad verwendet. Der zusätzliche zentrale Kontrollpunkt vereinfacht den Betrieb, erfordert aber klare Zuständigkeiten und Tests für Routing, Rückwege und Ausfallszenarien.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"ist-multi-cloud-loadbalancing-immer-besser-als-ein-loadbalancer-pro-provider\"\u003eIst Multi-Cloud Loadbalancing immer besser als ein Loadbalancer pro Provider?\u003c/h3\u003e\n\u003cp\u003eNein. Für eine einzelne Cloud kann die native Lösung ausreichen. Eine zentrale Edge wird relevant, wenn ein einheitlicher öffentlicher Einstieg, providerübergreifendes Failover oder einheitliche Schutz- und Routingregeln erforderlich sind.\u003c/p\u003e\n\u003ch3 id=\"wann-sollte-l4-statt-l7-eingesetzt-werden\"\u003eWann sollte L4 statt L7 eingesetzt werden?\u003c/h3\u003e\n\u003cp\u003eL4 eignet sich für TCP- oder UDP-Dienste ohne verwertbare Anwendungsinformationen. L7 ist sinnvoll, wenn HTTP-/HTTPS-Merkmale wie Hostname oder Pfad in die Routingentscheidung einfließen sollen.\u003c/p\u003e\n\u003ch3 id=\"verhindert-backend-cloaking-den-direkten-backend-zugriff-vollständig\"\u003eVerhindert Backend Cloaking den direkten Backend-Zugriff vollständig?\u003c/h3\u003e\n\u003cp\u003eNein. Es reduziert die öffentliche Sichtbarkeit. Netzwerke, Firewalls und Dienste müssen weiterhin so konfiguriert sein, dass nur autorisierte Verbindungen akzeptiert und administrative Zugänge separat geschützt werden.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eEine providergebundene Loadbalancing-Lösung optimiert den lokalen Betrieb, bildet aber Multi-Cloud-Anforderungen nur begrenzt ab. Eine zentrale Edge-Schicht schafft einen konsistenten öffentlichen Eingang, verbirgt Backend-Strukturen und bündelt Routing, Health Checks, TLS und Schutzfunktionen. Entscheidend bleiben korrekte L4-/L7-Entscheidungen, realistische Failover-Tests und ein klares Betriebsmodell. Die ayedo Edge Cloud ist in diesem Zusammenhang als providerunabhängige Edge-Plattform relevant – nicht als bloßer Loadbalancer vor einem einzelnen \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n-Cluster.\u003c/p\u003e\n",
      "summary": "\nTL;DR Multi-Cloud Loadbalancing ist mehr als die Verteilung von Anfragen auf mehrere Provider. Entscheidend sind eine zentrale Routing-Logik, verborgen gehaltene Backends, belastbare Health Checks und ein Betrieb ohne Abhängigkeit von einzelnen Cloud-Netzwerken. Eine unabhängige Edge-Schicht schafft dafür einen einheitlichen Kontrollpunkt vor heterogenen Infrastrukturen.\nEinleitung Ein Loadbalancer pro Cloud löst zunächst nur ein lokales Problem: Er verteilt Traffic innerhalb eines Providers. Sobald Anwendungen auf mehrere Clouds oder Provider verteilt werden, entstehen jedoch mehrere öffentliche Einstiegspunkte, unterschiedliche Routingmodelle und voneinander getrennte Betriebsprozesse. Diese Struktur erschwert Failover, Sicherheitskontrollen und Änderungen an der Backend-Topologie.\n",
      "image": "https://ayedo.de/edge-loadbalancing-fur-multi-cloud-backends-entwerfen.png",
      "date_published": "2026-09-02T13:58:52Z",
      "date_modified": "2026-09-02T13:58:52Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["cloud","cloud-native","security","operations","kubernetes"],
      "language": "de"
    },{
      "id": "https://ayedo.de/posts/failover-und-health-checks-fur-backend-pools-planen/",
      "url": "https://ayedo.de/posts/failover-und-health-checks-fur-backend-pools-planen/",
      "title": "Failover und Health Checks für Backend-Pools planen",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/failover-und-health-checks-fur-backend-pools-planen/failover-und-health-checks-fur-backend-pools-planen.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eLoadbalancing Failover ist keine automatische Garantie für Hochverfügbarkeit. Entscheidend ist, welche Fehler ein Health Check erkennt, wie schnell er reagiert und welche Ziele danach noch erreichbar sind. Eine belastbare Failover Architektur trennt technische Erreichbarkeit von fachlicher Betriebsfähigkeit und definiert das Verhalten für L4- und L7-Traffic eindeutig.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eEin Backend kann erreichbar sein und trotzdem keine Anfragen verarbeiten. Ein offener TCP-Port sagt wenig darüber aus, ob eine Anwendung Datenbankverbindungen aufbauen, Requests vollständig beantworten oder ihre fachlichen Abhängigkeiten bedienen kann. Genau an dieser Stelle scheitern viele Failover-Konzepte: Der Loadbalancer erkennt nur den Ausfall des Prozesses, nicht den Ausfall der Anwendung.\u003c/p\u003e\n\u003cp\u003eBackend Health Checks müssen deshalb zur Fehlerdomäne des jeweiligen Services passen. Gleichzeitig braucht Failover klare Regeln: Wann gilt ein Ziel als nicht verfügbar? Auf welchen Pool wird ausgewichen? Wie wird verhindert, dass ein kurzzeitiger Fehler eine Failover-Kaskade auslöst? Diese Fragen gehören zum Betriebsdesign und nicht erst in die Störungsanalyse.\u003c/p\u003e\n\u003ch2 id=\"1-health-checks-bewerten-unterschiedliche-verfügbarkeiten\"\u003e1. Health Checks bewerten unterschiedliche Verfügbarkeiten\u003c/h2\u003e\n\u003cp\u003eEin Health Check kann auf verschiedenen Ebenen ansetzen. Bei einem L4-Service wird typischerweise geprüft, ob eine TCP-Verbindung zu einer Adresse und einem Port aufgebaut werden kann. Das erkennt etwa einen nicht erreichbaren Host oder einen nicht laufenden Listener. Für viele Anwendungen reicht dieser Check jedoch nicht aus: Ein Prozess kann Verbindungen akzeptieren, obwohl seine Request-Verarbeitung blockiert ist.\u003c/p\u003e\n\u003cp\u003eL7-Health-Checks prüfen dagegen das Verhalten eines HTTP- oder HTTPS-Endpunkts. Neben dem Statuscode können Pfad, Protokoll und Antwortverhalten relevant sein. Ein sinnvoller Prüfpunkt sollte eine für den Betrieb aussagekräftige Funktion abbilden, aber keine unnötig tiefen Abhängigkeiten aufrufen. Wird beispielsweise bei jedem Check ein komplexer Geschäftsprozess gestartet, kann der Check selbst zusätzliche Last erzeugen.\u003c/p\u003e\n\u003cp\u003eFür die Failover-Planung sind außerdem Fehlerintervalle, Wiederholungen und die Rückkehr eines Backends wichtig. Zu aggressive Prüfungen reagieren schnell, können bei kurzen Netzstörungen aber gesunde Ziele aus dem Pool entfernen. Zu großzügige Werte verlängern die Zeit, in der Traffic an ein bereits gestörtes Backend gelangt.\u003c/p\u003e\n\u003ch2 id=\"2-failover-braucht-definierte-fehler--und-rückkehrregeln\"\u003e2. Failover braucht definierte Fehler- und Rückkehrregeln\u003c/h2\u003e\n\u003cp\u003eFailover bedeutet nicht lediglich, Traffic an „ein anderes Backend“ zu senden. Zuerst muss festgelegt werden, welche Ziele zur gleichen Verfügbarkeitsdomäne gehören. Ein Pool kann mehrere Instanzen derselben Anwendung enthalten, alternativ können getrennte Pools für unterschiedliche Standorte, Cluster oder Provider vorgesehen werden. Diese Struktur bestimmt, wie viel Ausfall ein System tatsächlich toleriert.\u003c/p\u003e\n\u003cp\u003eEbenso wichtig ist die Rückkehr in den Normalbetrieb. Wenn ein Backend nach einem kurzen Fehler sofort wieder Traffic erhält, kann ein instabiler Dienst zwischen verfügbar und nicht verfügbar wechseln. Dieses Flapping erschwert die Diagnose und belastet zusätzlich die Anwendung. Eine kontrollierte Wiederaufnahme sollte deshalb erst erfolgen, wenn das Ziel wieder zuverlässig antwortet.\u003c/p\u003e\n\u003cp\u003eBei L4- und L7-Loadbalancing unterscheiden sich zudem die Folgen bestehender Verbindungen. Neue Verbindungen lassen sich leichter auf gesunde Ziele verteilen. Bereits etablierte Sessions können dagegen abbrechen oder an Zustandsabhängigkeiten scheitern. Failover muss daher berücksichtigen, ob die Anwendung stateless arbeitet, Sessions extern hält oder Verbindungszustände an ein bestimmtes Backend bindet.\u003c/p\u003e\n\u003ch2 id=\"3-failover-ist-teil-der-edge-architektur\"\u003e3. Failover ist Teil der Edge-Architektur\u003c/h2\u003e\n\u003cp\u003eDie ayedo Edge Cloud bewertet Backend-Ziele über Health Checks und kann Traffic innerhalb von Backend-Pools verteilen oder bei Ausfällen auf verfügbare Ziele ausweichen. Das gilt im Kontext ihres Anycast-basierten Layer-4- und Layer-7-Loadbalancings. Die Edge Cloud übernimmt dabei den öffentlichen Eingang und die Weiterleitung; die eigentlichen Anwendungen laufen weiterhin in der Compute-Infrastruktur.\u003c/p\u003e\n\u003cp\u003eDiese Trennung ist für die Failover Architektur entscheidend. Ein ausgefallener \u003ca href=\"/kubernetes/\"\u003eKubernetes-Pod\u003c/a\u003e\n, ein nicht erreichbarer Cluster oder ein gestörter Provider sind unterschiedliche Fehlerbilder. Die Edge kann den öffentlichen Traffic-Eingang und die Auswahl erreichbarer Backends steuern, ersetzt aber keine Redundanz innerhalb der Anwendung oder ihrer Datenhaltung. Ein zweiter Pool hilft nicht, wenn beide Pools dieselbe ausgefallene Datenbank verwenden.\u003c/p\u003e\n\u003cp\u003eDurch die verteilte Multi-PoP-Architektur und das Aktiv-Aktiv-Prinzip wird die Edge selbst nicht als einzelner Übergabepunkt betrachtet. Anycast-Routing, Backend Health Checks und Failover müssen dennoch gemeinsam geplant werden: Ein Ziel kann aus Sicht eines Edge-Standorts erreichbar sein, während ein anderer Pfad Fehler zeigt. Für den Betrieb sind deshalb zentrale Statistiken und klare Zustandsdefinitionen erforderlich.\u003c/p\u003e\n\u003ch2 id=\"4-fehlererkennung-muss-zum-ausfallverhalten-passen\"\u003e4. Fehlererkennung muss zum Ausfallverhalten passen\u003c/h2\u003e\n\u003cp\u003eEin guter Health Check beantwortet nicht die Frage „Lebt der Server?“, sondern „Kann dieses Ziel diese Art von Traffic derzeit sinnvoll verarbeiten?“. Für einen API-Endpunkt kann ein authentifizierungsfreier Readiness-Pfad geeignet sein. Für eine transaktionale Anwendung muss zusätzlich geprüft werden, ob kritische Abhängigkeiten verfügbar sind. Dabei ist zwischen Readiness, Liveness und echter Service-Verfügbarkeit zu unterscheiden.\u003c/p\u003e\n\u003cp\u003eFailover sollte außerdem nicht blind über alle Anfragen erfolgen. Bei nicht idempotenten Schreiboperationen kann ein Timeout unklar lassen, ob die Verarbeitung bereits gestartet oder abgeschlossen wurde. Ein Retry auf ein zweites Backend kann dann zu Doppelverarbeitung führen. Die Edge kann den Traffic weiterleiten, aber die Anwendung muss Wiederholbarkeit, Idempotenz und Fehlerantworten sauber definieren.\u003c/p\u003e\n\u003cp\u003eFür den Betrieb gehören daher folgende Fragen in das Design: Welche Fehler lösen Failover aus? Welche Antworten bleiben beim ursprünglichen Backend? Wie wird ein Pool vollständig ungesund behandelt? Und wie werden Fehlentscheidungen sichtbar? Ohne diese Regeln entsteht zwar technische Umschaltung, aber keine kontrollierte Hochverfügbarkeit.\u003c/p\u003e\n\u003ch2 id=\"betriebsszenario-primärer-cluster-und-ausweichpool\"\u003eBetriebsszenario: Primärer Cluster und Ausweichpool\u003c/h2\u003e\n\u003cp\u003eEine API läuft primär in einem \u003ca href=\"/kubernetes/\"\u003eKubernetes-Cluster\u003c/a\u003e\n und zusätzlich in einem getrennten Cluster bei einem anderen Provider. Beide Umgebungen werden als Backend-Ziele einer Edge-Konfiguration angebunden. Ein L7-Check prüft einen dedizierten Readiness-Endpunkt. Dieser bestätigt, dass die API Requests annehmen kann und ihre unmittelbar notwendigen Abhängigkeiten verfügbar sind.\u003c/p\u003e\n\u003cp\u003eFällt der primäre Pool aus, verteilt die Edge neue Requests an den Ausweichpool. Bestehende Verbindungen werden nicht automatisch fachlich fortgesetzt; Clients müssen mit Timeouts und Wiederholungen umgehen können. Vor der Aktivierung des Designs wird außerdem geprüft, ob beide Cluster dieselben Datenstände, Konfigurationen und Sicherheitsanforderungen erfüllen. Sonst verlagert das Failover den Ausfall lediglich an eine andere Stelle.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"sind-tcp-checks-für-backend-health-checks-ausreichend\"\u003eSind TCP-Checks für Backend Health Checks ausreichend?\u003c/h3\u003e\n\u003cp\u003eNur für die Erreichbarkeit eines Ports. Sie erkennen nicht zuverlässig, ob die Anwendung Requests verarbeiten kann. Für HTTP-Services ist ein passender L7-Check meist aussagekräftiger.\u003c/p\u003e\n\u003ch3 id=\"was-passiert-wenn-alle-backends-eines-pools-ausfallen\"\u003eWas passiert, wenn alle Backends eines Pools ausfallen?\u003c/h3\u003e\n\u003cp\u003eDas Verhalten muss vorab definiert werden, etwa eine Fehlerantwort oder ein Ausweichen auf einen separaten Pool. Ohne Regel bleibt der Ausfall zwar erkennbar, aber betrieblich unkontrolliert.\u003c/p\u003e\n\u003ch3 id=\"verhindert-failover-den-verlust-laufender-sessions\"\u003eVerhindert Failover den Verlust laufender Sessions?\u003c/h3\u003e\n\u003cp\u003eNein. Failover verteilt vor allem neue Verbindungen oder Requests neu. Session-Zustände, Wiederholungen und mögliche Doppelverarbeitung müssen von Anwendung und Client berücksichtigt werden.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eLoadbalancing Failover ist eine Betriebsentscheidung mit technischen, organisatorischen und wirtschaftlichen Folgen. Health Checks müssen die tatsächliche Verfügbarkeit eines Services bewerten, während Pools, Rückkehrregeln und Session-Verhalten das Ausfallrisiko begrenzen. Die ayedo Edge Cloud ordnet diese Mechanismen in ein Anycast-basiertes L4- und L7-Loadbalancing mit verteiltem Edge-Eingang ein. Hochverfügbarkeit entsteht jedoch erst durch das Zusammenspiel von Edge, Compute, Datenhaltung und belastbaren Betriebsprozessen.\u003c/p\u003e\n",
      "summary": "\nTL;DR Loadbalancing Failover ist keine automatische Garantie für Hochverfügbarkeit. Entscheidend ist, welche Fehler ein Health Check erkennt, wie schnell er reagiert und welche Ziele danach noch erreichbar sind. Eine belastbare Failover Architektur trennt technische Erreichbarkeit von fachlicher Betriebsfähigkeit und definiert das Verhalten für L4- und L7-Traffic eindeutig.\nEinleitung Ein Backend kann erreichbar sein und trotzdem keine Anfragen verarbeiten. Ein offener TCP-Port sagt wenig darüber aus, ob eine Anwendung Datenbankverbindungen aufbauen, Requests vollständig beantworten oder ihre fachlichen Abhängigkeiten bedienen kann. Genau an dieser Stelle scheitern viele Failover-Konzepte: Der Loadbalancer erkennt nur den Ausfall des Prozesses, nicht den Ausfall der Anwendung.\n",
      "image": "https://ayedo.de/failover-und-health-checks-fur-backend-pools-planen.png",
      "date_published": "2026-09-02T13:58:52Z",
      "date_modified": "2026-09-02T13:58:52Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["kubernetes","cloud-native","digital-sovereignty","software-delivery","platform"],
      "language": "de"
    },{
      "id": "https://ayedo.de/posts/l4-und-l7-im-vergleich-trade-offs-fur-den-betrieb/",
      "url": "https://ayedo.de/posts/l4-und-l7-im-vergleich-trade-offs-fur-den-betrieb/",
      "title": "L4 und L7 im Vergleich: Trade-offs für den Betrieb",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/l4-und-l7-im-vergleich-trade-offs-fur-den-betrieb/l4-und-l7-im-vergleich-trade-offs-fur-den-betrieb.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eL4- und L7-Loadbalancing unterscheiden sich nicht nur durch ihre Protokollebene, sondern vor allem durch ihren Betriebsaufwand. L4 ist meist einfacher und robuster, L7 bietet mehr Steuerungsmöglichkeiten, erzeugt aber höhere Anforderungen an Konfiguration, Beobachtbarkeit und Änderungsmanagement. Eine Edge-Plattform kann beide Ebenen gezielt kombinieren.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eDie falsche Loadbalancing-Ebene erzeugt häufig keinen sofortigen Fehler, sondern schleichende Betriebskomplexität. Wer HTTP-Anforderungen auf L4 behandelt, verliert Möglichkeiten für Routing und Protokolltransparenz. Wer jede Verbindung auf L7 verarbeitet, erhöht dagegen Konfigurationsumfang, Fehleroberfläche und Änderungsaufwand. Der entscheidende Vergleich lautet deshalb nicht „Welche Ebene ist leistungsfähiger?“, sondern: Welche Verarbeitung braucht die Anwendung, und welche Konsequenzen entstehen daraus im Betrieb? Für Platform- und Infrastrukturteams betrifft diese Entscheidung Konfiguration, Monitoring, Fehlersuche, Security und die Organisation von Releases.\u003c/p\u003e\n\u003ch2 id=\"1-konfiguration-verbindung-gegen-anfrage\"\u003e1. Konfiguration: Verbindung gegen Anfrage\u003c/h2\u003e\n\u003cp\u003eLayer 4 arbeitet auf Transportebene. Ein Loadbalancer verteilt TCP- oder UDP-Verbindungen, ohne den Inhalt einer HTTP-Anfrage zu interpretieren. Das reduziert die Zahl relevanter Konfigurationsparameter: Listener, Ports, Backends, Health Checks und Verteilungslogik stehen im Mittelpunkt. L4 eignet sich dadurch auch für Protokolle, die nicht HTTP-basiert sind oder deren Nutzdaten nicht an der Edge ausgewertet werden sollen.\u003c/p\u003e\n\u003cp\u003eLayer 7 verarbeitet dagegen Anwendungsprotokolle wie HTTP oder HTTPS. Routing nach Hostname, Pfad oder weiteren Request-Eigenschaften wird möglich. TLS kann an der Edge terminiert werden; zusätzlich lassen sich HTTP-Services mit einer \u003ca href=\"https://de.wikipedia.org/wiki/Web_Application_Firewall\" target=\"_blank\" rel=\"noopener\"\u003eWeb Application Firewall\u003c/a\u003e\n schützen. Diese Fähigkeiten sind technisch wertvoll, machen Konfigurationen aber stärker abhängig von Anwendung, URL-Struktur und Zertifikatsbetrieb.\u003c/p\u003e\n\u003cp\u003eFür den Betrieb bedeutet das: L4-Konfigurationen sind meist stabiler gegenüber Änderungen im Backend. L7-Konfigurationen müssen stärker mit API-Versionen, Domains und Routingregeln abgestimmt werden.\u003c/p\u003e\n\u003ch2 id=\"2-beobachtbarkeit-was-sichtbar-wird\"\u003e2. Beobachtbarkeit: Was sichtbar wird\u003c/h2\u003e\n\u003cp\u003eL4 liefert vor allem Infrastruktur- und Verbindungsmetriken: Erreichbarkeit, Verbindungsaufbau, Ports, Fehler beim Transport und die Verteilung auf Backends. Diese Sicht reicht aus, um Netzwerk- oder Backend-Ausfälle einzugrenzen. Sie erklärt jedoch nicht automatisch, warum ein bestimmter Request mit HTTP 404, 401 oder 503 beantwortet wurde.\u003c/p\u003e\n\u003cp\u003eL7 kann die Beobachtung näher an das Anwendungsverhalten führen. Statuscodes, Hostnames, Pfade und die Wirkung einzelner Routingregeln werden auswertbar. Dadurch lassen sich Fehlkonfigurationen zwischen Edge und Anwendung präziser unterscheiden. Gleichzeitig steigt die Gefahr, Metriken falsch zu interpretieren: Ein erreichbares Backend kann auf L4 gesund erscheinen, obwohl die Anwendung auf L7 fachlich nicht korrekt antwortet.\u003c/p\u003e\n\u003cp\u003eDie betriebliche Konsequenz ist eine andere Monitoring-Strategie. L4 benötigt starke Netzwerk- und Verbindungsmetriken. L7 braucht zusätzlich eine klare Zuordnung von Requests, Regeln, Health Checks und Backend-Antworten. Ohne diese Korrelation wird die detailliertere Sicht nicht automatisch zu besserer Fehlersuche.\u003c/p\u003e\n\u003ch2 id=\"3-fehlerbilder-und-zuständigkeiten\"\u003e3. Fehlerbilder und Zuständigkeiten\u003c/h2\u003e\n\u003cp\u003eBei L4 liegen Fehlerbilder häufig an klaren Grenzen: Der Listener ist nicht erreichbar, eine Verbindung wird abgewiesen, ein Backend antwortet nicht oder ein Health Check schlägt fehl. Die Ursache kann weiterhin komplex sein, aber die Verarbeitungskette bleibt vergleichsweise kurz. Ein Protokollfehler innerhalb der Anwendung ist für den L4-Loadbalancer nicht sichtbar.\u003c/p\u003e\n\u003cp\u003eL7 erweitert diese Kette. Eine Anfrage kann bereits an TLS, einer WAF-Regel, einer Host- oder Pfadregel, einer Authentifizierungslogik oder am Backend scheitern. Das verbessert den Schutz und die Steuerbarkeit, verteilt die Verantwortung aber auf mehr Komponenten. Bei einem Fehler muss geklärt werden, ob die Anfrage korrekt klassifiziert, verändert, blockiert oder weitergeleitet wurde.\u003c/p\u003e\n\u003cp\u003eEine Edge-Plattform sollte diese Ebenen deshalb nicht als konkurrierende Betriebsmodelle behandeln. Die ayedo Edge Cloud kombiniert Anycast-basiertes Layer-4- und Layer-7-Loadbalancing mit Health Checks, Failover und zentralen Edge-Funktionen. Damit kann L4 für Transport- und Protokollanforderungen genutzt werden, während HTTP-Anwendungen L7-Funktionen erhalten. Backend Cloaking begrenzt dabei die direkte Sichtbarkeit der eigentlichen Backends.\u003c/p\u003e\n\u003ch2 id=\"4-änderungsaufwand-und-architekturfolgen\"\u003e4. Änderungsaufwand und Architekturfolgen\u003c/h2\u003e\n\u003cp\u003eL4-Änderungen betreffen typischerweise Endpunkte, Ports, Backends oder Verteilungsregeln. Sie sind häufig unabhängig vom Applikationsrelease und lassen sich in standardisierten Plattformprozessen abbilden. Das ist besonders relevant, wenn mehrere Cluster oder Provider dieselbe öffentliche Erreichbarkeit bereitstellen sollen.\u003c/p\u003e\n\u003cp\u003eL7-Änderungen sind enger mit dem Lebenszyklus der Anwendung verbunden. Neue Domains, API-Pfade, TLS-Zertifikate, WAF-Ausnahmen oder Routingregeln benötigen Tests über die gesamte Request-Kette. Ein kleiner Regelkonflikt kann nur einen Pfad oder einen Mandanten betreffen und dadurch schwerer erkennbar sein als ein vollständiger L4-Ausfall.\u003c/p\u003e\n\u003cp\u003eAuch wirtschaftlich entsteht ein Unterschied: L7 reduziert den Bedarf an Logik in einzelnen Backends, erhöht aber den Aufwand für Governance, Tests und Verantwortungsabgrenzung. Die ayedo Edge Cloud kann dabei als providerunabhängige Edge-Schicht vor ayedo Managed \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n, eigenen Kubernetes-Clustern oder Clustern anderer Provider eingesetzt werden. Das trennt öffentliche Traffic-Verarbeitung und Compute-Verantwortung sauber.\u003c/p\u003e\n\u003ch2 id=\"praxisszenario-ein-dienst-zwei-verarbeitungsebenen\"\u003ePraxisszenario: Ein Dienst, zwei Verarbeitungsebenen\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt eine HTTP-API in einem \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n-Cluster und einen zusätzlichen TCP-Dienst für eine spezialisierte Anwendung. Die API benötigt TLS-Termination, host- und pfadbasiertes Routing sowie WAF-Schutz. Der TCP-Dienst darf dagegen nicht auf Anwendungsebene interpretiert werden.\u003c/p\u003e\n\u003cp\u003eBeide Dienste über dieselbe L7-Konfiguration zu führen, würde unnötige Komplexität erzeugen. Eine reine L4-Architektur würde hingegen zentrale Funktionen für die API in die Backends verlagern. Sinnvoller ist eine getrennte Verarbeitung: L7 für die HTTP-API, L4 für den TCP-Dienst. Gemeinsame Anycast-Erreichbarkeit, Health Checks, Failover und Statistiken können trotzdem über die Edge-Plattform organisiert werden. Die Zuständigkeiten bleiben klar, obwohl die öffentliche Eingangsschicht zusammenhängend betrieben wird.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"ist-l4-grundsätzlich-einfacher-als-l7\"\u003eIst L4 grundsätzlich einfacher als L7?\u003c/h3\u003e\n\u003cp\u003eIm Regelfall ja, weil L4 keine HTTP-Inhalte auswertet. Einfacher bedeutet jedoch nicht automatisch geeigneter: Routing, TLS-Termination oder WAF-Schutz erfordern eine Verarbeitung auf L7.\u003c/p\u003e\n\u003ch3 id=\"wann-verursacht-l7-besonders-viel-änderungsaufwand\"\u003eWann verursacht L7 besonders viel Änderungsaufwand?\u003c/h3\u003e\n\u003cp\u003eWenn Domains, API-Pfade, Zertifikate, WAF-Regeln und Backend-Versionen häufig gemeinsam verändert werden. Dann sind integrierte Tests und klare Ownership für Edge- und Anwendungskonfiguration notwendig.\u003c/p\u003e\n\u003ch3 id=\"können-l4-und-l7-in-einer-architektur-kombiniert-werden\"\u003eKönnen L4 und L7 in einer Architektur kombiniert werden?\u003c/h3\u003e\n\u003cp\u003eJa. Unterschiedliche Services können je nach Protokoll und Schutzbedarf auf der passenden Ebene verarbeitet werden. Entscheidend ist, die Zuständigkeiten und Beobachtbarkeit je Ebene eindeutig zu definieren.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eDer L4-L7-Vergleich ist vor allem eine Betriebsentscheidung. L4 begrenzt die Verarbeitung und damit häufig auch die Konfigurations- und Fehleroberfläche. L7 schafft mehr Kontrolle über HTTP-Traffic, verlangt aber diszipliniertes Änderungsmanagement und tiefere Beobachtbarkeit. Eine Edge-Plattform wie die ayedo Edge Cloud ist dann sinnvoll eingeordnet, wenn sie beide Ebenen als zusammenhängende öffentliche Eingangsschicht nutzt, ohne Edge-Verantwortung mit der Compute-Infrastruktur zu vermischen.\u003c/p\u003e\n",
      "summary": "\nTL;DR L4- und L7-Loadbalancing unterscheiden sich nicht nur durch ihre Protokollebene, sondern vor allem durch ihren Betriebsaufwand. L4 ist meist einfacher und robuster, L7 bietet mehr Steuerungsmöglichkeiten, erzeugt aber höhere Anforderungen an Konfiguration, Beobachtbarkeit und Änderungsmanagement. Eine Edge-Plattform kann beide Ebenen gezielt kombinieren.\nEinleitung Die falsche Loadbalancing-Ebene erzeugt häufig keinen sofortigen Fehler, sondern schleichende Betriebskomplexität. Wer HTTP-Anforderungen auf L4 behandelt, verliert Möglichkeiten für Routing und Protokolltransparenz. Wer jede Verbindung auf L7 verarbeitet, erhöht dagegen Konfigurationsumfang, Fehleroberfläche und Änderungsaufwand. Der entscheidende Vergleich lautet deshalb nicht „Welche Ebene ist leistungsfähiger?“, sondern: Welche Verarbeitung braucht die Anwendung, und welche Konsequenzen entstehen daraus im Betrieb? Für Platform- und Infrastrukturteams betrifft diese Entscheidung Konfiguration, Monitoring, Fehlersuche, Security und die Organisation von Releases.\n",
      "image": "https://ayedo.de/l4-und-l7-im-vergleich-trade-offs-fur-den-betrieb.png",
      "date_published": "2026-09-02T13:58:52Z",
      "date_modified": "2026-09-02T13:58:52Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["security","operations","platform","software-delivery","compliance"],
      "language": "de"
    },{
      "id": "https://ayedo.de/posts/l4-l7-loadbalancing-fur-zustandsbehaftete-anwendungen/",
      "url": "https://ayedo.de/posts/l4-l7-loadbalancing-fur-zustandsbehaftete-anwendungen/",
      "title": "L4/L7-Loadbalancing für zustandsbehaftete Anwendungen",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/l4-l7-loadbalancing-fur-zustandsbehaftete-anwendungen/l4-l7-loadbalancing-fur-zustandsbehaftete-anwendungen.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eBei zustandsbehafteten Anwendungen entscheidet nicht allein die Verteilung von Verbindungen über die passende Loadbalancing-Ebene. L4 bietet geringe Eingriffstiefe und eignet sich für stabile Verbindungen, während L7 Routinglogik und Session Persistence gezielter abbilden kann. Entscheidend sind Session-Modell, Backend-Pools, Skalierungsverhalten und Failover-Strategie.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eZustandsbehaftete Anwendungen scheitern häufig nicht an fehlender Rechenleistung, sondern an einer unpassenden Lastverteilungsstrategie. Wird eine laufende Verbindung ohne Rücksicht auf ihren Zustand an ein anderes Backend weitergeleitet, verliert die Anwendung Kontext: Sitzungen brechen ab, Transaktionen werden inkonsistent oder Nutzer müssen sich erneut authentifizieren. Die zentrale Architekturentscheidung lautet deshalb nicht einfach „L4 oder L7“, sondern: Wo wird der Zustand gehalten, und welche Komponente kann die notwendige Bindung zuverlässig durchsetzen? L4- und L7-Loadbalancing verfolgen dabei unterschiedliche Ansätze. Die Wahl beeinflusst Session Persistence, Backend-Skalierung, Failover und den Betriebsaufwand an der Edge.\u003c/p\u003e\n\u003ch2 id=\"1-warum-zustände-die-lastverteilung-begrenzen\"\u003e1. Warum Zustände die Lastverteilung begrenzen\u003c/h2\u003e\n\u003cp\u003eEine zustandsbehaftete Anwendung hält Informationen über eine Verbindung oder Sitzung entweder im Prozess, im lokalen Speicher des Backends oder in einer gemeinsam genutzten Datenbank. Typische Beispiele sind langlebige TCP-Verbindungen, WebSockets, bestimmte Messaging-Dienste und Anwendungen mit lokalem Session-Kontext. Eine beliebige Verteilung auf mehrere Backends ist in diesen Fällen nicht möglich, ohne den Zustand explizit zu replizieren oder zentral verfügbar zu machen.\u003c/p\u003e\n\u003cp\u003eBei L4-Loadbalancing wird der Traffic auf Verbindungs- beziehungsweise Transportebene verteilt. Der Loadbalancer kennt typischerweise weder URL noch Cookie noch den fachlichen Kontext einer HTTP-Session. Er kann eine bestehende TCP-Verbindung einem Backend zuordnen, aber nicht anhand anwendungsbezogener Merkmale entscheiden, ob eine Sitzung logisch zusammenbleiben muss.\u003c/p\u003e\n\u003cp\u003eDas ist kein Nachteil an sich. L4 benötigt weniger Protokollverständnis und eignet sich für viele TCP-basierte Anwendungen. Problematisch wird der Ansatz, wenn eine Architektur Session Persistence erwartet, diese aber nicht auf Transportebene oder in der Anwendung abgesichert ist. Dann wird aus Backend-Skalierung ein Konsistenzproblem.\u003c/p\u003e\n\u003ch2 id=\"2-l4-stabile-verbindungen-begrenzte-session-logik\"\u003e2. L4: stabile Verbindungen, begrenzte Session-Logik\u003c/h2\u003e\n\u003cp\u003eBei L4 bleibt eine einzelne Verbindung üblicherweise einem Backend zugeordnet, solange diese Verbindung besteht. Für Anwendungen mit langlebigen Sessions kann das ausreichend sein. Neue Verbindungen dürfen jedoch auf andere Backends verteilt werden. Nach einem Client-Reconnect oder bei mehreren parallelen Verbindungen entsteht daher keine automatische Garantie, dass derselbe Anwendungskontext wieder erreicht wird.\u003c/p\u003e\n\u003cp\u003eDer Vorteil liegt in der geringen Verarbeitungstiefe: TLS kann bis zum Backend durchgereicht werden, und der Loadbalancer muss die Anwendung nicht interpretieren. Das reduziert Protokollabhängigkeiten und kann für heterogene TCP-Dienste sinnvoll sein. Gleichzeitig fehlen L7-Möglichkeiten wie Routing nach Host, Pfad oder HTTP-Header.\u003c/p\u003e\n\u003cp\u003eFür die ayedo Edge Cloud ist L4 damit vor allem dann relevant, wenn die Anwendung selbst mit Verbindungsbindung, repliziertem Zustand oder einem externen Session Store arbeitet. Die Edge kann eingehende Verbindungen über verteilte PoPs und Anycast annehmen und zu Backend-Pools weiterleiten. Die eigentliche Zustandsstrategie bleibt jedoch eine Architekturentscheidung der Anwendung. Health Checks und Failover müssen außerdem so gewählt werden, dass ein Backend-Ausfall nicht nur neue, sondern auch bestehende Verbindungen berücksichtigt.\u003c/p\u003e\n\u003ch2 id=\"3-l7-gezieltere-persistence-und-höhere-komplexität\"\u003e3. L7: gezieltere Persistence und höhere Komplexität\u003c/h2\u003e\n\u003cp\u003eL7-Loadbalancing verarbeitet Anwendungsprotokolle wie HTTP oder HTTPS. Dadurch können Routingentscheidungen auf Basis von Hostnamen, Pfaden, Headern oder Cookies getroffen werden. Für Sticky Sessions lässt sich beispielsweise ein Sitzungsmerkmal verwenden, das einen Client wieder demselben Backend oder Backend-Pool zuordnet. Das ist präziser als eine reine Transportzuordnung, setzt aber voraus, dass die Anwendung und die Routinglogik dieses Verfahren unterstützen.\u003c/p\u003e\n\u003cp\u003eSession Persistence ist kein Ersatz für eine belastbare Zustandsarchitektur. Fällt das gebundene Backend aus, muss die Sitzung entweder auf einen replizierten Zustand zugreifen können oder verloren gehen. Auch ungleich große Sessions können die Lastverteilung verzerren: Ein Backend mit vielen langlebigen Verbindungen bleibt stark belastet, während neue Requests bereits auf andere Instanzen verteilt werden.\u003c/p\u003e\n\u003cp\u003eL7 bringt zudem TLS Termination, Protokollverarbeitung und zusätzliche Betriebsverantwortung an die Edge. In der ayedo Edge Cloud kann diese Verarbeitung mit WAF, Backend-Pools, Health Checks und Failover zusammenspielen. Das schafft zentrale Steuerungsmöglichkeiten, sollte aber nicht als automatische Garantie für Session Persistence verstanden werden. Die konkrete Persistenzlogik muss zum Session-Modell passen.\u003c/p\u003e\n\u003ch2 id=\"4-backend-skalierung-und-failover-richtig-modellieren\"\u003e4. Backend-Skalierung und Failover richtig modellieren\u003c/h2\u003e\n\u003cp\u003eZustandsbehaftete Anwendungen skalieren anders als stateless Services. Bei stateless Workloads kann ein neuer Pod oder Server meist sofort Requests übernehmen. Bei Sticky Sessions oder langlebigen Verbindungen ist ein Backend-Pool dagegen nicht homogen: Einige Instanzen halten viele aktive Sitzungen, andere sind kaum belastet. Durchschnittliche Request-Zahlen bilden diese Situation nur unzureichend ab.\u003c/p\u003e\n\u003cp\u003eVor einer Skalierung müssen daher mindestens drei Fragen beantwortet werden: Werden Sitzungen lokal gehalten? Wie lange bleiben Verbindungen bestehen? Was passiert bei einem Backend-Ausfall? L4 kann bestehende Verbindungen stabil halten, aber nicht sinnvoll auf eine andere Instanz migrieren. L7 kann neue Requests gezielter routen, verliert den lokalen Zustand jedoch ebenfalls, wenn keine Replikation oder externe Speicherung existiert.\u003c/p\u003e\n\u003cp\u003eFür eine Edge-Plattform bedeutet das: Health Checks sollten nicht nur den Prozessstatus prüfen, sondern die tatsächliche Bereitschaft des Backends für neue Sitzungen. Failover muss zwischen neuen Verbindungen und bestehenden Sessions unterscheiden. Backend Cloaking reduziert dabei die öffentliche Angriffsfläche, ersetzt aber keine Session- oder Replikationsstrategie. Die ayedo Edge Cloud kann vor \u003ca href=\"/kubernetes/\"\u003eKubernetes-Clustern\u003c/a\u003e\n bei ayedo oder anderen Providern sowie vor eigener Infrastruktur eingesetzt werden. Damit bleibt die Zustandsarchitektur vom Compute-Standort getrennt planbar.\u003c/p\u003e\n\u003ch2 id=\"praxis--und-betriebsszenario\"\u003ePraxis- und Betriebsszenario\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt eine Webanwendung mit lokalen Sessions und mehreren \u003ca href=\"/kubernetes/\"\u003eKubernetes-Backends\u003c/a\u003e\n. Zunächst wird L4 eingesetzt. Bestehende TCP-Verbindungen bleiben stabil, aber nach Reconnects landen Nutzer teilweise auf einer anderen Instanz und verlieren ihren Kontext. Eine Umstellung auf L7 mit Cookie-basierter Bindung verbessert das Verhalten bei normalen Requests. Beim Ausfall eines Backends gehen die dort lokal gehaltenen Sessions trotzdem verloren.\u003c/p\u003e\n\u003cp\u003eDie nachhaltigere Variante verschiebt den Session-Zustand in einen gemeinsam erreichbaren Store oder repliziert ihn zwischen Instanzen. Danach kann L7 Persistence weiterhin Verbindungen und Requests gezielt verteilen, während Failover technisch beherrschbar wird. Alternativ bleibt L4 sinnvoll, wenn die Anwendung selbst Verbindungszustand und Wiederaufnahme kontrolliert. Entscheidend ist nicht die vermeintlich höhere Ebene, sondern die Übereinstimmung von Loadbalancer, Session-Modell und Ausfallverhalten.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"sind-sticky-sessions-immer-erforderlich\"\u003eSind Sticky Sessions immer erforderlich?\u003c/h3\u003e\n\u003cp\u003eNein. Sie sind nur nötig, wenn Sitzungszustand lokal am Backend liegt oder Verbindungen an eine bestimmte Instanz gebunden sind. Replizierte oder externe Zustände erlauben meist eine freiere Verteilung.\u003c/p\u003e\n\u003ch3 id=\"ist-l7-grundsätzlich-besser-für-zustandsbehaftete-anwendungen\"\u003eIst L7 grundsätzlich besser für zustandsbehaftete Anwendungen?\u003c/h3\u003e\n\u003cp\u003eNein. L7 bietet mehr Routinginformationen, aber auch mehr Komplexität. Für reine TCP-Dienste oder anwendungsseitig kontrollierte Zustände kann L4 die passendere und robustere Ebene sein.\u003c/p\u003e\n\u003ch3 id=\"was-passiert-bei-der-backend-skalierung\"\u003eWas passiert bei der Backend-Skalierung?\u003c/h3\u003e\n\u003cp\u003eNeue Backends übernehmen meist neue Verbindungen oder Sessions. Bestehende Bindungen werden nicht automatisch migriert. Bei Sticky Sessions kann deshalb eine kontrollierte Drain- und Failover-Strategie notwendig sein.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eLoadbalancing zustandsbehaftete Anwendungen verlangt eine klare Trennung zwischen Verbindungsbindung, Session Persistence und eigentlicher Zustandsverwaltung. L4 bewahrt Verbindungen mit geringer Protokolltiefe, L7 ermöglicht gezielteres Routing, löst aber keine lokalen Zustände. Eine Edge-Plattform wie die ayedo Edge Cloud schafft den verteilten öffentlichen Einstieg, Schutz und Backend-Failover. Die belastbare Lösung entsteht erst durch das Zusammenspiel mit Session- und Skalierungsdesign der Anwendung.\u003c/p\u003e\n",
      "summary": "\nTL;DR Bei zustandsbehafteten Anwendungen entscheidet nicht allein die Verteilung von Verbindungen über die passende Loadbalancing-Ebene. L4 bietet geringe Eingriffstiefe und eignet sich für stabile Verbindungen, während L7 Routinglogik und Session Persistence gezielter abbilden kann. Entscheidend sind Session-Modell, Backend-Pools, Skalierungsverhalten und Failover-Strategie.\nEinleitung Zustandsbehaftete Anwendungen scheitern häufig nicht an fehlender Rechenleistung, sondern an einer unpassenden Lastverteilungsstrategie. Wird eine laufende Verbindung ohne Rücksicht auf ihren Zustand an ein anderes Backend weitergeleitet, verliert die Anwendung Kontext: Sitzungen brechen ab, Transaktionen werden inkonsistent oder Nutzer müssen sich erneut authentifizieren. Die zentrale Architekturentscheidung lautet deshalb nicht einfach „L4 oder L7“, sondern: Wo wird der Zustand gehalten, und welche Komponente kann die notwendige Bindung zuverlässig durchsetzen? L4- und L7-Loadbalancing verfolgen dabei unterschiedliche Ansätze. Die Wahl beeinflusst Session Persistence, Backend-Skalierung, Failover und den Betriebsaufwand an der Edge.\n",
      "image": "https://ayedo.de/l4-l7-loadbalancing-fur-zustandsbehaftete-anwendungen.png",
      "date_published": "2026-09-02T13:58:52Z",
      "date_modified": "2026-09-02T13:58:52Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["kubernetes","cloud-native","digital-sovereignty","software-delivery","platform"],
      "language": "de"
    },{
      "id": "https://ayedo.de/posts/kubernetes-workloads-mit-l4-und-l7-skalierbar-verteilen/",
      "url": "https://ayedo.de/posts/kubernetes-workloads-mit-l4-und-l7-skalierbar-verteilen/",
      "title": "Kubernetes-Workloads mit L4 und L7 skalierbar verteilen",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/kubernetes-workloads-mit-l4-und-l7-skalierbar-verteilen/kubernetes-workloads-mit-l4-und-l7-skalierbar-verteilen.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eKubernetes Loadbalancing endet nicht am Service-Objekt des Clusters. Für öffentlich erreichbare Anwendungen müssen IP-Verteilung, TLS, Routing, Schutzfunktionen und Backend-Auswahl außerhalb des Clusters zusammenspielen. Eine providerunabhängige Edge-Integration trennt diese Aufgaben vom Clusterbetrieb und unterstützt L4- sowie L7-Szenarien für Services, APIs und \u003ca href=\"/kubernetes/\"\u003eIngress-Architekturen\u003c/a\u003e\n.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eEin Kubernetes-Service kann einen Workload intern erreichbar machen, löst aber nicht automatisch die Anforderungen eines öffentlichen Endpunkts. Externer Traffic benötigt einen stabilen Eingang, eine belastbare Verteilung auf Backends und klare Zuständigkeiten für TLS, Routing und Ausfallsituationen. Häufig wird diese Funktion vollständig an den jeweiligen Kubernetes-Provider oder an einen einzelnen Cluster gebunden. Das vereinfacht den Einstieg, erschwert jedoch spätere Providerwechsel, Multi-Cluster-Architekturen und die zentrale Steuerung sicherheitsrelevanter Funktionen. Kubernetes Loadbalancing sollte deshalb als Zusammenspiel aus Cluster-internem Routing und einer vorgelagerten Edge betrachtet werden. L4 und L7 erfüllen dabei unterschiedliche Aufgaben und müssen passend zum Protokoll und zur Anwendung eingesetzt werden.\u003c/p\u003e\n\u003ch2 id=\"1-l4-und-l7-adressieren-unterschiedliche-verkehrsebenen\"\u003e1. L4 und L7 adressieren unterschiedliche Verkehrsebenen\u003c/h2\u003e\n\u003cp\u003eL4 Loadbalancing arbeitet auf Transportebene. Verbindungen werden anhand von IP-Adressen und Ports verteilt, ohne den Inhalt der Anwendung auszuwerten. Das eignet sich für TCP- oder UDP-basierte Services, Datenbanken mit öffentlichem Zugriffskonzept, proprietäre Protokolle oder TLS-Verbindungen, die erst im Backend terminiert werden. Die Edge muss in diesen Fällen keine HTTP-Struktur verstehen, sondern Verbindungen zuverlässig an erreichbare Backends weiterleiten.\u003c/p\u003e\n\u003cp\u003eL7 Loadbalancing arbeitet dagegen auf Anwendungsebene. Bei HTTP- und HTTPS-Services kann nach Hostnamen, Pfaden oder weiteren Request-Eigenschaften geroutet werden. Dadurch lassen sich beispielsweise mehrere APIs und Webanwendungen über eine gemeinsame öffentliche Adresse verteilen. TLS Termination an der Edge entlastet Backends und zentralisiert Zertifikats- und Verbindungslogik. Die Wahl zwischen L4 und L7 ist daher keine reine Produktentscheidung: Sie bestimmt, wo Protokollverständnis, Verschlüsselung und Routingregeln betrieben werden.\u003c/p\u003e\n\u003ch2 id=\"2-kubernetes-ingress-braucht-einen-stabilen-öffentlichen-eingang\"\u003e2. Kubernetes Ingress braucht einen stabilen öffentlichen Eingang\u003c/h2\u003e\n\u003cp\u003eKubernetes Ingress beschreibt Regeln für HTTP- und HTTPS-Routing, ist aber selbst kein vollständiger globaler Eingangspunkt. Die konkrete Umsetzung hängt vom verwendeten Ingress-Controller, der Netzwerkanbindung und dem Clusterbetrieb ab. Bei einem L7-Szenario kann die ayedo Edge Cloud den öffentlichen Traffic annehmen, TLS terminieren und Requests anhand definierter Routinginformationen an Kubernetes-Backends weiterleiten. Der Ingress bleibt dabei Teil der Anwendungsarchitektur, während die Edge den vorgelagerten Zugang und die Verteilung übernimmt.\u003c/p\u003e\n\u003cp\u003eFür reine TCP- oder UDP-Services ist ein Ingress ungeeignet. Hier wird der Service über L4 erreichbar gemacht und auf entsprechende Backend-Endpunkte verteilt. Diese Trennung verhindert, dass ein HTTP-Konzept auf nicht passende Protokolle übertragen wird. Gleichzeitig bleibt der Cluster austauschbar: Die Backends können aus ayedo Managed \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n, einem selbst betriebenen Cluster oder einem Kubernetes-Cluster bei einem anderen Provider stammen.\u003c/p\u003e\n\u003ch2 id=\"3-providerunabhängigkeit-reduziert-architektonische-kopplung\"\u003e3. Providerunabhängigkeit reduziert architektonische Kopplung\u003c/h2\u003e\n\u003cp\u003eWird der öffentliche Zugang ausschließlich über den Mechanismus eines Clusterproviders realisiert, liegen DNS, externe IPs, TLS, Routing und Ausfallverhalten häufig eng an diesem Betrieb. Ein Wechsel des Providers oder die Ergänzung eines zweiten Clusters wird dann zu einer Migrationsaufgabe für den öffentlichen Traffic. Eine separate Edge-Schicht entkoppelt diese Funktionen vom Lebenszyklus einzelner Kubernetes-Cluster.\u003c/p\u003e\n\u003cp\u003eDie ayedo Edge Cloud nutzt dafür Anycast-basiertes Layer-4- und Layer-7-Loadbalancing, Anycast DNS sowie Multi-Provider-DNS. Backend Cloaking verhindert, dass die eigentlichen Backend-Adressen direkt als öffentlicher Zugang dienen. Health Checks und Failover ermöglichen, nicht erreichbare Backends aus der Verteilung zu nehmen. Das ist besonders relevant für Multi-Cluster- oder hybride Szenarien: Routing und Schutzfunktionen bleiben an der Edge zentral steuerbar, während Workloads zwischen Clustern oder Providern verschoben werden können. Die Edge wird damit zum stabilen Vertrag gegenüber Clients, nicht der einzelne Cluster.\u003c/p\u003e\n\u003ch2 id=\"4-skalierung-umfasst-traffic-workloads-und-betrieb\"\u003e4. Skalierung umfasst Traffic, Workloads und Betrieb\u003c/h2\u003e\n\u003cp\u003eEine Edge kann eingehende Verbindungen und Requests verteilen, ersetzt aber keine Kubernetes-Mechanismen zur Skalierung von Pods. Horizontal Pod Autoscaling, Rollouts und interne Service-Discovery bleiben Aufgaben des Clusters. Die Edge muss dagegen erkennen, welche Backends erreichbar sind und wohin öffentlicher Traffic weitergeleitet werden darf. Proxy Protocol kann dabei notwendige Informationen zur ursprünglichen Verbindung an kompatible Backends übergeben.\u003c/p\u003e\n\u003cp\u003eFür den Betrieb ist entscheidend, diese Ebenen getrennt zu beobachten. Traffic- und Usage-Statistiken an der Edge zeigen die Entwicklung des öffentlichen Zugangs; Kubernetes-Metriken zeigen Pod-Auslastung, Replica-Anzahl und interne Fehler. DDoS Protection, Web Application Firewall und TLS Termination gehören zur vorgelagerten Schutz- und Verarbeitungsschicht, nicht zur Pod-Logik. Durch eine verteilte Multi-PoP-Architektur, eigenes Autonomous System und ein Aktiv-Aktiv-Prinzip wird der öffentliche Eingang außerdem unabhängig von der Verfügbarkeit eines einzelnen Clusterstandorts betrachtet.\u003c/p\u003e\n\u003ch2 id=\"praxis--und-architekturszenario\"\u003ePraxis- und Architekturszenario\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt eine Webanwendung und mehrere APIs in zwei Kubernetes-Clustern bei unterschiedlichen Providern. HTTP- und HTTPS-Anfragen werden an der Edge per L7 nach Hostname und Pfad verteilt. Ein TCP-basierter Service erhält einen separaten L4-Endpunkt. Beide Cluster bleiben für ihre internen Services, Deployments und Autoscaling-Regeln verantwortlich.\u003c/p\u003e\n\u003cp\u003eFällt ein Backend aus, entfernen Health Checks dieses aus der aktiven Verteilung. Die öffentlichen DNS- und Routingstrukturen müssen dabei nicht an den jeweiligen Provider angepasst werden. Alternativ könnte jeder Cluster seinen eigenen externen Einstieg betreiben. Das würde jedoch Konfigurationen für TLS, Schutz, Monitoring und Failover mehrfach verteilen und den Providerwechsel stärker in den öffentlichen Betrieb hineinziehen.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"ist-kubernetes-ingress-dasselbe-wie-l7-loadbalancing\"\u003eIst Kubernetes Ingress dasselbe wie L7 Loadbalancing?\u003c/h3\u003e\n\u003cp\u003eNein. Ingress definiert typischerweise HTTP- und HTTPS-Routing im Kubernetes-Kontext. L7 Loadbalancing ist die übergeordnete Anwendungsebene, auf der Requests analysiert und verteilt werden.\u003c/p\u003e\n\u003ch3 id=\"wann-ist-l4-loadbalancing-die-bessere-wahl\"\u003eWann ist L4 Loadbalancing die bessere Wahl?\u003c/h3\u003e\n\u003cp\u003eWenn TCP oder UDP transportiert werden soll, der Traffic nicht HTTP-basiert ist oder die TLS-Terminierung bewusst im Backend verbleiben muss. L4 benötigt kein Verständnis der Anwendungsinhalte.\u003c/p\u003e\n\u003ch3 id=\"muss-kubernetes-bei-ayedo-betrieben-werden\"\u003eMuss Kubernetes bei ayedo betrieben werden?\u003c/h3\u003e\n\u003cp\u003eNein. Die ayedo Edge Cloud kann auch vor eigenen Kubernetes-Clustern oder Clustern anderer Provider eingesetzt werden. Die Edge-Funktionen bleiben damit vom gewählten Compute-Betrieb getrennt.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eKubernetes Loadbalancing sollte nicht auf die Frage reduziert werden, welcher Service einen Port öffnet. L4 und L7 bilden unterschiedliche Integrationspfade für Protokolle, APIs und \u003ca href=\"/kubernetes/\"\u003eIngress-Architekturen\u003c/a\u003e\n. Eine providerunabhängige Edge trennt öffentlichen Zugang, Schutz und Routing vom eigentlichen Clusterbetrieb. Die ayedo Edge Cloud unterstützt diese Trennung mit Anycast-Verteilung, DNS, Backend-Health-Checks und Failover für Kubernetes-Workloads unabhängig vom gewählten Provider.\u003c/p\u003e\n",
      "summary": "\nTL;DR Kubernetes Loadbalancing endet nicht am Service-Objekt des Clusters. Für öffentlich erreichbare Anwendungen müssen IP-Verteilung, TLS, Routing, Schutzfunktionen und Backend-Auswahl außerhalb des Clusters zusammenspielen. Eine providerunabhängige Edge-Integration trennt diese Aufgaben vom Clusterbetrieb und unterstützt L4- sowie L7-Szenarien für Services, APIs und Ingress-Architekturen .\nEinleitung Ein Kubernetes-Service kann einen Workload intern erreichbar machen, löst aber nicht automatisch die Anforderungen eines öffentlichen Endpunkts. Externer Traffic benötigt einen stabilen Eingang, eine belastbare Verteilung auf Backends und klare Zuständigkeiten für TLS, Routing und Ausfallsituationen. Häufig wird diese Funktion vollständig an den jeweiligen Kubernetes-Provider oder an einen einzelnen Cluster gebunden. Das vereinfacht den Einstieg, erschwert jedoch spätere Providerwechsel, Multi-Cluster-Architekturen und die zentrale Steuerung sicherheitsrelevanter Funktionen. Kubernetes Loadbalancing sollte deshalb als Zusammenspiel aus Cluster-internem Routing und einer vorgelagerten Edge betrachtet werden. L4 und L7 erfüllen dabei unterschiedliche Aufgaben und müssen passend zum Protokoll und zur Anwendung eingesetzt werden.\n",
      "image": "https://ayedo.de/kubernetes-workloads-mit-l4-und-l7-skalierbar-verteilen.png",
      "date_published": "2026-09-02T13:58:51Z",
      "date_modified": "2026-09-02T13:58:51Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["kubernetes","security","operations","development","hosting"],
      "language": "de"
    },{
      "id": "https://ayedo.de/posts/proxy-protocol-im-l4-und-l7-betrieb-korrekt-einsetzen/",
      "url": "https://ayedo.de/posts/proxy-protocol-im-l4-und-l7-betrieb-korrekt-einsetzen/",
      "title": "Proxy Protocol im L4- und L7-Betrieb korrekt einsetzen",
      "content_html": "\u003cp\u003e\u003cimg src=\"/posts/proxy-protocol-im-l4-und-l7-betrieb-korrekt-einsetzen/proxy-protocol-im-l4-und-l7-betrieb-korrekt-einsetzen.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eDas Proxy Protocol überträgt Verbindungsinformationen wie die ursprüngliche Client-IP über eine Proxy- oder Loadbalancing-Verbindung hinweg. Im L4- und L7-Betrieb gelten dabei unterschiedliche Integrationsanforderungen. Entscheidend ist, dass der Backend-Dienst das Protokoll erwartet, korrekt auswertet und nicht mit normalen HTTP-Headern verwechselt.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eEin Backend sieht nicht automatisch die Adresse des tatsächlichen Clients. Sobald eine Edge-Plattform eine neue Verbindung zum Zielsystem aufbaut, erscheint zunächst die Edge als Kommunikationspartner. Das ist architektonisch gewollt, kann aber für Zugriffskontrolle, Rate Limiting, Audit-Logs oder forensische Analysen problematisch werden. Das Proxy Protocol löst dieses Problem, indem die Edge Verbindungsinformationen vor den eigentlichen Nutzdaten an das Backend übergibt. Die Funktion ist jedoch keine rein technische Einstellung am Loadbalancer: Sie bildet einen Integrationsvertrag zwischen Edge und Backend. Wird sie auf einer Seite aktiviert und auf der anderen nicht erwartet, entstehen keine besseren Logs, sondern fehlerhafte Verbindungen.\u003c/p\u003e\n\u003ch2 id=\"1-was-das-proxy-protocol-tatsächlich-überträgt\"\u003e1. Was das Proxy Protocol tatsächlich überträgt\u003c/h2\u003e\n\u003cp\u003eDas Proxy Protocol ergänzt eine Backend-Verbindung um Metadaten zur ursprünglichen Verbindung. Dazu gehören typischerweise Quell- und Zieladresse sowie die verwendeten Ports. Das Backend kann dadurch die Client-IP erkennen, obwohl die TCP-Verbindung technisch von der Edge Cloud aufgebaut wurde.\u003c/p\u003e\n\u003cp\u003eWichtig ist die Abgrenzung zu einer transparenten Netzwerkverbindung: Das Proxy Protocol verändert nicht die Quelladresse auf IP-Ebene. Es übermittelt die Information innerhalb eines Protokollpräfixes, das vor dem eigentlichen Anwendungsprotokoll steht. Der Backend-Dienst oder ein vorgeschalteter Listener muss dieses Präfix deshalb interpretieren können.\u003c/p\u003e\n\u003cp\u003eFür ayedo Edge Cloud ist das Proxy Protocol eine Funktion innerhalb der Backend-Verbindung. Die Edge übernimmt weiterhin den öffentlichen Traffic-Eingang, das Routing und die Verteilung. Das Backend erhält zusätzliche Verbindungsinformationen, bleibt aber hinter der Edge verborgen. Diese Kombination unterstützt Backend Cloaking, ohne den Bedarf an belastbaren Logging- und Sicherheitsinformationen zu beseitigen.\u003c/p\u003e\n\u003ch2 id=\"2-l4-verbindungsinformationen-ohne-http-verarbeitung\"\u003e2. L4: Verbindungsinformationen ohne HTTP-Verarbeitung\u003c/h2\u003e\n\u003cp\u003eIm L4 Loadbalancing arbeitet die Edge auf Transportebene. Sie verteilt beispielsweise TCP-Verbindungen, ohne den Inhalt der Anwendung auf HTTP-Ebene auswerten zu müssen. Das ist relevant für TLS-Passthrough, Datenbanken, proprietäre TCP-Protokolle oder andere Dienste, bei denen die Edge den Anwendungsinhalt nicht terminieren soll.\u003c/p\u003e\n\u003cp\u003eDas Proxy Protocol wird in diesem Szenario am Anfang der Backend-TCP-Verbindung eingefügt. Der Backend-Endpunkt muss daher bereits vor dem eigentlichen Protokoll-Handshake mit dem Präfix rechnen. Ein Dienst, der unmittelbar einen TLS-, SMTP- oder proprietären Handshake erwartet, kann die Verbindung sonst als beschädigt interpretieren.\u003c/p\u003e\n\u003cp\u003eDie Client-IP bleibt für den Backend-Prozess verfügbar, obwohl die Edge die Verbindung weiterleitet. Gleichzeitig muss die Backend-Infrastruktur sicherstellen, dass nur vertrauenswürdige vorgelagerte Systeme Proxy-Informationen liefern dürfen. Akzeptiert ein öffentlich erreichbarer Dienst beliebige Proxy-Header, kann ein Angreifer Quelladressen fälschen und dadurch IP-basierte Regeln oder Logs manipulieren.\u003c/p\u003e\n\u003ch2 id=\"3-l7-proxy-protocol-vor-http-oder-tls\"\u003e3. L7: Proxy Protocol vor HTTP oder TLS\u003c/h2\u003e\n\u003cp\u003eIm L7-Betrieb terminiert die Edge typischerweise eine HTTP- oder HTTPS-Verbindung und baut anschließend eine separate Backend-Verbindung auf. Ohne zusätzliche Information kennt das Backend daher nur die Adresse der Edge. Das gilt auch dann, wenn die ursprüngliche Client-IP in der Edge selbst bekannt ist.\u003c/p\u003e\n\u003cp\u003eDas Proxy Protocol kann diese Information an den Beginn der neuen Backend-Verbindung setzen. Der Backend-Listener muss das Präfix lesen und danach das erwartete Protokoll an den zuständigen Dienst weiterreichen. Bei HTTP bedeutet das: Erst kommt das Proxy-Protocol-Präfix, danach folgen Request Line und Header. Bei einer verschlüsselten Backend-Verbindung muss die Verarbeitung zur gewählten TLS-Architektur passen.\u003c/p\u003e\n\u003cp\u003eProxy Protocol und HTTP-Header wie \u003ccode\u003eX-Forwarded-For\u003c/code\u003e sind nicht dasselbe. Header gehören zur Anwendungsschicht und müssen vom HTTP-Stack ausgewertet werden. Das Proxy Protocol liegt davor und kann auch dann sinnvoll sein, wenn ein vorgeschalteter TCP-Listener, Ingress oder Service Mesh die Verbindung zunächst auf Transportebene übernimmt. Die Entscheidung hängt deshalb vom tatsächlichen Backend-Pfad ab, nicht allein davon, ob der öffentliche Dienst HTTP nutzt.\u003c/p\u003e\n\u003ch2 id=\"4-der-integrationsvertrag-zwischen-edge-und-backend\"\u003e4. Der Integrationsvertrag zwischen Edge und Backend\u003c/h2\u003e\n\u003cp\u003eDie Aktivierung des Proxy Protocols ist nur dann erfolgreich, wenn beide Seiten dieselben Erwartungen haben. Zur technischen Abstimmung gehören mindestens der Listener-Typ, die Protokollvariante, das Transportprotokoll, der Port und die Frage, an welcher Stelle die Information entfernt oder weitergereicht wird.\u003c/p\u003e\n\u003cp\u003eEin häufiger Fehler ist die Aktivierung am Edge-Service, während der Backend-Dienst weiterhin ein unverändertes HTTP- oder TLS-Protokoll erwartet. Der Dienst interpretiert die ersten Bytes des Proxy-Präfixes dann als Nutzdaten. Umgekehrt verwirft ein Proxy- oder Ingress-Listener ohne Proxy-Protocol-Unterstützung eine Verbindung, wenn er die zusätzliche Präambel nicht verarbeiten kann.\u003c/p\u003e\n\u003cp\u003eAuch Health Checks müssen berücksichtigt werden. Ein Backend kann reguläre Verbindungen mit Proxy Protocol akzeptieren, aber Prüfverbindungen anders behandeln. Für einen stabilen Betrieb müssen Health Checks denselben relevanten Verbindungsbedingungen entsprechen wie der produktive Traffic. Logging- und Security-Systeme sollten außerdem dokumentieren, aus welcher vertrauenswürdigen Quelle die Client-IP stammt. Nur dann bleibt die Information über mehrere Backend-Verbindungen hinweg belastbar.\u003c/p\u003e\n\u003ch2 id=\"praxis--und-betriebsszenario\"\u003ePraxis- und Betriebsszenario\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt einen HTTPS-Service auf einem \u003ca href=\"/kubernetes/\"\u003eKubernetes-Cluster\u003c/a\u003e\n außerhalb von ayedo Managed Kubernetes. Die ayedo Edge Cloud übernimmt TLS Termination und leitet Requests an einen Ingress im Cluster weiter. Für Security-Logs und IP-basierte Zugriffskontrollen muss der Ingress die ursprüngliche Client-IP erhalten.\u003c/p\u003e\n\u003cp\u003eEine mögliche Umsetzung ist die Übergabe per HTTP-Header. Dafür muss der gesamte HTTP-Pfad diese Header vertrauenswürdig behandeln. Alternativ nimmt ein vorgelagerter Listener das Proxy Protocol entgegen und reicht die Verbindung anschließend an den HTTP-Ingress weiter. Dieser Ansatz kann sinnvoll sein, wenn die Client-Information bereits vor der HTTP-Verarbeitung benötigt wird. Entscheidend ist, dass genau ein dafür konfigurierter Einstiegspunkt das Präfix verarbeitet. Wird es zusätzlich an einen nicht dafür vorgesehenen Dienst weitergereicht, schlägt der Request fehl.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"ersetzt-das-proxy-protocol-x-forwarded-for\"\u003eErsetzt das Proxy Protocol \u003ccode\u003eX-Forwarded-For\u003c/code\u003e?\u003c/h3\u003e\n\u003cp\u003eNein. Das Proxy Protocol überträgt Metadaten vor dem Anwendungsprotokoll. \u003ccode\u003eX-Forwarded-For\u003c/code\u003e ist ein HTTP-Header. Welche Variante geeignet ist, hängt davon ab, an welcher Stelle im Backend die Client-IP benötigt und verarbeitet wird.\u003c/p\u003e\n\u003ch3 id=\"funktioniert-proxy-protocol-mit-tls-passthrough\"\u003eFunktioniert Proxy Protocol mit TLS-Passthrough?\u003c/h3\u003e\n\u003cp\u003eGrundsätzlich kann es vor einer TLS-Verbindung eingesetzt werden. Der empfangende Listener muss das Proxy-Protocol-Präfix jedoch vor dem TLS-Handshake verarbeiten und die Verbindung anschließend korrekt an den TLS-Dienst weitergeben.\u003c/p\u003e\n\u003ch3 id=\"kann-jedes-backend-die-client-ip-direkt-auswerten\"\u003eKann jedes Backend die Client-IP direkt auswerten?\u003c/h3\u003e\n\u003cp\u003eNein. Der konkrete Listener, Reverse Proxy, Ingress oder Dienst muss Proxy Protocol unterstützen und aktiviert haben. Andernfalls wird das Präfix als unbekannte oder ungültige Nutzlast behandelt.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eDas Proxy Protocol ist kein Schalter für „bessere Logs“, sondern ein verbindlicher Bestandteil der Verbindung zwischen Edge und Backend. Im L4-Betrieb schützt es die Client-Information über transportbasierte Weiterleitungen hinweg; im L7-Betrieb ergänzt es die neu aufgebaute Backend-Verbindung nach Termination. Die ayedo Edge Cloud kann diese Information an Backend-Verbindungen weitergeben – zuverlässig wird das Ergebnis aber erst durch einen passend konfigurierten und abgesicherten Backend-Listener.\u003c/p\u003e\n",
      "summary": "\nTL;DR Das Proxy Protocol überträgt Verbindungsinformationen wie die ursprüngliche Client-IP über eine Proxy- oder Loadbalancing-Verbindung hinweg. Im L4- und L7-Betrieb gelten dabei unterschiedliche Integrationsanforderungen. Entscheidend ist, dass der Backend-Dienst das Protokoll erwartet, korrekt auswertet und nicht mit normalen HTTP-Headern verwechselt.\nEinleitung Ein Backend sieht nicht automatisch die Adresse des tatsächlichen Clients. Sobald eine Edge-Plattform eine neue Verbindung zum Zielsystem aufbaut, erscheint zunächst die Edge als Kommunikationspartner. Das ist architektonisch gewollt, kann aber für Zugriffskontrolle, Rate Limiting, Audit-Logs oder forensische Analysen problematisch werden. Das Proxy Protocol löst dieses Problem, indem die Edge Verbindungsinformationen vor den eigentlichen Nutzdaten an das Backend übergibt. Die Funktion ist jedoch keine rein technische Einstellung am Loadbalancer: Sie bildet einen Integrationsvertrag zwischen Edge und Backend. Wird sie auf einer Seite aktiviert und auf der anderen nicht erwartet, entstehen keine besseren Logs, sondern fehlerhafte Verbindungen.\n",
      "image": "https://ayedo.de/proxy-protocol-im-l4-und-l7-betrieb-korrekt-einsetzen.png",
      "date_published": "2026-09-02T13:58:51Z",
      "date_modified": "2026-09-02T13:58:51Z",
      "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}],
      "tags": ["kubernetes","operations","compliance","cloud-native","digital-sovereignty"],
      "language": "de"
    },
  ]
}