{ "version": "https://jsonfeed.org/version/1.1", "title": "Blog | ayedo", "home_page_url": "https://ayedo.de/", "feed_url": "https://ayedo.de/posts/", "description": "Entdecken Sie unsere neuesten Artikel über Cloud-Native Technologien, Kubernetes, DevOps und moderne Software-Entwicklung.", "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/edge-ist-kein-kubernetes-feature/", "url": "https://ayedo.de/posts/edge-ist-kein-kubernetes-feature/", "title": "Edge ist kein Kubernetes-Feature:", "content_html": "\u003cp\u003e\u003cimg src=\"/posts/edge-ist-kein-kubernetes-feature/edge-ist-kein-kubernetes-feature.png\" alt=\"\"\u003e\u003c/p\u003e\n\u003ch2 id=\"warum-die-ayedo-edge-cloud-vor-jeder-infrastruktur-funktionieren-kann\"\u003eWarum die ayedo Edge Cloud vor jeder Infrastruktur funktionieren kann\u003c/h2\u003e\n\u003cp\u003eWer Edge-Infrastruktur mit \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n gleichsetzt, vermischt zwei unterschiedliche Ebenen.\u003c/p\u003e\n\u003cp\u003eKubernetes orchestriert Workloads. Eine Edge Cloud kontrolliert, wie Traffic diese Workloads erreicht.\u003c/p\u003e\n\u003cp\u003eDiese Trennung ist entscheidend.\u003c/p\u003e\n\u003cp\u003eDie ayedo Edge Cloud bildet eine eigenständige Infrastruktur-Schicht zwischen Internet und Backend. DNS, Routing, Loadbalancing, Monitoring und Schutzmechanismen werden damit nicht dort implementiert, wo eine Anwendung läuft, sondern davor.\u003c/p\u003e\n\u003cp\u003eDas Backend kann deshalb ein Kubernetes-Cluster sein. Es kann aber genauso ein klassischer Server, eine VM, ein Managed Server bei einem anderen Provider oder Infrastruktur im eigenen Rechenzentrum sein.\u003c/p\u003e\n\u003ch2 id=\"edge-und-compute-sind-getrennte-ebenen\"\u003eEdge und Compute sind getrennte Ebenen\u003c/h2\u003e\n\u003cp\u003eTechnisch betrachtet braucht die Edge Cloud zunächst erreichbare Backends.\u003c/p\u003e\n\u003cp\u003eDer eingehende Traffic wird über unsere Edge-Infrastruktur angenommen und anschließend an die konfigurierten Zielsysteme weitergeleitet. Edge-Standort und Compute-Standort müssen dabei weder im selben Rechenzentrum liegen noch vom selben Anbieter betrieben werden.\u003c/p\u003e\n\u003cp\u003eGenau diese Entkopplung ermöglicht heterogene Architekturen.\u003c/p\u003e\n\u003cp\u003eEin Unternehmen kann seine bestehenden Server weiter betreiben und trotzdem zusätzliche Infrastruktur davor schalten. Dazu gehören beispielsweise Anycast DNS, Layer-4-Loadbalancing, Endpoint Monitoring oder eine Web Application Firewall.\u003c/p\u003e\n\u003cp\u003eDie Anwendung muss dafür nicht auf die ayedo Compute Cloud migriert werden.\u003c/p\u003e\n\u003ch2 id=\"anycast-macht-den-einstieg-unabhängig-vom-backend\"\u003eAnycast macht den Einstieg unabhängig vom Backend\u003c/h2\u003e\n\u003cp\u003eEin zentraler Bestandteil dieser Architektur ist Anycast.\u003c/p\u003e\n\u003cp\u003eDabei wird dieselbe IP-Adresse von mehreren Edge-Standorten angekündigt. Das Netzwerk routet eine Verbindung zu einem geeigneten Point of Presence. Fällt ein Standort aus, kann ein anderer übernehmen, ohne dass dafür zunächst DNS-Einträge geändert und deren TTLs abgewartet werden müssen.\u003c/p\u003e\n\u003cp\u003eDie öffentliche Erreichbarkeit einer Anwendung wird dadurch von ihrem eigentlichen Compute-Standort entkoppelt.\u003c/p\u003e\n\u003cp\u003eHinter diesem Einstieg können wiederum unterschiedliche Backends liegen. Die Edge Cloud übernimmt die Verteilung der Verbindungen und überwacht die konfigurierten Endpunkte.\u003c/p\u003e\n\u003cp\u003eDamit entsteht eine zusätzliche Verfügbarkeits- und Routing-Schicht, ohne die darunterliegende Infrastruktur ersetzen zu müssen.\u003c/p\u003e\n\u003ch2 id=\"sicherheit-gehört-vor-das-backend\"\u003eSicherheit gehört vor das Backend\u003c/h2\u003e\n\u003cp\u003eDasselbe Prinzip gilt für Security.\u003c/p\u003e\n\u003cp\u003eEine Web Application Firewall entfaltet ihren Nutzen gerade dadurch, dass sie vor der eigentlichen Anwendung sitzt. HTTP(S)-Traffic kann am Edge geprüft werden, bevor er das Backend erreicht.\u003c/p\u003e\n\u003cp\u003eDamit wird die WAF nicht zu einer Eigenschaft des Servers oder \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n-Clusters, sondern zu einer vorgelagerten Schutzschicht.\u003c/p\u003e\n\u003cp\u003eDas ist architektonisch relevant: Zusätzliche Sicherheitsanforderungen erzwingen damit nicht automatisch einen Wechsel der Compute-Infrastruktur.\u003c/p\u003e\n\u003cp\u003eBestehende Systeme können bestehen bleiben. Die zusätzliche Funktion wird dort ergänzt, wo sie technisch hingehört: am Ingress.\u003c/p\u003e\n\u003ch2 id=\"kubernetes-automatisiert--es-ist-aber-keine-voraussetzung\"\u003eKubernetes automatisiert – es ist aber keine Voraussetzung\u003c/h2\u003e\n\u003cp\u003eMit \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n lässt sich diese Architektur deutlich stärker automatisieren.\u003c/p\u003e\n\u003cp\u003eUnsere Edge Services sind deshalb eng mit Komponenten wie \u003ccode\u003ecert-manager\u003c/code\u003e, \u003ccode\u003eexternal-dns\u003c/code\u003e und dem Cloud Controller Manager integriert. DNS-Einträge, Zertifikate und Loadbalancer können so direkt aus Kubernetes heraus verwaltet beziehungsweise provisioniert werden.\u003c/p\u003e\n\u003cp\u003eDas ist allerdings eine Integration und keine technische Voraussetzung für die Edge Cloud.\u003c/p\u003e\n\u003cp\u003eEin regulärer Server benötigt keinen Kubernetes-Cluster, damit Traffic über die Edge-Infrastruktur zu ihm geroutet werden kann.\u003c/p\u003e\n\u003cp\u003eGenau diese Unterscheidung ist wichtig.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eKubernetes automatisiert die Anbindung an die Edge. Es definiert aber nicht, was hinter der Edge laufen darf.\u003c/strong\u003e\u003c/p\u003e\n\u003ch2 id=\"infrastruktur-muss-kombinierbar-bleiben\"\u003eInfrastruktur muss kombinierbar bleiben\u003c/h2\u003e\n\u003cp\u003eCloud-Plattformen werden häufig vertikal gedacht: Compute, Netzwerk, DNS, Security und Plattformdienste stammen vom selben Anbieter.\u003c/p\u003e\n\u003cp\u003eTechnisch notwendig ist diese Kopplung nicht.\u003c/p\u003e\n\u003cp\u003eEine eigenständige Edge-Schicht ermöglicht eine andere Architektur: Compute dort betreiben, wo er technisch, wirtschaftlich oder regulatorisch sinnvoll ist – und Routing, Erreichbarkeit und Schutz unabhängig davon organisieren.\u003c/p\u003e\n\u003cp\u003eDas kann die ayedo Compute Cloud sein.\u003c/p\u003e\n\u003cp\u003eEs muss sie aber nicht sein.\u003c/p\u003e\n\u003cp\u003eFür uns ist genau diese Entkopplung ein wichtiger Bestandteil souveräner Infrastruktur. Ein zusätzlicher Infrastruktur-Service sollte keinen Providerwechsel voraussetzen.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eDie Edge Cloud entscheidet, wie eine Anwendung erreichbar ist. Nicht, wo sie laufen muss.\u003c/strong\u003e\u003c/p\u003e\n", "summary": "\nWarum die ayedo Edge Cloud vor jeder Infrastruktur funktionieren kann Wer Edge-Infrastruktur mit Kubernetes gleichsetzt, vermischt zwei unterschiedliche Ebenen.\nKubernetes orchestriert Workloads. Eine Edge Cloud kontrolliert, wie Traffic diese Workloads erreicht.\nDiese Trennung ist entscheidend.\nDie ayedo Edge Cloud bildet eine eigenständige Infrastruktur-Schicht zwischen Internet und Backend. DNS, Routing, Loadbalancing, Monitoring und Schutzmechanismen werden damit nicht dort implementiert, wo eine Anwendung läuft, sondern davor.\nDas Backend kann deshalb ein Kubernetes-Cluster sein. Es kann aber genauso ein klassischer Server, eine VM, ein Managed Server bei einem anderen Provider oder Infrastruktur im eigenen Rechenzentrum sein.\n", "image": "https://ayedo.de/edge-ist-kein-kubernetes-feature.png", "date_published": "2026-09-07T10:42:25Z", "date_modified": "2026-09-07T10:42:25Z", "authors": [{"name":"Katrin Peter","url":"https://www.linkedin.com/in/katrinpeter/"}], "tags": ["kubernetes","operations","cloud-native","security","hosting"], "language": "de" },{ "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/aktiv-aktiv-architektur-fur-souveranen-edge-betrieb/", "url": "https://ayedo.de/posts/aktiv-aktiv-architektur-fur-souveranen-edge-betrieb/", "title": "Aktiv-Aktiv-Architektur für souveränen Edge-Betrieb", "content_html": "\u003cp\u003e\u003cimg src=\"/posts/aktiv-aktiv-architektur-fur-souveranen-edge-betrieb/aktiv-aktiv-architektur-fur-souveranen-edge-betrieb.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eEine Aktiv-Aktiv-Architektur verteilt den öffentlichen Traffic-Eintritt auf mehrere gleichzeitig aktive Standorte. Dadurch entfällt der einzelne aktive Eintrittspunkt als zentrale Ausfallannahme. Der Ansatz erhöht jedoch die Anforderungen an Anycast-Routing, Health Checks, Failover und Betriebsprozesse. Souveränität bedeutet dabei vor allem: Unternehmen kontrollieren Netzwerk, Routinglogik und Ausfallverhalten selbst.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eEin einzelner aktiver Edge-Standort ist kein neutraler Architekturbaustein. Fällt seine Anbindung, seine Routing-Instanz oder ein zentraler Dienst aus, kann der öffentliche Zugang zu ansonsten verfügbaren Backends unterbrochen werden. Ein redundanter Standby-Standort reduziert dieses Risiko, bleibt aber auf einen kontrollierten Umschaltvorgang angewiesen. Die Aktiv-Aktiv-Architektur verfolgt einen anderen Ansatz: Mehrere Standorte nehmen Traffic gleichzeitig an und teilen sich die Verantwortung für den Eintritt in die \u003ca href=\"/platform/\"\u003ePlattform\u003c/a\u003e\n. Damit steigt die Hochverfügbarkeit, aber auch die technische Verantwortung für Routing, Zustandsbewertung und Failover. Wer den öffentlichen Traffic-Eintritt selbst kontrollieren will, muss diese Mechanismen als zusammenhängenden Betriebsprozess betrachten.\u003c/p\u003e\n\u003ch2 id=\"1-aktiv-aktiv-reduziert-zentrale-eintrittspunkte\"\u003e1. Aktiv-Aktiv reduziert zentrale Eintrittspunkte\u003c/h2\u003e\n\u003cp\u003eBei einer Aktiv-Passiv-Architektur verarbeitet ein primärer Standort den Traffic. Ein zweiter Standort wartet auf eine Aktivierung oder übernimmt erst nach einer manuellen beziehungsweise automatisierten Umschaltung. Dieses Modell kann funktionieren, erzeugt aber eine klare Abhängigkeit: Der primäre Standort ist bis zum Failover der zentrale Eintrittspunkt.\u003c/p\u003e\n\u003cp\u003eEine Aktiv-Aktiv-Architektur verteilt diese Rolle auf mehrere gleichzeitig aktive Edge-Standorte. \u003ca href=\"/kubernetes/\"\u003eAnycast-Routing\u003c/a\u003e\n kann Anfragen an den aus Netzwerksicht geeigneten Standort führen, ohne dass Clients einen einzelnen festen Endpoint kennen müssen. Fällt ein Standort aus, kann der Traffic über die verbleibenden aktiven Standorte verarbeitet werden.\u003c/p\u003e\n\u003cp\u003eDer Vorteil ist nicht nur technische Redundanz. Mit eigener Netzwerk-Infrastruktur und eigenem Autonomous System liegt die Kontrolle über den öffentlichen Eintritt, die Routing-Entscheidungen und die Rücknahme nicht verfügbarer Pfade beim Plattformbetreiber. Das ist ein konkretes Merkmal digitaler Souveränität. Es bedeutet jedoch nicht, dass Ausfälle verschwinden: Die Architektur verlagert die Verantwortung von einem zentralen Standort auf verteilte Routing- und Betriebsprozesse.\u003c/p\u003e\n\u003ch2 id=\"2-routing-muss-verfügbarkeit-tatsächlich-abbilden\"\u003e2. Routing muss Verfügbarkeit tatsächlich abbilden\u003c/h2\u003e\n\u003cp\u003eAnycast allein erzeugt keine Hochverfügbarkeit. Es verteilt Traffic zunächst anhand netzwerktechnischer Kriterien wie BGP-Pfaden und Erreichbarkeit. Ob ein Standort auch in der Lage ist, eine Anwendung sinnvoll zu bedienen, muss durch zusätzliche Zustandsinformationen bewertet werden.\u003c/p\u003e\n\u003cp\u003eDafür müssen Routing und Health Checks zusammenwirken. Ein Health Check kann beispielsweise prüfen, ob ein Edge-Dienst erreichbar ist, ob ein Backend antwortet oder ob eine definierte Anwendungskomponente einen funktionsfähigen Zustand meldet. Entscheidend ist die Wahl der Prüfebene: Ein erreichbarer Proxy bedeutet nicht automatisch, dass die dahinterliegende Anwendung gesund ist.\u003c/p\u003e\n\u003cp\u003eZu aggressive Prüfungen können funktionierende Standorte aus dem Routing nehmen und dadurch unnötige Umschaltungen auslösen. Zu großzügige Prüfungen lassen dagegen fehlerhafte Pfade aktiv. Für die Betriebsstabilität brauchen Unternehmen deshalb klare Kriterien für Fehlererkennung, Zeitverhalten und Wiederaufnahme. Ein Aktiv-Aktiv-Design ist nur dann belastbar, wenn Routingentscheidungen den tatsächlichen Servicezustand möglichst präzise abbilden.\u003c/p\u003e\n\u003ch2 id=\"3-failover-ist-ein-verteiltes-betriebsproblem\"\u003e3. Failover ist ein verteiltes Betriebsproblem\u003c/h2\u003e\n\u003cp\u003eFailover wird häufig als einzelne Umschaltaktion verstanden. In einer verteilten Aktiv-Aktiv-Architektur ist es jedoch eine Kette voneinander abhängiger Entscheidungen. Ein Standort kann ausfallen, während seine Netzwerkverbindung noch aktiv ist. Ein Backend kann nur teilweise erreichbar sein. Oder ein Fehler betrifft ausschließlich eine Anwendungsschicht, während Layer 4 weiterhin antwortet.\u003c/p\u003e\n\u003cp\u003eDaraus entstehen unterschiedliche Failover-Szenarien für Layer 4 und Layer 7. Die Edge muss entscheiden, ob sie neue Verbindungen an einen anderen Standort lenkt, bestehende Sessions auslaufen lässt oder Anfragen auf ein anderes Backend verteilt. Bei zustandsbehafteten Anwendungen können Session-Bindings, Wiederholungen und Timeout-Verhalten die Umschaltung zusätzlich beeinflussen.\u003c/p\u003e\n\u003cp\u003eHealth Checks und Failover-Regeln müssen deshalb gemeinsam getestet werden. Relevant sind nicht nur vollständige Standortausfälle, sondern auch fehlerhafte Routen, degradierte Backends und verzögerte Wiederherstellung. Die Aktiv-Aktiv-Architektur reduziert die Abhängigkeit von einem Standort, erhöht aber die Anforderungen an Runbooks, Monitoring, Änderungsprozesse und regelmäßige Ausfalltests.\u003c/p\u003e\n\u003ch2 id=\"4-souveränität-umfasst-auch-den-betrieb\"\u003e4. Souveränität umfasst auch den Betrieb\u003c/h2\u003e\n\u003cp\u003eEigene Netzwerk-Infrastruktur und ein eigenes Autonomous System schaffen die Grundlage, um den öffentlichen Traffic-Eintritt unabhängig von einem einzelnen Infrastrukturprovider zu steuern. Diese Unabhängigkeit ist architektonisch wertvoll, wenn Routing, Schutzfunktionen und Failover nicht vollständig an die Infrastruktur eines einzelnen Anbieters gekoppelt sein sollen.\u003c/p\u003e\n\u003cp\u003eSie bringt aber zusätzliche Betriebsverantwortung mit sich. Routingänderungen müssen nachvollziehbar sein. Health-Check-Fehler brauchen eine eindeutige Interpretation. Failover darf nicht durch widersprüchliche Zustände zwischen mehreren Standorten instabil werden. Auch die Rückkehr eines Standorts in den aktiven Betrieb muss kontrolliert erfolgen, damit kein sogenanntes Flapping entsteht.\u003c/p\u003e\n\u003cp\u003eEine Plattform wie die ayedo Edge Cloud verbindet dafür verteilte Multi-PoP-Infrastruktur, eigenes Netzwerk und Aktiv-Aktiv-Betrieb mit Funktionen für \u003ca href=\"/kubernetes/\"\u003eAnycast-Loadbalancing\u003c/a\u003e\n, Health Checks und Failover. Der relevante Punkt ist nicht die einzelne Funktion, sondern deren Zusammenspiel am öffentlichen Eingang vor Anwendungen und APIs. Die Backends können dabei in ayedo Managed Kubernetes, in eigenen Clustern oder bei anderen Providern betrieben werden.\u003c/p\u003e\n\u003ch2 id=\"praxis--und-betriebsszenario\"\u003ePraxis- und Betriebsszenario\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt eine API in zwei Rechenzentren und möchte keinen Standort als primären öffentlichen Eingang festlegen. Beide Standorte sind über eine Aktiv-Aktiv-Edge erreichbar. Anycast-Routing verteilt neue Verbindungen, während Health Checks die Erreichbarkeit der Edge- und Backend-Komponenten bewerten.\u003c/p\u003e\n\u003cp\u003eFällt die Backend-Anbindung eines Standorts aus, bleibt dessen Netzwerkpfad möglicherweise weiterhin sichtbar. Ohne anwendungsnahe Health Checks würde der Standort deshalb weiterhin Traffic erhalten. Mit abgestimmten Prüfungen kann die Edge den fehlerhaften Pfad aus der Verteilung nehmen. Nach der Reparatur darf die Wiederaufnahme nicht allein durch das Wiedererscheinen einer Route erfolgen, sondern sollte den geprüften Servicezustand berücksichtigen. Der Mehraufwand liegt damit weniger in der zweiten Leitung als in der kontrollierten Zustands- und Änderungslogik.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"ist-aktiv-aktiv-immer-verfügbarer-als-aktiv-passiv\"\u003eIst Aktiv-Aktiv immer verfügbarer als Aktiv-Passiv?\u003c/h3\u003e\n\u003cp\u003eNein. Aktiv-Aktiv reduziert zentrale Eintrittspunkte, erfordert aber präzise Zustandsbewertung und getestetes Failover. Fehlkonfigurierte Health Checks oder instabiles Routing können die Verfügbarkeit sogar verschlechtern.\u003c/p\u003e\n\u003ch3 id=\"welche-rolle-spielt-anycast-im-failover\"\u003eWelche Rolle spielt Anycast im Failover?\u003c/h3\u003e\n\u003cp\u003eAnycast ermöglicht, dass mehrere Standorte dieselbe öffentliche Erreichbarkeit anbieten. Die eigentliche Ausfallsteuerung entsteht erst durch die Kombination aus Routing, Health Checks und Regeln zur Entfernung fehlerhafter Standorte.\u003c/p\u003e\n\u003ch3 id=\"macht-eigene-netzwerkinfrastruktur-automatisch-souverän\"\u003eMacht eigene Netzwerkinfrastruktur automatisch souverän?\u003c/h3\u003e\n\u003cp\u003eNein. Sie schafft technische Kontrollmöglichkeiten über Routing und Traffic-Eintritt. Souveränität hängt zusätzlich von Betriebsprozessen, Abhängigkeiten, Zuständigkeiten und der Fähigkeit ab, Ausfälle kontrolliert zu behandeln.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eEine Aktiv-Aktiv-Architektur für den Edge-Betrieb ist vor allem eine Entscheidung über Kontrolle und Betriebsverantwortung. Sie reduziert die Abhängigkeit von einem einzelnen aktiven Standort, verlangt dafür aber belastbare Verfahren für Routing, Health Checks und Failover. Für Unternehmen mit hohen Anforderungen an öffentlichen Traffic-Eintritt und digitale Souveränität ist die ayedo Edge Cloud relevant, wenn diese Funktionen über eigene Netzwerk-Infrastruktur und verteilte, gleichzeitig aktive Standorte zusammengeführt werden.\u003c/p\u003e\n", "summary": "\nTL;DR Eine Aktiv-Aktiv-Architektur verteilt den öffentlichen Traffic-Eintritt auf mehrere gleichzeitig aktive Standorte. Dadurch entfällt der einzelne aktive Eintrittspunkt als zentrale Ausfallannahme. Der Ansatz erhöht jedoch die Anforderungen an Anycast-Routing, Health Checks, Failover und Betriebsprozesse. Souveränität bedeutet dabei vor allem: Unternehmen kontrollieren Netzwerk, Routinglogik und Ausfallverhalten selbst.\nEinleitung Ein einzelner aktiver Edge-Standort ist kein neutraler Architekturbaustein. Fällt seine Anbindung, seine Routing-Instanz oder ein zentraler Dienst aus, kann der öffentliche Zugang zu ansonsten verfügbaren Backends unterbrochen werden. Ein redundanter Standby-Standort reduziert dieses Risiko, bleibt aber auf einen kontrollierten Umschaltvorgang angewiesen. Die Aktiv-Aktiv-Architektur verfolgt einen anderen Ansatz: Mehrere Standorte nehmen Traffic gleichzeitig an und teilen sich die Verantwortung für den Eintritt in die Plattform . Damit steigt die Hochverfügbarkeit, aber auch die technische Verantwortung für Routing, Zustandsbewertung und Failover. Wer den öffentlichen Traffic-Eintritt selbst kontrollieren will, muss diese Mechanismen als zusammenhängenden Betriebsprozess betrachten.\n", "image": "https://ayedo.de/aktiv-aktiv-architektur-fur-souveranen-edge-betrieb.png", "date_published": "2026-09-04T22:25:59Z", "date_modified": "2026-09-04T22:25:59Z", "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}], "tags": ["digital-sovereignty","cloud-native","politics","kubernetes","software-delivery"], "language": "de" },{ "id": "https://ayedo.de/posts/byoip-als-baustein-digitaler-souveranitat-an-der-edge/", "url": "https://ayedo.de/posts/byoip-als-baustein-digitaler-souveranitat-an-der-edge/", "title": "BYOIP als Baustein digitaler Souveränität an der Edge", "content_html": "\u003cp\u003e\u003cimg src=\"/posts/byoip-als-baustein-digitaler-souveranitat-an-der-edge/byoip-als-baustein-digitaler-souveranitat-an-der-edge.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eBring Your Own IP hält den eigenen IP-Adressraum auch bei wechselnden Edge- oder Cloud-Anbietern unter eigener Kontrolle. Das erleichtert Providerwechsel, stabilisiert Routing- und DNS-Strukturen und reduziert Anpassungen an Sicherheitsrichtlinien. BYOIP ersetzt jedoch keine unabhängige Architektur: Entscheidend ist das Zusammenspiel aus Adressraum, \u003ca href=\"/kubernetes/\"\u003eRouting\u003c/a\u003e\n, DNS, Edge-Schutz und Betriebsprozessen.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eEin Providerwechsel wird technisch aufwendig, wenn sich nicht nur Infrastruktur, sondern auch der öffentliche IP-Adressraum ändert. Dann müssen DNS-Einträge, Allowlisting-Regeln, Firewall-Policies, Zertifikatsprozesse, Monitoring und teilweise auch Dokumentationen angepasst werden. Diese Abhängigkeiten entstehen oft schleichend, weil IP-Adressen als bloße Konfigurationswerte behandelt werden. Bring Your Own IP, kurz BYOIP, setzt an einer anderen Stelle an: Der eigene Adressraum bleibt organisatorisch und architektonisch erhalten, während die Edge-Infrastruktur wechseln kann. Das schafft keine vollständige Unabhängigkeit von Providern. Es reduziert aber die technische Reichweite eines Wechsels und macht öffentliche Erreichbarkeit stärker zu einer kontrollierten Architekturkomponente.\u003c/p\u003e\n\u003ch2 id=\"1-der-eigene-ip-adressraum-als-kontinuitätsanker\"\u003e1. Der eigene IP-Adressraum als Kontinuitätsanker\u003c/h2\u003e\n\u003cp\u003eIP-Adressen sind in vielen Umgebungen Bestandteil von Sicherheits- und Betriebsprozessen. Externe Partner erlauben Verbindungen aus definierten Quellnetzen, Firewalls arbeiten mit festen Regeln, und Monitoring- oder Fraud-Systeme ordnen Traffic bestimmten Adressbereichen zu. Wird dieser Raum bei einem Providerwechsel ersetzt, entsteht ein koordinationsintensiver Migrationspfad.\u003c/p\u003e\n\u003cp\u003eBYOIP trennt den Adressraum von der konkreten Plattform, die ihn nutzt. Unternehmen bringen einen eigenen IPv4- oder IPv6-Adressbereich an eine Edge-Infrastruktur und können dadurch die öffentliche Identität ihrer Services beibehalten. Technisch bleibt der Provider für \u003ca href=\"/kubernetes/\"\u003eRouting\u003c/a\u003e\n, Erreichbarkeit und Betrieb relevant; die Abhängigkeit verschiebt sich jedoch von der Adressvergabe hin zur Nutzung einer standardisierten Routing- und Edge-Leistung.\u003c/p\u003e\n\u003cp\u003eFür digitale Souveränität ist diese Unterscheidung wichtig. Souveränität bedeutet hier nicht, ohne externe Infrastruktur auszukommen. Sie bedeutet, zentrale Architekturentscheidungen – insbesondere die Kontrolle über den öffentlichen Adressraum – nicht vollständig an einen einzelnen Anbieter zu delegieren. BYOIP ist damit ein Kontinuitätsbaustein, kein vollständiges Unabhängigkeitsversprechen.\u003c/p\u003e\n\u003ch2 id=\"2-providerwechsel-weniger-änderungen-aber-kein-selbstläufer\"\u003e2. Providerwechsel: weniger Änderungen, aber kein Selbstläufer\u003c/h2\u003e\n\u003cp\u003eEin Providerwechsel besteht auch mit BYOIP aus mehreren technischen Übergängen. Der eigene IP-Adressraum muss beim neuen Edge-Anbieter technisch eingebunden, geroutet und gegen Missbrauch abgesichert werden. Abhängig vom Design müssen \u003ca href=\"/kubernetes/\"\u003eRouting\u003c/a\u003e\n–Ankündigungen, Validierungen und Zuständigkeiten abgestimmt werden. Der Adressraum allein garantiert daher keine unterbrechungsfreie Migration.\u003c/p\u003e\n\u003cp\u003eDer Vorteil liegt in der reduzierten Änderungsfläche. Systeme, die den öffentlichen IP-Adressraum als Vertrauensanker verwenden, müssen nicht grundsätzlich auf neue Netze umgestellt werden. Das betrifft beispielsweise Partner-Allowlisting, vorgelagerte Netzwerkfilter oder Regelwerke für administrative Zugänge. Auch Dokumentation und Notfallverfahren bleiben konsistenter.\u003c/p\u003e\n\u003cp\u003eDie verbleibenden Abhängigkeiten sollten trotzdem explizit dokumentiert werden: Wer kontrolliert Routing und DNS? Welche Vorlaufzeiten gelten für eine Umstellung? Wie wird der Zustand bei einem Failover überprüft? Eine BYOIP-Architektur ist erst dann belastbar, wenn technische Zuständigkeiten, Freigaben und Rückfallverfahren geklärt sind. Sonst bleibt der Adressraum zwar stabil, der eigentliche Wechsel aber operativ riskant.\u003c/p\u003e\n\u003ch2 id=\"3-routing-und-dns-müssen-gemeinsam-geplant-werden\"\u003e3. Routing und DNS müssen gemeinsam geplant werden\u003c/h2\u003e\n\u003cp\u003eDer IP-Adressraum ist nur ein Teil der öffentlichen Erreichbarkeit. \u003ca href=\"/kubernetes/\"\u003eRouting\u003c/a\u003e\n entscheidet, wohin Pakete gelangen; DNS entscheidet, welche Namen auf welche Endpunkte zeigen. Bei einer Edge-Architektur müssen beide Ebenen zusammenpassen. Ein stabiler Adressraum reduziert DNS-Änderungen, ersetzt aber weder redundante DNS-Strukturen noch ein kontrolliertes Failover.\u003c/p\u003e\n\u003cp\u003eAnycast kann dabei eine wichtige Rolle spielen. Derselbe Dienst beziehungsweise Adressraum wird aus mehreren Netzwerkstandorten erreichbar gemacht, sodass Routing den Traffic zu einem geeigneten Edge-Punkt führt. Das kann die Ausfallsicherheit und Verteilung verbessern, erhöht aber die Anforderungen an Routing-Transparenz, Health Checks und Fehleranalyse. Eine Route kann erreichbar sein, während ein Backend oder eine Region bereits gestört ist.\u003c/p\u003e\n\u003cp\u003eDie ayedo Edge Cloud verbindet BYOIP mit eigener Netzwerk-Infrastruktur, eigenem Autonomous System und einer verteilten Multi-PoP-Architektur im Aktiv-Aktiv-Prinzip. Für Unternehmen ist daran vor allem die Trennung von Adressraum und Compute-Standort relevant: Backends können in unterschiedlichen Umgebungen betrieben werden, während der öffentliche Einstieg an der Edge konsistent bleibt. Anycast DNS und Multi-Provider-DNS adressieren ergänzend die Namensauflösung, nicht jedoch automatisch alle Routingfragen.\u003c/p\u003e\n\u003ch2 id=\"4-sicherheitsrichtlinien-überleben-den-infrastrukturwechsel\"\u003e4. Sicherheitsrichtlinien überleben den Infrastrukturwechsel\u003c/h2\u003e\n\u003cp\u003eSicherheitsrichtlinien sind häufig stärker an IP-Adressen gekoppelt, als es die ursprüngliche Architektur vermuten lässt. Quell-IP-Allowlisting, Netzwerkzugriffe von Partnern, DDoS-Ausnahmen oder Regeln für administrative Schnittstellen können bei einem Adresswechsel zu Ausfällen führen. BYOIP reduziert diese Umstellungen, weil der kontrollierte öffentliche Adressraum erhalten bleibt.\u003c/p\u003e\n\u003cp\u003eDas bedeutet nicht, dass Sicherheitsrichtlinien unverändert bleiben sollten. An der Edge können TLS Termination, Web Application Firewall und DDoS Protection den Schutz vor den Backends bündeln. Backend Cloaking verhindert zusätzlich, dass interne Zielsysteme als öffentliche Angriffsfläche behandelt werden müssen. Die Sicherheitsgrenze verschiebt sich damit bewusst an den öffentlichen Eingang, während Compute-Umgebungen getrennt betrieben werden können.\u003c/p\u003e\n\u003cp\u003eFür die Praxis ist entscheidend, Regelwerke nicht ausschließlich mit „bekannten IPs“ zu begründen. IP-Adressen identifizieren einen Adressraum, aber nicht automatisch einen legitimen Request. Anwendungsschutz, Identitäten, Protokollkontext und Backend-Health müssen weiterhin berücksichtigt werden. BYOIP bewahrt also die technische Kontinuität von Netzwerkregeln; es ersetzt keine mehrschichtige Sicherheitsarchitektur.\u003c/p\u003e\n\u003ch2 id=\"praxis--und-betriebsszenario\"\u003ePraxis- und Betriebsszenario\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt eine API auf einem eigenen \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n-Cluster und nutzt für den öffentlichen Zugang eine Edge-Plattform. Ohne BYOIP führt ein Providerwechsel zu neuen öffentlichen IPs. Partner müssen Allowlisting anpassen, DNS-TTLs und Umschaltfenster werden kritisch, und alte Regeln müssen kontrolliert entfernt werden.\u003c/p\u003e\n\u003cp\u003eMit BYOIP bleibt der eigene Adressraum erhalten. Die neue Edge-Plattform übernimmt \u003ca href=\"/kubernetes/\"\u003eRouting\u003c/a\u003e\n, TLS Termination, WAF und DDoS-Schutz; das Backend bleibt über einen abgeschirmten Zugang erreichbar. DNS kann stabiler bleiben, während der Wechsel über Health Checks und ein abgestimmtes Failover-Verfahren validiert wird. Die Migration wird dadurch nicht automatisch unterbrechungsfrei, aber die Zahl der gleichzeitig zu ändernden Komponenten sinkt deutlich.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"ist-byoip-gleichbedeutend-mit-vollständiger-providerunabhängigkeit\"\u003eIst BYOIP gleichbedeutend mit vollständiger Providerunabhängigkeit?\u003c/h3\u003e\n\u003cp\u003eNein. \u003ca href=\"/kubernetes/\"\u003eRouting\u003c/a\u003e\n, Edge-Betrieb, DNS und Schutzfunktionen können weiterhin von Providern abhängen. BYOIP reduziert vor allem die Abhängigkeit beim öffentlichen Adressraum.\u003c/p\u003e\n\u003ch3 id=\"eignet-sich-byoip-nur-für-einen-einzelnen-cloud-anbieter\"\u003eEignet sich BYOIP nur für einen einzelnen Cloud-Anbieter?\u003c/h3\u003e\n\u003cp\u003eNein. Der eigene Adressraum kann grundsätzlich an unterschiedliche Edge- oder Cloud-Umgebungen angebunden werden. Die konkrete technische Umsetzung hängt von \u003ca href=\"/kubernetes/\"\u003eRouting\u003c/a\u003e\n, Validierung und den jeweiligen Betriebsprozessen ab.\u003c/p\u003e\n\u003ch3 id=\"welche-rolle-spielt-kubernetes\"\u003eWelche Rolle spielt Kubernetes?\u003c/h3\u003e\n\u003cp\u003e\u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n ist nur eine mögliche Backend-Umgebung. Die Edge übernimmt den öffentlichen Eingang unabhängig davon, ob der Cluster bei ayedo, im eigenen Rechenzentrum oder bei einem anderen Provider betrieben wird.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eBYOIP ist kein isoliertes Netzwerkfeature, sondern ein Architekturbaustein für technische Kontinuität. Der eigene IP-Adressraum bleibt bei Plattform- und Providerwechseln kontrollierbar und reduziert dadurch Anpassungen an DNS, Allowlisting und Betriebsprozessen. Seine Wirkung entsteht jedoch erst im Zusammenspiel mit \u003ca href=\"/kubernetes/\"\u003eRouting\u003c/a\u003e\n, Multi-Provider-DNS, Edge-Schutz und klaren Failover-Verfahren. Die ayedo Edge Cloud ordnet BYOIP in eine providerunabhängige Edge-Architektur mit eigener Netzwerkinfrastruktur, Anycast und Aktiv-Aktiv-Betrieb ein.\u003c/p\u003e\n", "summary": "\nTL;DR Bring Your Own IP hält den eigenen IP-Adressraum auch bei wechselnden Edge- oder Cloud-Anbietern unter eigener Kontrolle. Das erleichtert Providerwechsel, stabilisiert Routing- und DNS-Strukturen und reduziert Anpassungen an Sicherheitsrichtlinien. BYOIP ersetzt jedoch keine unabhängige Architektur: Entscheidend ist das Zusammenspiel aus Adressraum, Routing , DNS, Edge-Schutz und Betriebsprozessen.\nEinleitung Ein Providerwechsel wird technisch aufwendig, wenn sich nicht nur Infrastruktur, sondern auch der öffentliche IP-Adressraum ändert. Dann müssen DNS-Einträge, Allowlisting-Regeln, Firewall-Policies, Zertifikatsprozesse, Monitoring und teilweise auch Dokumentationen angepasst werden. Diese Abhängigkeiten entstehen oft schleichend, weil IP-Adressen als bloße Konfigurationswerte behandelt werden. Bring Your Own IP, kurz BYOIP, setzt an einer anderen Stelle an: Der eigene Adressraum bleibt organisatorisch und architektonisch erhalten, während die Edge-Infrastruktur wechseln kann. Das schafft keine vollständige Unabhängigkeit von Providern. Es reduziert aber die technische Reichweite eines Wechsels und macht öffentliche Erreichbarkeit stärker zu einer kontrollierten Architekturkomponente.\n", "image": "https://ayedo.de/byoip-als-baustein-digitaler-souveranitat-an-der-edge.png", "date_published": "2026-09-04T22:25:59Z", "date_modified": "2026-09-04T22:25:59Z", "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}], "tags": ["digital-sovereignty","security","operations","kubernetes","cloud-native"], "language": "de" },{ "id": "https://ayedo.de/posts/souverane-edge-cloud-fur-den-technischen-multi-cloud-betrieb/", "url": "https://ayedo.de/posts/souverane-edge-cloud-fur-den-technischen-multi-cloud-betrieb/", "title": "Souveräne Edge Cloud für den technischen Multi-Cloud-Betrieb", "content_html": "\u003cp\u003e\u003cimg src=\"/posts/souverane-edge-cloud-fur-den-technischen-multi-cloud-betrieb/souverane-edge-cloud-fur-den-technischen-multi-cloud-betrieb.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eEine Multi-Cloud-Architektur wird schwer beherrschbar, wenn jeder Provider eigene öffentliche Einstiegspunkte, Routingregeln und Schutzmechanismen betreibt. Eine providerunabhängige Edge Cloud bündelt diese Funktionen vor heterogenen Compute-Umgebungen. Sie trennt öffentlichen Traffic von den Backends und schafft eine zentrale Schicht für Routing, Security, TLS, Failover und Betrieb.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eDer häufigste Architekturfehler im Multi-Cloud-Betrieb ist nicht die Nutzung mehrerer Provider, sondern die Verteilung des öffentlichen Eingangs auf deren jeweilige Plattformen. Dadurch entstehen unterschiedliche DNS-Modelle, Loadbalancer, Security-Regeln, Zertifikatsprozesse und Betriebsverantwortlichkeiten. Anwendungen laufen dann zwar verteilt, werden aber von uneinheitlichen Edge-Strukturen erreicht.\u003c/p\u003e\n\u003cp\u003eEine Multi-Cloud Edge Cloud setzt an einem anderen Punkt an: Sie bildet eine eigenständige Infrastruktur-Schicht zwischen Internet und Compute. \u003ca href=\"https://www.kubernetes.com/\" target=\"_blank\" rel=\"noopener\"\u003eKubernetes\u003c/a\u003e\n–Cluster, virtuelle Maschinen oder andere Backends können bei unterschiedlichen Providern betrieben werden, während zentrale Funktionen an der Edge verbleiben. Diese Trennung reduziert Abhängigkeiten, verändert aber auch die Anforderungen an Routing, Zustandsmanagement und Betrieb.\u003c/p\u003e\n\u003ch2 id=\"1-die-edge-als-eigenständige-plattform-schicht\"\u003e1. Die Edge als eigenständige Plattform-Schicht\u003c/h2\u003e\n\u003cp\u003eIn einer Multi-Cloud-Architektur sollten Edge und Compute nicht als dasselbe System betrachtet werden. Compute-Infrastrukturen führen Anwendungen aus. Die Edge Cloud übernimmt dagegen den öffentlichen Traffic-Eingang, verarbeitet Verbindungen und entscheidet, welches Backend eine Anfrage erreicht. Diese Verantwortungsgrenze bleibt auch dann sinnvoll, wenn die Anwendung in \u003ca href=\"https://www.kubernetes.com/\" target=\"_blank\" rel=\"noopener\"\u003eKubernetes\u003c/a\u003e\n läuft.\u003c/p\u003e\n\u003cp\u003eEine eigenständige Edge-Schicht abstrahiert die Unterschiede zwischen ayedo Managed \u003ca href=\"https://www.kubernetes.com/\" target=\"_blank\" rel=\"noopener\"\u003eKubernetes\u003c/a\u003e\n, eigenen Clustern und Kubernetes-Umgebungen anderer Provider. Für den Client bleibt der öffentliche Einstieg konsistent, während Backends technisch und organisatorisch unterschiedlich betrieben werden können. Providerwechsel oder zusätzliche Cluster müssen dadurch nicht automatisch zu einer neuen öffentlichen Architektur führen.\u003c/p\u003e\n\u003cp\u003eDie Providerunabhängigkeit entsteht allerdings nicht allein durch mehrere DNS-Einträge. Entscheidend ist, wo Routing, TLS-Termination, Schutzfunktionen und Health Checks ausgeführt werden. Werden diese Funktionen jeweils im Provider-Ökosystem implementiert, bleiben sie an dessen Netzwerk und Betriebsmodell gekoppelt. Eine eigene Edge-Infrastruktur mit eigenem Autonomous System schafft hier eine separate technische Zuständigkeit.\u003c/p\u003e\n\u003ch2 id=\"2-zentrales-traffic-routing-über-heterogene-backends\"\u003e2. Zentrales Traffic-Routing über heterogene Backends\u003c/h2\u003e\n\u003cp\u003eFür das Routing in einer Multi-Cloud-Umgebung müssen zwei Ebenen zusammenspielen: die Erreichbarkeit des Dienstes und die Auswahl eines geeigneten Backends. Anycast kann den öffentlichen Einstieg über eine verteilte Edge-Architektur bereitstellen. Layer-4- und Layer-7-Loadbalancing ermöglichen anschließend eine differenzierte Verteilung, abhängig von Verbindung, Protokoll oder Anwendungskontext.\u003c/p\u003e\n\u003cp\u003eHealth Checks sind dabei mehr als eine Komfortfunktion. Ohne verlässliche Zustandsprüfung kann ein Edge-System Traffic an einen technisch erreichbaren, aber operativ nicht funktionsfähigen Dienst weiterleiten. Failover muss deshalb an den tatsächlichen Backend-Zustand gekoppelt sein. Das gilt gleichermaßen für \u003ca href=\"https://www.kubernetes.com/\" target=\"_blank\" rel=\"noopener\"\u003eKubernetes\u003c/a\u003e\n–Cluster bei ayedo, in eigener Infrastruktur oder bei einem anderen Provider.\u003c/p\u003e\n\u003cp\u003eEin zentraler Routingpunkt erleichtert zudem kontrollierte Änderungen. Neue Cluster können schrittweise eingebunden, einzelne Backends aus dem Traffic genommen oder Lasten zwischen Providern verteilt werden. Die konkrete Routinglogik muss zur Anwendung passen: Zustandsbehaftete Sessions, regionale Anforderungen und unterschiedliche Kapazitäten können den Betrieb komplex machen. Die Edge reduziert diese Komplexität nicht automatisch, sie macht sie aber zentral steuerbar.\u003c/p\u003e\n\u003ch2 id=\"3-security-und-termination-dort-bündeln-wo-traffic-entsteht\"\u003e3. Security und Termination dort bündeln, wo Traffic entsteht\u003c/h2\u003e\n\u003cp\u003eSecurity-Funktionen sind im Multi-Cloud-Betrieb besonders anfällig für Fragmentierung. Wenn jede Compute-Plattform eigene WAF-Regeln, DDoS-Mechanismen und TLS-Konfigurationen verwendet, entstehen unterschiedliche Schutzprofile und mehrere Änderungsprozesse. Ein zentraler Schutz an der Edge kann diese Funktionen vor die heterogenen Backends verlagern.\u003c/p\u003e\n\u003cp\u003eDie ayedo Edge Cloud unterstützt diesen Ansatz mit einer Web Application Firewall für HTTP- und HTTPS-Services sowie DDoS Protection und Scrubbing an der Edge. TLS kann dort terminiert werden, bevor der Traffic weitergeleitet wird. Backend Cloaking verhindert, dass die eigentlichen Ursprungsadressen als öffentlicher Einstieg dienen. Das reduziert die direkte Sichtbarkeit der Backends und unterstützt eine klare Trennung zwischen Edge und Compute.\u003c/p\u003e\n\u003cp\u003eDiese Zentralisierung ersetzt keine Absicherung der Backends. Netzwerkzugriffe, Authentisierung und interne Sicherheitskontrollen bleiben Aufgaben der jeweiligen Umgebung. Sie schafft jedoch einen einheitlichen Kontrollpunkt für eingehende Verbindungen. Auch BYOIP kann relevant sein, wenn öffentliche Adressräume unabhängig von einem einzelnen Compute-Provider betrieben werden sollen.\u003c/p\u003e\n\u003ch2 id=\"4-betrieb-zuständigkeiten-und-digitale-souveränität\"\u003e4. Betrieb, Zuständigkeiten und digitale Souveränität\u003c/h2\u003e\n\u003cp\u003eEine providerunabhängige Edge verbessert nicht nur die technische Topologie, sondern verschiebt auch Betriebsverantwortung. DNS, Traffic-Routing, Zertifikate, WAF-Regeln, DDoS-Schutz und Backend-Failover werden zu zentralen Plattformaufgaben. Das verlangt klare Zuständigkeiten, standardisierte Änderungen und nachvollziehbare Statistiken über Traffic und Nutzung.\u003c/p\u003e\n\u003cp\u003eDie ayedo Edge Cloud verbindet dafür Anycast DNS und Multi-Provider-DNS mit den Funktionen der Edge-Plattform. Das eigene Autonomous System und die eigene Netzwerk-Infrastruktur sind dabei keine Marketingattribute, sondern Bestandteile der technischen Unabhängigkeit vom Compute-Provider. Die verteilte Multi-PoP-Architektur und das Aktiv-Aktiv-Prinzip unterstützen eine Edge, die nicht auf einen einzelnen Betriebsort reduziert ist.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.kubernetes.com/\" target=\"_blank\" rel=\"noopener\"\u003eKubernetes\u003c/a\u003e\n bleibt in diesem Modell ein Compute- und Orchestrierungsbaustein, nicht die Definition der gesamten Eingangsschicht. Die Edge Cloud lässt sich mit ayedo Managed Kubernetes ebenso wie mit eigenen oder bei anderen Providern betriebenen Kubernetes-Clustern nutzen. Dadurch kann ein Unternehmen Plattformgrenzen bewusst festlegen, statt öffentliche Erreichbarkeit und Workload-Orchestrierung an denselben Anbieter zu binden.\u003c/p\u003e\n\u003ch2 id=\"praxis--und-betriebsszenario\"\u003ePraxis- und Betriebsszenario\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt einen \u003ca href=\"https://www.kubernetes.com/\" target=\"_blank\" rel=\"noopener\"\u003eKubernetes\u003c/a\u003e\n–Cluster bei ayedo, einen zweiten in eigener Infrastruktur und einen dritten bei einem weiteren Provider. Alle drei Umgebungen stellen dieselbe Anwendung bereit, unterscheiden sich aber bei Netzwerk, Ingress-Konfiguration und Betriebsprozessen.\u003c/p\u003e\n\u003cp\u003eMit separaten Provider-Loadbalancern müsste das Unternehmen DNS, TLS, WAF-Regeln und Failover mehrfach pflegen. In einer zentralen Edge-Architektur zeigt der öffentliche DNS auf die Edge. Dort werden TLS und WAF verarbeitet, Health Checks bewerten die Backends, und das Routing verteilt Anfragen auf verfügbare Cluster. Fällt eine Umgebung aus, kann sie aus dem Traffic genommen werden, ohne den öffentlichen Einstieg neu zu gestalten. Die Compute-Provider bleiben austauschbare Backend-Standorte.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"ist-eine-edge-cloud-nur-für-kubernetes-relevant\"\u003eIst eine Edge Cloud nur für Kubernetes relevant?\u003c/h3\u003e\n\u003cp\u003eNein. \u003ca href=\"https://www.kubernetes.com/\" target=\"_blank\" rel=\"noopener\"\u003eKubernetes\u003c/a\u003e\n ist ein möglicher Backend-Typ. Eine Edge Cloud kann auch Anwendungen und APIs vor anderen Compute-Umgebungen schützen, terminieren und an erreichbare Backends weiterleiten.\u003c/p\u003e\n\u003ch3 id=\"muss-jeder-provider-dieselbe-netzwerkarchitektur-verwenden\"\u003eMuss jeder Provider dieselbe Netzwerkarchitektur verwenden?\u003c/h3\u003e\n\u003cp\u003eNein. Gerade die Edge-Schicht kann Unterschiede zwischen Providern kapseln. Die Backends müssen jedoch über definierte, überprüfbare Wege erreichbar sein und passende Health Checks unterstützen.\u003c/p\u003e\n\u003ch3 id=\"ersetzt-zentrales-edge-routing-die-provider-dns-dienste\"\u003eErsetzt zentrales Edge-Routing die Provider-DNS-Dienste?\u003c/h3\u003e\n\u003cp\u003eNicht vollständig. Die Edge kann Anycast DNS und Multi-Provider-DNS zentral einbinden. Providerinterne DNS-Zonen und interne Namensauflösung bleiben davon getrennte Aufgaben.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eEine souveräne Multi-Cloud-Architektur entsteht nicht dadurch, dass Anwendungen lediglich auf mehrere Provider verteilt werden. Entscheidend ist eine klare Trennung zwischen öffentlichem Eingang und heterogener Compute-Infrastruktur. Eine eigenständige Edge-Schicht zentralisiert Traffic-Routing, Schutz, TLS, Failover und Sichtbarkeit, ohne \u003ca href=\"https://www.kubernetes.com/\" target=\"_blank\" rel=\"noopener\"\u003eKubernetes\u003c/a\u003e\n an einen einzelnen Anbieter zu binden. Die ayedo Edge Cloud ist in diesem Modell eine providerunabhängige Plattform vor ayedo, eigenen und fremden Kubernetes-Umgebungen – mit eigener Netzwerk-Infrastruktur und eigenem Autonomous System als Teil der technischen Betriebsgrenze.\u003c/p\u003e\n", "summary": "\nTL;DR Eine Multi-Cloud-Architektur wird schwer beherrschbar, wenn jeder Provider eigene öffentliche Einstiegspunkte, Routingregeln und Schutzmechanismen betreibt. Eine providerunabhängige Edge Cloud bündelt diese Funktionen vor heterogenen Compute-Umgebungen. Sie trennt öffentlichen Traffic von den Backends und schafft eine zentrale Schicht für Routing, Security, TLS, Failover und Betrieb.\nEinleitung Der häufigste Architekturfehler im Multi-Cloud-Betrieb ist nicht die Nutzung mehrerer Provider, sondern die Verteilung des öffentlichen Eingangs auf deren jeweilige Plattformen. Dadurch entstehen unterschiedliche DNS-Modelle, Loadbalancer, Security-Regeln, Zertifikatsprozesse und Betriebsverantwortlichkeiten. Anwendungen laufen dann zwar verteilt, werden aber von uneinheitlichen Edge-Strukturen erreicht.\n", "image": "https://ayedo.de/souverane-edge-cloud-fur-den-technischen-multi-cloud-betrieb.png", "date_published": "2026-09-04T22:25:59Z", "date_modified": "2026-09-04T22:25:59Z", "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}], "tags": ["kubernetes","security","digital-sovereignty","cloud","cloud-native"], "language": "de" },{ "id": "https://ayedo.de/posts/exit-fahigkeit-edge-architekturen-ohne-providerbindung/", "url": "https://ayedo.de/posts/exit-fahigkeit-edge-architekturen-ohne-providerbindung/", "title": "Exit-Fähigkeit: Edge-Architekturen ohne Providerbindung", "content_html": "\u003cp\u003e\u003cimg src=\"/posts/exit-fahigkeit-edge-architekturen-ohne-providerbindung/exit-fahigkeit-edge-architekturen-ohne-providerbindung.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eExit-Fähigkeit in der Cloud entsteht nicht allein durch mehrere Compute-Provider. Entscheidend ist, welche Funktionen vor den Workloads unabhängig betrieben werden: öffentliche Erreichbarkeit, TLS-Terminierung, Schutz und Routing. Eine providerunabhängige Edge-Schicht reduziert Migrationsaufwand, beseitigt aber nicht jede Abhängigkeit. DNS, Identitäten, Daten, Secrets und Workload-Schnittstellen bleiben kritisch.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eEin Providerwechsel scheitert selten am Verschieben einzelner \u003ca href=\"/kubernetes/\"\u003eContainer\u003c/a\u003e\n. Problematisch ist vielmehr die öffentliche Eintrittskette: IP-Adressen, DNS, TLS-Zertifikate, WAF-Regeln, DDoS-Schutz und Routing sind häufig eng an den bisherigen Compute-Provider gekoppelt. Wer diese Funktionen gemeinsam mit den Backends betreibt, muss beim Wechsel nicht nur Anwendungen migrieren, sondern auch deren Erreichbarkeit und Schutz neu aufbauen. Die zentrale Architekturentscheidung lautet deshalb: Welche Aufgaben gehören zur Compute-Plattform, und welche sollten davor providerunabhängig betrieben werden? Eine eigenständige Edge-Schicht verbessert die Exit-Fähigkeit Cloud, wenn sie öffentliche Zugänge und Sicherheitsfunktionen von den Backend-Zielen entkoppelt.\u003c/p\u003e\n\u003ch2 id=\"1-beweglich-bleibt-nur-was-nicht-am-compute-provider-hängt\"\u003e1. Beweglich bleibt nur, was nicht am Compute-Provider hängt\u003c/h2\u003e\n\u003cp\u003eBei einer klassischen Providerarchitektur liegen öffentliche IPs, Loadbalancer, TLS-Terminierung und WAF häufig im selben Netzwerk- und Service-Modell wie die Workloads. Der Providerwechsel wird dadurch zu einer Umstellung der gesamten Eingangskette. Selbst wenn \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n -Manifeste portabel sind, müssen externe Loadbalancer, Security Policies, Zertifikate und DNS-Einträge neu abgebildet werden.\u003c/p\u003e\n\u003cp\u003eEine separate Edge-Schicht verschiebt diese Verantwortung vor den Compute-Provider. Sie kann Anfragen an Backends in unterschiedlichen Netzwerken oder bei unterschiedlichen Providern weiterleiten. Beim Wechsel bleibt der öffentliche Einstiegspunkt grundsätzlich erhalten; geändert wird primär das Backend-Ziel. Besonders relevant ist Bring Your Own IP: Werden eigene öffentliche Adressbereiche an der Edge genutzt, muss die Erreichbarkeit nicht zwangsläufig an providergebundene IPs gekoppelt werden. Ohne BYOIP bleibt die öffentliche Adresse selbst ein Migrationsobjekt.\u003c/p\u003e\n\u003ch2 id=\"2-tls-und-schutzfunktionen-werden-zu-unabhängigen-betriebsdomänen\"\u003e2. TLS und Schutzfunktionen werden zu unabhängigen Betriebsdomänen\u003c/h2\u003e\n\u003cp\u003eTLS-Terminierung, WAF und DDoS-Schutz sind nicht nur technische Zusatzfunktionen. Sie bestimmen, wo Zertifikate, Regeln, Logs und Incident-Prozesse betrieben werden. Sind sie fest in den Cloud-Loadbalancer eines Providers integriert, müssen Konfigurationen beim Wechsel vollständig übertragen oder neu implementiert werden. Dabei entstehen Risiken: Schutzregeln fehlen, Zertifikate werden verspätet ausgerollt oder der neue Eingang ist noch nicht ausreichend getestet.\u003c/p\u003e\n\u003cp\u003eEine providerunabhängige Edge Cloud kann diese Funktionen zentral vor mehreren Backends bereitstellen. ayedo Edge Cloud übernimmt TLS-Terminierung an der Edge sowie WAF und DDoS Protection beziehungsweise Scrubbing vor den eigentlichen Anwendungen. Dadurch bleiben die Sicherheitskontrollen unabhängig davon, ob ein Backend in ayedo Managed \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n, einem eigenen Kubernetes-Cluster oder bei einem anderen Provider läuft. Die Abhängigkeit verschwindet jedoch nicht vollständig: Zertifikatsmaterial, Regelpflege, Freigabeprozesse und die Fähigkeit, Konfigurationen reproduzierbar zu verwalten, müssen organisatorisch und technisch beherrscht werden.\u003c/p\u003e\n\u003ch2 id=\"3-backend-cloaking-reduziert-aber-ersetzt-keine-portabilität\"\u003e3. Backend Cloaking reduziert, aber ersetzt keine Portabilität\u003c/h2\u003e\n\u003cp\u003eEin Providerwechsel wird schwieriger, wenn Backends direkt öffentlich adressierbar sind. Dann müssen Anwendungen mehrere Eintrittspunkte absichern, Quellnetze erlauben und bei einer Migration parallel mit alten und neuen Endpunkten umgehen. Außerdem können interne Topologie, Provideradressen oder Clusterstrukturen nach außen sichtbar werden.\u003c/p\u003e\n\u003cp\u003eBackend Cloaking trennt den öffentlichen Zugang von den tatsächlichen Backend-Zielen. Die Clients sehen die Edge, nicht die Adressen und Struktur der dahinterliegenden Systeme. Routing, Health Checks und Failover können an der Edge gesteuert werden, während Backends ausgetauscht oder zwischen Providern verschoben werden. ayedo Edge Cloud unterstützt diese Entkopplung als öffentliche Edge vor Anwendungen und APIs. Sie macht Workloads jedoch nicht automatisch portabel. Datenbanken, Storage, Identitätsdienste, proprietäre APIs, Netzwerkfreigaben und Workload-spezifische Abhängigkeiten bleiben an ihrer jeweiligen Plattform. Exit-Fähigkeit bedeutet daher nicht Providerfreiheit in jedem Layer, sondern eine bewusst begrenzte und dokumentierte Bindung.\u003c/p\u003e\n\u003ch2 id=\"4-dns-und-betriebsprozesse-entscheiden-über-den-tatsächlichen-exit\"\u003e4. DNS und Betriebsprozesse entscheiden über den tatsächlichen Exit\u003c/h2\u003e\n\u003cp\u003eEine stabile Edge-Adresse löst nicht alle Migrationsprobleme. DNS bleibt eine eigenständige Kontroll- und Abhängigkeitsebene. Authoritative DNS, Registrar, TTLs, DNSSEC, Failover-Logik und Zertifikatsvalidierung müssen in den Exit-Plan einbezogen werden. Eine Multi-Provider-DNS-Architektur kann die Abhängigkeit von einem einzelnen DNS-Anbieter reduzieren, erhöht aber den Konfigurations- und Testaufwand.\u003c/p\u003e\n\u003cp\u003eAuch der Betrieb muss providerunabhängig organisiert sein. Dazu gehören standardisierte Backend-Schnittstellen, reproduzierbare Edge-Konfigurationen, Health-Check-Kriterien und klare Zuständigkeiten für Routingänderungen. Anycast-basierte Edge-Architekturen mit eigenem Autonomous System und eigener Netzwerkinfrastruktur können den öffentlichen Zugang von einzelnen Compute-Netzen entkoppeln. Die Aktiv-Aktiv-Ausrichtung der ayedo Edge Cloud unterstützt dabei eine verteilte Betriebsarchitektur. Entscheidend bleibt jedoch, ob ein Unternehmen den Wechsel regelmäßig testen kann. Ein ungenutzter Exit-Plan ist keine belastbare Exit-Fähigkeit Cloud.\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=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n -Cluster bei Provider A. Der öffentliche Loadbalancer, TLS und die WAF stammen aus dessen Plattform. Für den Wechsel zu Provider B muss das Unternehmen DNS umstellen, Zertifikate neu anbinden, Schutzregeln übertragen und den neuen Eingang parallel testen.\u003c/p\u003e\n\u003cp\u003eIn einer entkoppelten Variante terminieren TLS und Schutzfunktionen an einer providerunabhängigen Edge. Das Backend-Ziel wird zunächst zusätzlich auf den Cluster bei Provider B erweitert. Health Checks steuern, welcher Standort Traffic erhält. Nach erfolgreicher Validierung wird Provider A entfernt. Mit BYOIP kann zusätzlich die öffentliche Adressierung erhalten bleiben. Die Migration betrifft dann weiterhin Daten, Secrets und Workload-Anbindungen, aber nicht die komplette öffentliche Eingangsschicht.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"ist-multi-cloud-automatisch-exit-fähig\"\u003eIst Multi-Cloud automatisch exit-fähig?\u003c/h3\u003e\n\u003cp\u003eNein. Mehrere Provider erhöhen zunächst die Komplexität. Exit-Fähigkeit entsteht erst durch entkoppelte Schnittstellen, portable Konfigurationen und getestete Abläufe für Routing, DNS, Security und Datenmigration.\u003c/p\u003e\n\u003ch3 id=\"welche-rolle-spielt-byoip-beim-providerwechsel\"\u003eWelche Rolle spielt BYOIP beim Providerwechsel?\u003c/h3\u003e\n\u003cp\u003eBYOIP kann öffentliche IP-Erreichbarkeit von den Adressen eines Compute-Providers lösen. Es beseitigt jedoch keine Abhängigkeiten bei DNS, Zertifikaten, Backends, Daten oder Netzwerkfreigaben.\u003c/p\u003e\n\u003ch3 id=\"macht-backend-cloaking-backends-vollständig-unabhängig\"\u003eMacht Backend Cloaking Backends vollständig unabhängig?\u003c/h3\u003e\n\u003cp\u003eNein. Backend Cloaking verbirgt und entkoppelt den öffentlichen Zugang. Anwendungen bleiben dennoch von Datenbanken, Identitäten, Storage, Netzwerkpfaden und providerabhängigen Diensten abhängig.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eExit-Fähigkeit Cloud ist eine Frage der Abgrenzung: Der öffentliche Eingang sollte nicht automatisch Teil der Compute-Plattform sein. Eine unabhängige Edge-Schicht macht IP-Erreichbarkeit, TLS, Schutz und Routing beweglicher, während Daten- und Laufzeitabhängigkeiten separat bewertet werden müssen. Die ayedo Edge Cloud ordnet diese Funktionen in einer eigenen, Anycast-basierten Plattform vor unterschiedlichen Backend-Umgebungen ein. Damit wird ein Providerwechsel planbarer – vorausgesetzt, DNS, Konfigurationen und Betriebsprozesse sind ebenso entkoppelt und getestet.\u003c/p\u003e\n", "summary": "\nTL;DR Exit-Fähigkeit in der Cloud entsteht nicht allein durch mehrere Compute-Provider. Entscheidend ist, welche Funktionen vor den Workloads unabhängig betrieben werden: öffentliche Erreichbarkeit, TLS-Terminierung, Schutz und Routing. Eine providerunabhängige Edge-Schicht reduziert Migrationsaufwand, beseitigt aber nicht jede Abhängigkeit. DNS, Identitäten, Daten, Secrets und Workload-Schnittstellen bleiben kritisch.\nEinleitung Ein Providerwechsel scheitert selten am Verschieben einzelner Container . Problematisch ist vielmehr die öffentliche Eintrittskette: IP-Adressen, DNS, TLS-Zertifikate, WAF-Regeln, DDoS-Schutz und Routing sind häufig eng an den bisherigen Compute-Provider gekoppelt. Wer diese Funktionen gemeinsam mit den Backends betreibt, muss beim Wechsel nicht nur Anwendungen migrieren, sondern auch deren Erreichbarkeit und Schutz neu aufbauen. Die zentrale Architekturentscheidung lautet deshalb: Welche Aufgaben gehören zur Compute-Plattform, und welche sollten davor providerunabhängig betrieben werden? Eine eigenständige Edge-Schicht verbessert die Exit-Fähigkeit Cloud, wenn sie öffentliche Zugänge und Sicherheitsfunktionen von den Backend-Zielen entkoppelt.\n", "image": "https://ayedo.de/exit-fahigkeit-edge-architekturen-ohne-providerbindung.png", "date_published": "2026-09-04T22:25:58Z", "date_modified": "2026-09-04T22:25:58Z", "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}], "tags": ["security","kubernetes","cloud-native","hosting","digital-sovereignty"], "language": "de" },{ "id": "https://ayedo.de/posts/jurisdiktion-und-technische-kontrolle-an-der-edge/", "url": "https://ayedo.de/posts/jurisdiktion-und-technische-kontrolle-an-der-edge/", "title": "Jurisdiktion und technische Kontrolle an der Edge", "content_html": "\u003cp\u003e\u003cimg src=\"/posts/jurisdiktion-und-technische-kontrolle-an-der-edge/jurisdiktion-und-technische-kontrolle-an-der-edge.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eJurisdiktion in der Cloud beschreibt rechtliche Zuständigkeiten, nicht automatisch die technische Kontrolle über Datenflüsse und Infrastruktur. Für die Bewertung einer Edge-Architektur müssen deshalb Routing, Traffic-Verarbeitung, TLS-Terminierung, Backend-Abschirmung und Betriebsprozesse getrennt betrachtet werden. Die ayedo Edge Cloud schafft technische Kontrollpunkte, ersetzt aber keine rechtliche Prüfung.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eDie Annahme, ein bestimmter Infrastrukturstandort löse automatisch alle Fragen zur Jurisdiktion der Cloud-Infrastruktur, führt in der Praxis zu falschen Entscheidungen. Rechtliche Zuständigkeiten ergeben sich aus mehreren Faktoren: beteiligten Unternehmen, Vertragsbeziehungen, Datenverarbeitung und anwendbarem Recht. Technische Kontrolle ist davon zu unterscheiden. Sie beschreibt, wer Routing, Traffic-Verarbeitung, Verschlüsselung und Backend-Zugriffe tatsächlich steuert. Für Unternehmen ist diese Trennung entscheidend, weil eine rechtlich zulässige Architektur nicht zwangsläufig ausreichend kontrollierbar ist – und technische Kontrolle umgekehrt keine Rechtsgarantie darstellt.\u003c/p\u003e\n\u003ch2 id=\"1-jurisdiktion-und-technische-kontrolle-sind-unterschiedliche-ebenen\"\u003e1. Jurisdiktion und technische Kontrolle sind unterschiedliche Ebenen\u003c/h2\u003e\n\u003cp\u003eJurisdiktion bezeichnet den rechtlichen Rahmen, dem Unternehmen, Verträge und Verarbeitungsprozesse unterliegen. Sie ist keine rein technische Eigenschaft eines Rechenzentrums oder eines Netzwerks. Selbst wenn ein Backend in einer bestimmten Region betrieben wird, können weitere Akteure, Dienste oder Vertragsbeziehungen für die rechtliche Bewertung relevant sein.\u003c/p\u003e\n\u003cp\u003eTechnische Kontrolle beantwortet andere Fragen: Wer bestimmt die \u003ca href=\"/kubernetes/\"\u003eRouting-Entscheidung\u003c/a\u003e\n? Wer verarbeitet eingehende Verbindungen? Wo endet TLS? Welche Systeme können Backends direkt erreichen? Diese Fragen betreffen Architektur und Betrieb, nicht automatisch die Rechtslage.\u003c/p\u003e\n\u003cp\u003eFür die Bewertung von Jurisdiktion in der Cloud-Infrastruktur sollten beide Ebenen dokumentiert werden. Eine rechtliche Prüfung betrachtet Zuständigkeiten und Verpflichtungen. Eine technische Architekturprüfung analysiert Datenpfade, Zugriffsmöglichkeiten und administrative Kontrolle. Erst zusammen entsteht ein belastbares Bild der tatsächlichen Abhängigkeiten.\u003c/p\u003e\n\u003ch2 id=\"2-routing-und-traffic-verarbeitung-als-kontrollpunkte\"\u003e2. Routing und Traffic-Verarbeitung als Kontrollpunkte\u003c/h2\u003e\n\u003cp\u003eAn der Edge entscheidet sich, wie öffentlicher Traffic eine Anwendung erreicht. Anycast-basierte \u003ca href=\"/kubernetes/\"\u003eRouting-\u003c/a\u003e\n und Loadbalancing-Mechanismen können eingehende Verbindungen über eine verteilte Multi-PoP-Architektur annehmen und zu geeigneten Backends weiterleiten. Dabei ist nicht nur der physische Standort eines Systems relevant, sondern auch die Kontrolle über Routing, Failover und Traffic-Verarbeitung.\u003c/p\u003e\n\u003cp\u003eDie ayedo Edge Cloud verfügt dafür über ein eigenes Autonomous System und eigene Netzwerk-Infrastruktur. Anycast DNS sowie Multi-Provider-DNS können zusätzlich die Auflösung und Erreichbarkeit beeinflussen. Diese Eigenschaften schaffen technische Kontrollpunkte für den öffentlichen Eingang, sind aber keine Aussage darüber, welchem Recht ein Unternehmen oder eine Verarbeitung unterliegt.\u003c/p\u003e\n\u003cp\u003eBetrieblich bedeutet das: Routingregeln, Health Checks und Failover müssen nachvollziehbar dokumentiert werden. Security- und Compliance-Teams benötigen eine gemeinsame Sicht auf Netzwerkpfade und Zuständigkeiten. Ohne diese Dokumentation bleibt „Kontrolle“ eine unpräzise Behauptung.\u003c/p\u003e\n\u003ch2 id=\"3-tls-terminierung-verändert-die-vertrauensgrenze\"\u003e3. TLS-Terminierung verändert die Vertrauensgrenze\u003c/h2\u003e\n\u003cp\u003eBei der TLS-Terminierung an der Edge endet die verschlüsselte Verbindung des Clients nicht erst am Backend, sondern an der Edge-Plattform. Dort kann der Traffic für nachgelagerte Sicherheits- und Routingfunktionen verarbeitet und anschließend erneut zum Backend übertragen werden. Die Edge wird damit zu einem klar definierten Vertrauens- und Kontrollpunkt.\u003c/p\u003e\n\u003cp\u003eDiese Architektur hat direkte Security- und Betriebsfolgen. Zertifikate, Schlüsselmaterial, Zugriffskonzepte und Protokollierung müssen für die Edge berücksichtigt werden. Gleichzeitig können Backends von öffentlichen TLS- und HTTP-Verbindungen entlastet werden. Die Entscheidung für TLS-Terminierung ist deshalb keine reine Performancefrage, sondern eine Festlegung darüber, wo Verschlüsselung endet und welche Plattform Traffic verarbeiten darf.\u003c/p\u003e\n\u003cp\u003eDie ayedo Edge Cloud unterstützt TLS Termination an der Edge für HTTP- und HTTPS-Services. Daraus folgt jedoch keine rechtliche Bewertung der dort verarbeiteten Inhalte. Unternehmen müssen zusätzlich klären, welche Daten verarbeitet werden dürfen, welche Verträge gelten und welche Betriebsprozesse den Zugriff auf Konfigurationen und Schlüsselmaterial regeln.\u003c/p\u003e\n\u003ch2 id=\"4-backend-cloaking-reduziert-direkte-angriffs--und-abhängigkeitspfade\"\u003e4. Backend Cloaking reduziert direkte Angriffs- und Abhängigkeitspfade\u003c/h2\u003e\n\u003cp\u003eBackend Cloaking trennt die öffentlich erreichbare Edge von den eigentlichen Anwendungs-Backends. Die Backends müssen dadurch nicht als direkte öffentliche Ziele des Internets auftreten. Zugriffe können auf den vorgesehenen Pfad über die Edge begrenzt werden; die konkrete Durchsetzung erfolgt über Netzwerk- und Sicherheitsregeln der jeweiligen Umgebung.\u003c/p\u003e\n\u003cp\u003eTechnisch reduziert diese Trennung die Angriffsfläche und erleichtert die Kontrolle des eingehenden Traffics. Die Edge übernimmt Routing, Schutz und Lastverteilung, während die Compute-Infrastruktur die Anwendungen ausführt. Das gilt unabhängig davon, ob ein \u003ca href=\"/kubernetes/\"\u003eKubernetes-Cluster\u003c/a\u003e\n bei ayedo, im eigenen Rechenzentrum oder bei einem anderen Provider betrieben wird.\u003c/p\u003e\n\u003cp\u003eFür die Jurisdiktionsbewertung ist Backend Cloaking dennoch nur ein Baustein. Es verhindert nicht automatisch jede Verarbeitung außerhalb gewünschter Zuständigkeiten und ersetzt keine Prüfung von Logs, Administrationszugängen oder Drittanbieterabhängigkeiten. Sein Wert liegt in einem kontrollierbareren Datenpfad und einer klareren Trennung der Verantwortungsbereiche.\u003c/p\u003e\n\u003ch2 id=\"praxis--und-betriebsszenario\"\u003ePraxis- und Betriebsszenario\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt einen Kubernetes-Cluster bei einem externen Provider und möchte die öffentliche API nicht direkt über dessen Loadbalancer exponieren. Der DNS-Eintrag zeigt auf die ayedo Edge Cloud. Dort werden Verbindungen per Anycast angenommen, TLS terminiert und HTTP-Traffic geprüft beziehungsweise weitergeleitet. Das Backend akzeptiert ausschließlich Verbindungen aus dem definierten Edge-Pfad.\u003c/p\u003e\n\u003cp\u003eIm Architekturvergleich liegt die technische Kontrolle über den öffentlichen Eingang damit nicht vollständig beim Compute-Provider. Routing, TLS-Terminierung und Backend-Abschirmung werden an der Edge zentral betrieben. Die rechtliche Bewertung bleibt jedoch separat: Sie muss Provider, Vertragsbeziehungen, Datenarten, Zugriffsrechte und Betriebsprozesse einbeziehen.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"ist-ein-eigener-netzwerkstandort-automatisch-rechtlich-souverän\"\u003eIst ein eigener Netzwerkstandort automatisch rechtlich souverän?\u003c/h3\u003e\n\u003cp\u003eNein. Ein Standort kann technische Datenpfade beeinflussen, beantwortet aber nicht allein Fragen zu Unternehmen, Verträgen, Zugriffen oder anwendbarem Recht.\u003c/p\u003e\n\u003ch3 id=\"bedeutet-tls-terminierung-an-der-edge-dass-ayedo-alle-inhalte-rechtlich-kontrolliert\"\u003eBedeutet TLS-Terminierung an der Edge, dass ayedo alle Inhalte rechtlich kontrolliert?\u003c/h3\u003e\n\u003cp\u003eNein. TLS-Terminierung beschreibt einen technischen Verarbeitungspunkt. Rechtliche Verantwortlichkeiten müssen anhand der konkreten Nutzung und Vertragsstruktur bewertet werden.\u003c/p\u003e\n\u003ch3 id=\"braucht-ein-externes-kubernetes-cluster-eine-ayedo-managed-kubernetes-umgebung\"\u003eBraucht ein externes Kubernetes-Cluster eine ayedo Managed Kubernetes-Umgebung?\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\u003eJurisdiktion der Cloud-Infrastruktur und technische Kontrolle sollten weder gleichgesetzt noch unabhängig voneinander betrachtet werden. Routing, TLS-Terminierung und Backend Cloaking machen Datenpfade und Vertrauensgrenzen steuerbarer, lösen aber keine rechtlichen Fragen automatisch. Die ayedo Edge Cloud ordnet diese Funktionen in einer eigenen, aktiv-aktiven Edge-Plattform mit eigener Netzwerk-Infrastruktur ein. Für belastbare Entscheidungen braucht es zusätzlich dokumentierte Betriebsprozesse und eine separate rechtliche Bewertung.\u003c/p\u003e\n", "summary": "\nTL;DR Jurisdiktion in der Cloud beschreibt rechtliche Zuständigkeiten, nicht automatisch die technische Kontrolle über Datenflüsse und Infrastruktur. Für die Bewertung einer Edge-Architektur müssen deshalb Routing, Traffic-Verarbeitung, TLS-Terminierung, Backend-Abschirmung und Betriebsprozesse getrennt betrachtet werden. Die ayedo Edge Cloud schafft technische Kontrollpunkte, ersetzt aber keine rechtliche Prüfung.\nEinleitung Die Annahme, ein bestimmter Infrastrukturstandort löse automatisch alle Fragen zur Jurisdiktion der Cloud-Infrastruktur, führt in der Praxis zu falschen Entscheidungen. Rechtliche Zuständigkeiten ergeben sich aus mehreren Faktoren: beteiligten Unternehmen, Vertragsbeziehungen, Datenverarbeitung und anwendbarem Recht. Technische Kontrolle ist davon zu unterscheiden. Sie beschreibt, wer Routing, Traffic-Verarbeitung, Verschlüsselung und Backend-Zugriffe tatsächlich steuert. Für Unternehmen ist diese Trennung entscheidend, weil eine rechtlich zulässige Architektur nicht zwangsläufig ausreichend kontrollierbar ist – und technische Kontrolle umgekehrt keine Rechtsgarantie darstellt.\n", "image": "https://ayedo.de/jurisdiktion-und-technische-kontrolle-an-der-edge.png", "date_published": "2026-09-04T22:25:58Z", "date_modified": "2026-09-04T22:25:58Z", "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}], "tags": ["cloud-native","operations","cloud","kubernetes","digital-sovereignty"], "language": "de" },{ "id": "https://ayedo.de/posts/offene-standards-fur-eine-portable-edge-architektur/", "url": "https://ayedo.de/posts/offene-standards-fur-eine-portable-edge-architektur/", "title": "Offene Standards für eine portable Edge-Architektur", "content_html": "\u003cp\u003e\u003cimg src=\"/posts/offene-standards-fur-eine-portable-edge-architektur/offene-standards-fur-eine-portable-edge-architektur.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eEine portable Edge-Architektur basiert nicht auf einem einzelnen Anbieter, sondern auf standardisierten Netzwerk-, Protokoll- und Integrationsschnittstellen. DNS, TLS, HTTP, TCP/IP und \u003ca href=\"/kubernetes/\"\u003eProxy Protocol\u003c/a\u003e\n reduzieren proprietäre Bindungen. Sie ermöglichen jedoch keine vollständige Austauschbarkeit: Routing, Schutzfunktionen, Betriebsmodelle und Migration bleiben architekturspezifische Aufgaben.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003ePortabilität scheitert selten am Transport eines \u003ca href=\"/kubernetes/\"\u003eContainers\u003c/a\u003e\n. Schwieriger ist der Wechsel des öffentlichen Eingangspunkts: DNS, TLS-Terminierung, Quell-IP-Weitergabe, Health Checks, Failover und Backend-Erreichbarkeit sind eng miteinander verbunden. Werden diese Funktionen über proprietäre Schnittstellen modelliert, wird ein Plattformwechsel schnell zu einem Netzwerkumbau. Offene Standards schaffen hier eine belastbare Abstraktion. Sie machen eine Edge-Architektur nicht automatisch vollständig austauschbar, verringern aber die Zahl der Abhängigkeiten, die bei wechselnden Backends, [Kubernetes]-Clustern oder Providern neu entworfen werden müssen.\u003c/p\u003e\n\u003ch2 id=\"1-standards-definieren-die-übergaben-zwischen-edge-und-backend\"\u003e1. Standards definieren die Übergaben zwischen Edge und Backend\u003c/h2\u003e\n\u003cp\u003eEine portable Edge-Architektur beginnt an den Schnittstellen. DNS beschreibt, wie Clients einen Dienst auflösen. TCP/IP und TLS definieren den Transport beziehungsweise die verschlüsselte Verbindung. HTTP standardisiert die Kommunikation auf Anwendungsebene. Für die Übergabe von Informationen über die ursprüngliche Client-Verbindung kann \u003ca href=\"/kubernetes/\"\u003eProxy Protocol\u003c/a\u003e\n eingesetzt werden. Diese Standards sind keine vollständige Plattformbeschreibung, aber sie strukturieren die Übergaben zwischen Komponenten.\u003c/p\u003e\n\u003cp\u003eDer entscheidende Unterschied zu proprietären Bindungen liegt in der Austauschbarkeit einzelner Implementierungen. Ein Backend muss nicht wissen, welcher Edge-Provider den Traffic verteilt, solange es die erwarteten Protokolle und Header verarbeitet. Ebenso kann ein [Kubernetes]-Ingress, ein klassischer Loadbalancer oder ein eigener Dienst hinter der Edge betrieben werden, wenn die Netzwerk- und TLS-Anforderungen kompatibel sind.\u003c/p\u003e\n\u003cp\u003eDas reduziert den Migrationsaufwand, beseitigt ihn aber nicht. Zertifikatsverwaltung, Routingregeln, Health-Check-Logik und Sicherheitsrichtlinien müssen zwischen Plattformen weiterhin abgeglichen werden. Standards schaffen eine gemeinsame Sprache, nicht automatisch identische Betriebsmodelle.\u003c/p\u003e\n\u003ch2 id=\"2-proxy-protocol-und-tls-zeigen-die-grenzen-von-portabilität\"\u003e2. Proxy Protocol und TLS zeigen die Grenzen von Portabilität\u003c/h2\u003e\n\u003cp\u003e\u003ca href=\"/kubernetes/\"\u003eProxy Protocol\u003c/a\u003e\n ist ein gutes Beispiel für eine standardbasierte, aber nicht vollständig neutrale Schnittstelle. Ein Proxy kann damit Informationen wie Quell- und Zieladresse an das Backend weitergeben, obwohl die TCP-Verbindung vom Proxy aufgebaut wurde. Das ist für Logging, Rate Limiting oder IP-basierte Zugriffskontrollen relevant. Ohne diese Information sieht das Backend häufig nur die Adresse der Edge.\u003c/p\u003e\n\u003cp\u003eDie Nutzung setzt jedoch voraus, dass der Backend-Dienst Proxy Protocol korrekt erwartet. Wird die Verbindung an einen Dienst weitergeleitet, der das Protokoll nicht unterstützt, kann der Verbindungsaufbau fehlschlagen. Portabilität verlangt deshalb nicht nur ein standardisiertes Protokoll, sondern auch eine dokumentierte Betriebsentscheidung: Wo wird es aktiviert, welche Listener erwarten es und wie wird ein Wechsel getestet?\u003c/p\u003e\n\u003cp\u003eÄhnlich verhält es sich mit TLS Termination. Sie entkoppelt Zertifikats- und Verschlüsselungslogik vom Backend und erleichtert die zentrale Steuerung. Gleichzeitig müssen Trust Boundaries, Weiterleitung verschlüsselter Verbindungen und Anforderungen an Ende-zu-Ende-Verschlüsselung berücksichtigt werden. Standardisierung reduziert Bindungen, ersetzt aber keine Sicherheitsarchitektur.\u003c/p\u003e\n\u003ch2 id=\"3-edge-funktionen-müssen-vom-compute-entkoppelt-bleiben\"\u003e3. Edge-Funktionen müssen vom Compute entkoppelt bleiben\u003c/h2\u003e\n\u003cp\u003ePortabilität wird erschwert, wenn Edge und Compute als eine untrennbare Plattform behandelt werden. Die Edge ist für den öffentlichen Traffic-Eingang, Routing, Schutz, Termination und Lastverteilung zuständig. Compute-Plattformen führen dagegen Anwendungen und Workloads aus. Diese Verantwortungsbereiche können über standardisierte Schnittstellen verbunden werden, ohne dieselbe Infrastruktur zu teilen.\u003c/p\u003e\n\u003cp\u003eFür wechselnde Backends ist Backend Cloaking relevant: Die öffentlich sichtbare Adresse muss nicht der tatsächlichen Backend-Adresse entsprechen. Dadurch können Workloads verschoben, Cluster ausgetauscht oder Backends bei unterschiedlichen Providern betrieben werden, ohne die öffentliche Dienstadresse grundsätzlich neu zu modellieren. Health Checks und Failover ergänzen diese Entkopplung um eine betriebliche Ebene.\u003c/p\u003e\n\u003cp\u003eDie ayedo Edge Cloud unterstützt diese Architektur mit Anycast-basiertem Layer-4- und Layer-7-Loadbalancing, TLS Termination, Backend Cloaking, \u003ca href=\"/kubernetes/\"\u003eProxy Protocol\u003c/a\u003e\n sowie Backend Health Checks und Failover. Die [Kubernetes]-native Integration ist dabei nicht auf ayedo Managed Kubernetes beschränkt, sondern kann auch mit eigenen oder bei anderen Providern betriebenen Clustern eingesetzt werden.\u003c/p\u003e\n\u003ch2 id=\"4-offene-standards-reduzieren-lock-in-aber-nicht-jede-komplexität\"\u003e4. Offene Standards reduzieren Lock-in, aber nicht jede Komplexität\u003c/h2\u003e\n\u003cp\u003eEin proprietäres Modell bündelt häufig Routing, Security Policies, DNS, Zertifikate und Backend-Anbindung in eigenen Ressourcen und Bedienkonzepten. Das kann innerhalb einer Plattform effizient sein, erhöht jedoch die Kosten eines Wechsels: Konfigurationen müssen übersetzt, Betriebsprozesse neu aufgebaut und Abhängigkeiten im Teamwissen identifiziert werden.\u003c/p\u003e\n\u003cp\u003eStandardbasierte Funktionen verschieben die Portabilität auf besser kontrollierbare Ebenen. DNS kann über mehrere Provider organisiert werden. HTTP- und TLS-Konfigurationen lassen sich zwischen Implementierungen vergleichen. \u003ca href=\"/kubernetes/\"\u003eProxy Protocol\u003c/a\u003e\n definiert eine klare Übergabe zum Backend. [Kubernetes]-Ressourcen und gängige Netzwerkmodelle können als Integrationspunkt dienen. Trotzdem bleiben Anycast-Routing, DDoS-Scrubbing, WAF-Regeln, Failover-Verhalten und Observability meist implementierungsspezifisch.\u003c/p\u003e\n\u003cp\u003eDie ayedo Edge Cloud verbindet solche standardnahen Schnittstellen mit eigener Netzwerk-Infrastruktur, eigenem Autonomous System und einer Aktiv-Aktiv-Architektur über verteilte PoPs. Für die Portabilität bedeutet das: Backends und Plattformen können unabhängig gewählt oder verändert werden, während der öffentliche Edge-Betrieb als eigene Verantwortungsdomäne bestehen bleibt.\u003c/p\u003e\n\u003ch2 id=\"praxis--und-architekturszenario\"\u003ePraxis- und Architekturszenario\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt eine API zunächst in einem [Kubernetes]-Cluster bei Provider A und plant später einen zweiten Cluster bei Provider B. Eine proprietär an den ersten Provider gebundene Edge-Konfiguration würde DNS, Zertifikate, Routing und Backend-Anbindung gemeinsam migrieren. Bei einer standardbasierten Architektur bleibt die öffentliche Dienstadresse an der Edge bestehen. Das neue Backend wird über kompatible Health Checks eingebunden; TLS wird weiterhin an der Edge terminiert, und \u003ca href=\"/kubernetes/\"\u003eProxy Protocol\u003c/a\u003e\n liefert bei Bedarf die Client-Information an den Listener.\u003c/p\u003e\n\u003cp\u003eDer Wechsel ist damit kein vollständiger Plattformtausch. WAF-Regeln, Routinglogik, Failover-Verhalten und Betriebsprozesse müssen geprüft werden. Der Unterschied liegt darin, dass die Anwendung nicht zugleich an einen bestimmten [Kubernetes]-Provider und an dessen Edge-Modell gebunden ist.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"macht-der-einsatz-offener-standards-eine-edge-plattform-vollständig-austauschbar\"\u003eMacht der Einsatz offener Standards eine Edge-Plattform vollständig austauschbar?\u003c/h3\u003e\n\u003cp\u003eNein. Standards erleichtern die Integration und Migration. Routingmodelle, Schutzfunktionen, Betriebsprozesse, Konfigurationen und Leistungsmerkmale bleiben je nach Plattform unterschiedlich.\u003c/p\u003e\n\u003ch3 id=\"wann-ist-proxy-protocol-für-ein-backend-sinnvoll\"\u003eWann ist \u003ca href=\"/kubernetes/\"\u003eProxy Protocol\u003c/a\u003e\n für ein Backend sinnvoll?\u003c/h3\u003e\n\u003cp\u003eWenn das Backend die ursprüngliche Client-Adresse benötigt, obwohl die Edge die Verbindung terminiert oder weiterleitet. Der Listener muss Proxy Protocol ausdrücklich unterstützen und korrekt konfigurieren.\u003c/p\u003e\n\u003ch3 id=\"ist-eine-portable-edge-architektur-nur-für-kubernetes-relevant\"\u003eIst eine portable Edge-Architektur nur für [Kubernetes] relevant?\u003c/h3\u003e\n\u003cp\u003eNein. Die Prinzipien gelten ebenso für virtuelle Maschinen, Bare-Metal-Systeme, Managed Services und gemischte Umgebungen. [Kubernetes] ist lediglich ein häufiger Integrationspunkt.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eEine portable Edge-Architektur entsteht durch klar definierte Verantwortungsgrenzen und standardisierte Übergaben, nicht durch die Annahme vollständiger Austauschbarkeit. DNS, TLS, HTTP, TCP/IP und \u003ca href=\"/kubernetes/\"\u003eProxy Protocol\u003c/a\u003e\n reduzieren proprietäre Abhängigkeiten an den Schnittstellen. Die ayedo Edge Cloud ordnet diese Schnittstellen in eine eigenständige Edge-Domäne ein, die unterschiedliche Backends und [Kubernetes]-Plattformen anbinden kann. So wird Portabilität zu einer planbaren Architektur- und Betriebsentscheidung statt zu einem nachträglichen Migrationsprojekt.\u003c/p\u003e\n", "summary": "\nTL;DR Eine portable Edge-Architektur basiert nicht auf einem einzelnen Anbieter, sondern auf standardisierten Netzwerk-, Protokoll- und Integrationsschnittstellen. DNS, TLS, HTTP, TCP/IP und Proxy Protocol reduzieren proprietäre Bindungen. Sie ermöglichen jedoch keine vollständige Austauschbarkeit: Routing, Schutzfunktionen, Betriebsmodelle und Migration bleiben architekturspezifische Aufgaben.\nEinleitung Portabilität scheitert selten am Transport eines Containers . Schwieriger ist der Wechsel des öffentlichen Eingangspunkts: DNS, TLS-Terminierung, Quell-IP-Weitergabe, Health Checks, Failover und Backend-Erreichbarkeit sind eng miteinander verbunden. Werden diese Funktionen über proprietäre Schnittstellen modelliert, wird ein Plattformwechsel schnell zu einem Netzwerkumbau. Offene Standards schaffen hier eine belastbare Abstraktion. Sie machen eine Edge-Architektur nicht automatisch vollständig austauschbar, verringern aber die Zahl der Abhängigkeiten, die bei wechselnden Backends, [Kubernetes]-Clustern oder Providern neu entworfen werden müssen.\n", "image": "https://ayedo.de/offene-standards-fur-eine-portable-edge-architektur.png", "date_published": "2026-09-04T22:25:58Z", "date_modified": "2026-09-04T22:25:58Z", "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}], "tags": ["kubernetes","cloud-native","security","hosting","digital-sovereignty"], "language": "de" },{ "id": "https://ayedo.de/posts/provider-abhangigkeiten-im-edge-betrieb-systematisch-prufen/", "url": "https://ayedo.de/posts/provider-abhangigkeiten-im-edge-betrieb-systematisch-prufen/", "title": "Provider-Abhängigkeiten im Edge-Betrieb systematisch prüfen", "content_html": "\u003cp\u003e\u003cimg src=\"/posts/provider-abhangigkeiten-im-edge-betrieb-systematisch-prufen/provider-abhangigkeiten-im-edge-betrieb-systematisch-prufen.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eProviderabhängigkeiten im Edge-Betrieb entstehen nicht allein durch die Anzahl eingesetzter Anbieter. Entscheidend sind technische Kopplungen entlang von DNS, IP-Adressierung, Routing, Security, Traffic-Verteilung und Backend-Anbindung. Eine belastbare Abhängigkeitsanalyse bewertet deshalb Wechselkosten, Kontrollpunkte und Failover-Verhalten. Die ayedo Edge Cloud bündelt diese Ebenen in einer providerunabhängig nutzbaren Edge-Plattform.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eMehrere Provider einzusetzen, reduziert Abhängigkeiten nicht automatisch. Ein Unternehmen kann DNS, DDoS-Schutz und Loadbalancing bei verschiedenen Anbietern betreiben und trotzdem an einen Provider gebunden sein, wenn IP-Adressen, Routing oder Backend-Anbindung nicht unabhängig migrierbar sind. Der typische Fehler besteht darin, Provider auf Vertrags- oder Produktebene zu zählen, statt technische Kopplungen zu analysieren. Für den Edge-Betrieb ist daher eine andere Frage entscheidend: Welche Komponente kontrolliert welchen Teil des öffentlichen Traffics, und wie aufwendig ist ein Wechsel im Störungs- oder Migrationsfall? Diese Perspektive macht Abhängigkeiten messbar und zeigt, wo eine zentrale Edge-Plattform organisatorisch und technisch sinnvoll ist.\u003c/p\u003e\n\u003ch2 id=\"1-abhängigkeiten-entlang-des-datenpfads-erfassen\"\u003e1. Abhängigkeiten entlang des Datenpfads erfassen\u003c/h2\u003e\n\u003cp\u003eEine belastbare Prüfung beginnt beim tatsächlichen Datenpfad: DNS-Auflösung, IP-Ankündigung und Routing, Traffic-Verarbeitung, Security-Funktionen und Weiterleitung zum Backend. Jede Ebene kann einen eigenen Provider, eigene Konfigurationen und eigene Ausfallmechanismen besitzen. Entscheidend ist nicht nur, ob diese Komponenten getrennt betrieben werden, sondern wie eng sie gekoppelt sind.\u003c/p\u003e\n\u003cp\u003eEin DNS-Wechsel kann beispielsweise technisch schnell umgesetzt werden, während die dazugehörigen IP-Adressen, Zertifikate, WAF-Regeln oder Health Checks an einen bestimmten Dienst gebunden bleiben. Ebenso ist ein zweiter DNS-Provider wenig hilfreich, wenn beide Anbieter auf dieselbe IP-Adressierung oder denselben Routingpfad angewiesen sind. Die Abhängigkeitsanalyse sollte deshalb pro Ebene dokumentieren: Wer kontrolliert die Konfiguration? Welche Ressourcen müssen migriert werden? Welche Änderungen sind während des laufenden Betriebs möglich? Und wie wird ein Ausfall erkannt und behandelt?\u003c/p\u003e\n\u003ch2 id=\"2-ip-adressierung-und-routing-getrennt-bewerten\"\u003e2. IP-Adressierung und Routing getrennt bewerten\u003c/h2\u003e\n\u003cp\u003eIP-Adressierung und Routing werden in der Praxis häufig als eine gemeinsame Abhängigkeit betrachtet. Sie sind jedoch unterschiedliche technische Kontrollpunkte. Die IP-Adresse bestimmt, unter welcher Identität ein Service erreichbar ist. Routing entscheidet, über welche Netze und Übergänge dieser Service angekündigt und erreicht wird. Ein Providerwechsel kann an beiden Stellen unterschiedliche Auswirkungen haben.\u003c/p\u003e\n\u003cp\u003eBring Your Own IP ermöglicht, die öffentliche Adressierung stärker von einer konkreten Plattform zu entkoppeln. Das reduziert beispielsweise die Wechselkosten bei der Migration von Services und erleichtert konsistente Freigaben oder Allowlisting-Regeln. Damit ist die Abhängigkeit aber nicht vollständig beseitigt: Entscheidend bleibt, wer die Adressen ankündigt, wie Failover organisiert ist und welche Netzwerkinfrastruktur den Traffic verarbeitet. Die ayedo Edge Cloud verbindet Anycast-basiertes Routing mit eigener Netzwerk-Infrastruktur und eigenem Autonomous System. Dadurch wird Routing als eigenständige Edge-Funktion betrachtet, statt nur als Nebenprodukt eines einzelnen Loadbalancers.\u003c/p\u003e\n\u003ch2 id=\"3-security--und-traffic-funktionen-als-kopplungspunkte-prüfen\"\u003e3. Security- und Traffic-Funktionen als Kopplungspunkte prüfen\u003c/h2\u003e\n\u003cp\u003eSecurity-Funktionen sind nicht beliebig austauschbar, weil sie direkt in den Traffic-Pfad eingreifen. WAF-Regeln, DDoS Protection, TLS Termination und Backend Cloaking beeinflussen, welche Anfragen akzeptiert werden, wo Verschlüsselung endet und welche Informationen das Backend über den öffentlichen Eingang erhält. Ein Wechsel muss deshalb nicht nur DNS-Einträge ersetzen, sondern auch Sicherheitslogik, Zertifikate, Header-Verhalten und Betriebsprozesse berücksichtigen.\u003c/p\u003e\n\u003cp\u003eFür die Analyse ist zu prüfen, ob Schutzmechanismen unabhängig vom Routing betrieben werden können oder ob sie an eine bestimmte Plattform gekoppelt sind. Ein vorgeschalteter DDoS-Dienst, ein separater DNS-Anbieter und ein nachgelagerter Loadbalancer können zwar funktional getrennt sein, aber zusätzliche Übergänge und Fehlerbilder erzeugen. Eine zentral abgebildete Edge-Schicht reduziert diese Koordinationspunkte. Die ayedo Edge Cloud bündelt WAF, DDoS Protection, TLS Termination und Backend Cloaking mit der Traffic-Verarbeitung. Das schafft keinen automatischen Verzicht auf alle Provider, macht die Verantwortungsgrenzen jedoch klarer und operativ kontrollierbarer.\u003c/p\u003e\n\u003ch2 id=\"4-traffic-verteilung-und-backend-anbindung-bewerten\"\u003e4. Traffic-Verteilung und Backend-Anbindung bewerten\u003c/h2\u003e\n\u003cp\u003eDie letzte relevante Ebene liegt hinter der Edge: die Verbindung zu Anwendungen, APIs und Clustern. Providerabhängigkeiten entstehen hier, wenn Backend-Adressen, Protokolle, Health Checks oder Failover-Logik an einen bestimmten Edge- oder Cloud-Anbieter gebunden sind. Besonders bei \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n -Umgebungen sollte deshalb getrennt werden, wo Workloads laufen und wer ihren öffentlichen Eingang kontrolliert.\u003c/p\u003e\n\u003cp\u003eBackend Health Checks und Failover sind nur dann belastbar, wenn sie den Zustand der tatsächlichen Anwendung bewerten und bei Fehlern eine definierte Reaktion auslösen. Proxy Protocol kann dabei relevante Verbindungsinformationen an das Backend weitergeben, ohne die öffentliche Erreichbarkeit direkt auf die Workload-Infrastruktur zu verlagern. Backend Cloaking verhindert zusätzlich, dass Anwendungen unmittelbar exponiert werden. Die ayedo Edge Cloud kann mit ayedo Managed Kubernetes ebenso wie mit eigenen oder bei anderen Providern betriebenen Kubernetes-Clustern genutzt werden. Damit bleibt die Edge-Funktion vom Compute-Provider getrennt, während Traffic-Verteilung und Backend-Anbindung zentral steuerbar bleiben.\u003c/p\u003e\n\u003ch2 id=\"praxis--und-betriebsszenario\"\u003ePraxis- und Betriebsszenario\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt eine API in einem \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n -Cluster bei Provider A. DNS liegt bei Provider B, DDoS-Schutz bei Provider C und TLS-Termination bei Provider D. Auf dem Papier bestehen vier Anbieter und damit eine vermeintliche Redundanz. In der Praxis müssen bei einem Wechsel jedoch DNS, Zertifikate, WAF-Regeln, IP-Allowlisting, Health Checks und Backend-Zugänge koordiniert werden. Zusätzlich darf der direkte Zugriff auf den Cluster nicht versehentlich geöffnet werden.\u003c/p\u003e\n\u003cp\u003eEine alternative Architektur verlagert öffentlichen DNS, Anycast-Routing, DDoS Protection, WAF, TLS Termination und Traffic-Verteilung in eine gemeinsame Edge-Schicht. Das Backend kann weiterhin bei Provider A oder an einem anderen Standort laufen. Der Vergleich zeigt: Die relevante Größe ist nicht die Provideranzahl, sondern die Zahl der Übergaben, gemeinsam verwalteten Zustände und migrationskritischen Ressourcen.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"reduziert-multi-provider-dns-automatisch-die-abhängigkeit\"\u003eReduziert Multi-Provider-DNS automatisch die Abhängigkeit?\u003c/h3\u003e\n\u003cp\u003eNein. Anycast DNS oder Multi-Provider-DNS erhöhen die Verfügbarkeit der Namensauflösung, beseitigen aber keine Abhängigkeiten bei IP-Adressierung, Routing, Security oder Backend-Anbindung.\u003c/p\u003e\n\u003ch3 id=\"welche-abhängigkeit-sollte-zuerst-geprüft-werden\"\u003eWelche Abhängigkeit sollte zuerst geprüft werden?\u003c/h3\u003e\n\u003cp\u003eBeginnen Sie mit der öffentlichen IP-Adressierung und dem Routing. Wenn diese Ebenen nicht unabhängig migrierbar sind, bleiben nachgelagerte Providerwechsel oft theoretisch oder verursachen erhebliche Betriebsrisiken.\u003c/p\u003e\n\u003ch3 id=\"ist-kubernetes-ein-eigener-edge-provider\"\u003eIst Kubernetes ein eigener Edge-Provider?\u003c/h3\u003e\n\u003cp\u003eNein. \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n stellt Compute- und Plattformressourcen bereit. Die Edge Cloud übernimmt den öffentlichen Traffic-Eingang, Schutz, Routing und die Weiterleitung zu diesen Workloads – unabhängig davon, wo der Cluster betrieben wird.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eProviderabhängigkeiten im Edge-Betrieb lassen sich nur entlang der technischen Kontrollpunkte bewerten. DNS, IP-Adressierung, Routing, Security, Traffic-Verteilung und Backend-Anbindung müssen als zusammenhängender Datenpfad analysiert werden. Eine Edge-Plattform wie die ayedo Edge Cloud bündelt diese Funktionen, ohne die Compute-Infrastruktur an ayedo Managed Kubernetes zu binden. Dadurch werden Wechselkosten, Verantwortlichkeiten und Failover-Szenarien transparenter – und Abhängigkeiten lassen sich gezielt reduzieren, statt sie nur zu verteilen.\u003c/p\u003e\n", "summary": "\nTL;DR Providerabhängigkeiten im Edge-Betrieb entstehen nicht allein durch die Anzahl eingesetzter Anbieter. Entscheidend sind technische Kopplungen entlang von DNS, IP-Adressierung, Routing, Security, Traffic-Verteilung und Backend-Anbindung. Eine belastbare Abhängigkeitsanalyse bewertet deshalb Wechselkosten, Kontrollpunkte und Failover-Verhalten. Die ayedo Edge Cloud bündelt diese Ebenen in einer providerunabhängig nutzbaren Edge-Plattform.\nEinleitung Mehrere Provider einzusetzen, reduziert Abhängigkeiten nicht automatisch. Ein Unternehmen kann DNS, DDoS-Schutz und Loadbalancing bei verschiedenen Anbietern betreiben und trotzdem an einen Provider gebunden sein, wenn IP-Adressen, Routing oder Backend-Anbindung nicht unabhängig migrierbar sind. Der typische Fehler besteht darin, Provider auf Vertrags- oder Produktebene zu zählen, statt technische Kopplungen zu analysieren. Für den Edge-Betrieb ist daher eine andere Frage entscheidend: Welche Komponente kontrolliert welchen Teil des öffentlichen Traffics, und wie aufwendig ist ein Wechsel im Störungs- oder Migrationsfall? Diese Perspektive macht Abhängigkeiten messbar und zeigt, wo eine zentrale Edge-Plattform organisatorisch und technisch sinnvoll ist.\n", "image": "https://ayedo.de/provider-abhangigkeiten-im-edge-betrieb-systematisch-prufen.png", "date_published": "2026-09-04T22:25:58Z", "date_modified": "2026-09-04T22:25:58Z", "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}], "tags": ["security","ai","cloud-native","hosting","kubernetes"], "language": "de" },{ "id": "https://ayedo.de/posts/digitale-souveranitat-durch-eigenes-autonomous-system/", "url": "https://ayedo.de/posts/digitale-souveranitat-durch-eigenes-autonomous-system/", "title": "Digitale Souveränität durch eigenes Autonomous System", "content_html": "\u003cp\u003e\u003cimg src=\"/posts/digitale-souveranitat-durch-eigenes-autonomous-system/digitale-souveranitat-durch-eigenes-autonomous-system.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eEin eigenes \u003ca href=\"/kubernetes/\"\u003eAutonomous System\u003c/a\u003e\n schafft keine vollständige Unabhängigkeit, erweitert aber die Kontrolle über den öffentlichen Traffic-Eintritt. Über \u003ca href=\"/kubernetes/\"\u003eBGP\u003c/a\u003e\n lassen sich Erreichbarkeit und Routing eigenständig gestalten. In Verbindung mit eigener Netzwerkinfrastruktur, Anycast und Aktiv-Aktiv-Betrieb wird digitale Souveränität zu einer überprüfbaren Architekturentscheidung.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eEin zentraler Netzwerkbetreiber kann technisch zum Single Point of Control werden, selbst wenn Anwendungen redundant über mehrere Rechenzentren verteilt sind. Entscheidend ist nicht nur, wo Workloads laufen, sondern wer die öffentliche Erreichbarkeit über das Internet steuert. Ein eigenes \u003ca href=\"/kubernetes/\"\u003eAutonomous System\u003c/a\u003e\n verschiebt diese Kontrolle: Das Unternehmen oder der Plattformbetreiber kann IP-Präfixe unter eigener Routing-Identität ankündigen und die Abhängigkeit von einzelnen Providern reduzieren. Das bedeutet jedoch nicht, dass BGP automatisch unabhängige oder optimale Pfade garantiert. Souveränität entsteht erst durch das Zusammenspiel aus Routing-Kontrolle, eigener Netzwerkinfrastruktur, redundanten Upstreams und einem belastbaren Betriebsmodell.\u003c/p\u003e\n\u003ch2 id=\"1-was-ein-eigenes-autonomous-system-technisch-kontrolliert\"\u003e1. Was ein eigenes Autonomous System technisch kontrolliert\u003c/h2\u003e\n\u003cp\u003eEin Autonomous System (AS) ist eine routingtechnische Einheit, die unter einer gemeinsamen administrativen Kontrolle steht. Im Internet wird sie über eine Autonomous System Number (ASN) identifiziert. Mit \u003ca href=\"/kubernetes/\"\u003eBGP\u003c/a\u003e\n kündigt ein AS IP-Präfixe gegenüber anderen Netzen an und empfängt Informationen über erreichbare Routen.\u003c/p\u003e\n\u003cp\u003eFür den öffentlichen Traffic-Eintritt ist das relevant, weil die Kontrolle über die IP-Präfixe nicht vollständig an einen einzelnen Transit- oder Hostinganbieter delegiert werden muss. Ein eigenes AS kann die Grundlage bilden, um Erreichbarkeit über mehrere Netzwerkpfade zu organisieren, Provider zu wechseln oder Traffic-Ankündigungen gezielt zu steuern.\u003c/p\u003e\n\u003cp\u003eDiese Kontrolle ist allerdings begrenzt. Die tatsächlichen Pfade entstehen aus BGP-Policies vieler beteiligter Netze. Ein eigenes AS garantiert daher weder einen bestimmten Weg noch eine bestimmte Latenz. Es schafft vielmehr eine eigene administrative Ebene für Routingentscheidungen und reduziert die Bindung an die Routing-Identität eines einzelnen Providers.\u003c/p\u003e\n\u003ch2 id=\"2-routingkontrolle-ist-mehr-als-providerwechsel\"\u003e2. Routingkontrolle ist mehr als Providerwechsel\u003c/h2\u003e\n\u003cp\u003eDigitale Souveränität zeigt sich nicht allein darin, einen Anbieter austauschen zu können. Relevant ist, ob die öffentliche Erreichbarkeit, die IP-Adressierung und die Verteilung des Traffics auch bei wechselnden Infrastrukturpartnern kontrollierbar bleiben. Dafür müssen Routing, DNS, Edge-Verarbeitung und Backend-Anbindung zusammenpassen.\u003c/p\u003e\n\u003cp\u003eEine Plattform mit eigenem AS kann IP-Präfixe über mehrere Netze erreichbar machen und den öffentlichen Einstieg von den dahinterliegenden Compute-Ressourcen entkoppeln. Anycast unterstützt dieses Modell, indem dieselben Adressen über mehrere geografisch verteilte Netzwerkpunkte angekündigt werden. Der Traffic gelangt dadurch an einen geeigneten Edge-Einstieg, bevor Schutz, TLS-Terminierung, Routing oder Lastverteilung greifen.\u003c/p\u003e\n\u003cp\u003eDie betriebliche Konsequenz: Ein Providerwechsel muss nicht zwangsläufig eine neue öffentliche Adresse oder eine vollständige DNS-Migration auslösen. Das reduziert Umstellungsrisiken und macht die Netzarchitektur langlebiger. Voraussetzung bleiben saubere BGP-Prozesse, abgestimmte Failover-Mechanismen und ein Betriebsteam, das Routing nicht als einmalige Konfiguration behandelt.\u003c/p\u003e\n\u003ch2 id=\"3-warum-das-eigene-as-allein-nicht-genügt\"\u003e3. Warum das eigene AS allein nicht genügt\u003c/h2\u003e\n\u003cp\u003eEin eigenes \u003ca href=\"/kubernetes/\"\u003eAutonomous System\u003c/a\u003e\n ist eine Kontrollmöglichkeit, aber keine vollständige Resilienzstrategie. Wer nur die ASN besitzt, den Traffic aber weiterhin über eine einzelne Infrastruktur, einen einzigen Transitpfad oder eine zentrale Edge-Instanz führt, hat wesentliche Abhängigkeiten beibehalten. Die formale Routingautonomie würde dann nicht der tatsächlichen Betriebsautonomie entsprechen.\u003c/p\u003e\n\u003cp\u003eEntscheidend ist deshalb die Architektur hinter den BGP-Ankündigungen. Redundante Netzwerkpfade, verteilte Edge-Punkte, Health Checks und Failover müssen gemeinsam betrachtet werden. Ebenso wichtig ist die Trennung zwischen Edge und Compute: Die Edge verarbeitet den öffentlichen Traffic-Eintritt, während Anwendungen in separaten Compute-Umgebungen betrieben werden können.\u003c/p\u003e\n\u003cp\u003eDie ayedo Edge Cloud verbindet dafür eigenes Autonomous System und eigene Netzwerkinfrastruktur mit einer verteilten Multi-PoP-Architektur und einem Aktiv-Aktiv-Prinzip. Das ist nicht gleichbedeutend mit vollständiger Providerunabhängigkeit, schafft aber eine technische Basis, um Erreichbarkeit und Schutzfunktionen von einzelnen Backends oder Compute-Providern zu entkoppeln.\u003c/p\u003e\n\u003ch2 id=\"4-souveränität-als-betriebs--und-entscheidungsmodell\"\u003e4. Souveränität als Betriebs- und Entscheidungsmodell\u003c/h2\u003e\n\u003cp\u003eRoutingkontrolle entfaltet ihren Wert erst, wenn sie in Betriebsprozesse übersetzt wird. Dazu gehören klare Zuständigkeiten für Präfixe, \u003ca href=\"/kubernetes/\"\u003eBGP\u003c/a\u003e\n-Ankündigungen, DNS, Zertifikate, DDoS-Reaktion und Failover. Ohne diese Prozesse kann eine technisch autonome Plattform durch fehlerhafte Änderungen oder unklare Eskalationswege trotzdem schwer steuerbar sein.\u003c/p\u003e\n\u003cp\u003eAuch die wirtschaftliche Perspektive ist relevant. Eine Abhängigkeit von einem einzelnen Netzwerkbetreiber kann Wechselkosten erzeugen: neue IP-Adressen, Anpassungen an Allow- und Deny-Listen, Zertifikatswechsel oder Änderungen an Integrationen. Eine stabile Edge-Adresse und providerübergreifende Erreichbarkeit können solche Folgekosten reduzieren. Sie ersetzen jedoch nicht die Prüfung von Transitverträgen, Routing-Policies und Notfallverfahren.\u003c/p\u003e\n\u003cp\u003eDie ayedo Edge Cloud bündelt den öffentlichen Einstieg, Anycast-Routing, Anycast DNS beziehungsweise Multi-Provider-DNS sowie Traffic-Verteilung an der Edge. Für \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n-Anwendungen kann sie unabhängig davon eingesetzt werden, ob der Cluster von ayedo, einem anderen Provider oder selbst betrieben wird. Souveränität bleibt damit eine Architekturentscheidung und kein Markenmerkmal.\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 benötigt einen stabilen öffentlichen Einstieg. Beim klassischen Modell stellt der Hostingprovider IP-Adressen, Routing und vorgeschaltete Schutzfunktionen bereit. Ein Wechsel des Providers kann dadurch DNS-Anpassungen, neue Allow-Listen und Änderungen an Partnerintegrationen auslösen.\u003c/p\u003e\n\u003cp\u003eIn einem alternativen Modell liegt der öffentliche Einstieg bei einer Edge-Plattform mit eigenem AS. Die Präfixe und der DNS-Einstieg sind von der konkreten Compute-Umgebung entkoppelt. Fällt ein Backend aus, übernehmen Health Checks und Failover die Steuerung; muss der Compute-Provider gewechselt werden, bleibt die Edge-Schicht unverändert. Der Vorteil ist nicht absolute Unabhängigkeit, sondern eine klarere Trennung von Routing-, Edge- und Compute-Verantwortung.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"ist-ein-eigenes-autonomous-system-automatisch-digital-souverän\"\u003eIst ein eigenes Autonomous System automatisch digital souverän?\u003c/h3\u003e\n\u003cp\u003eNein. Es erweitert die Routingkontrolle. Souveränität erfordert zusätzlich unabhängige Infrastruktur, mehrere Pfade, belastbare Prozesse und die Fähigkeit, Abhängigkeiten transparent zu steuern.\u003c/p\u003e\n\u003ch3 id=\"welche-rolle-spielt-bgp-dabei\"\u003eWelche Rolle spielt BGP dabei?\u003c/h3\u003e\n\u003cp\u003e\u003ca href=\"/kubernetes/\"\u003eBGP\u003c/a\u003e\n verteilt Informationen über erreichbare IP-Präfixe. Ein eigenes AS ermöglicht eigene Ankündigungen und Policies, garantiert aber keinen bestimmten Internetpfad oder eine bestimmte Performance.\u003c/p\u003e\n\u003ch3 id=\"muss-die-anwendung-im-selben-netzwerk-betrieben-werden\"\u003eMuss die Anwendung im selben Netzwerk betrieben werden?\u003c/h3\u003e\n\u003cp\u003eNein. Eine Edge-Plattform kann den öffentlichen Traffic unabhängig vom Compute-Standort verarbeiten und an eigene oder providerbetriebenen \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n-Cluster sowie andere Backends weiterleiten.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eEin eigenes \u003ca href=\"/kubernetes/\"\u003eAutonomous System\u003c/a\u003e\n ist kein abstraktes Infrastrukturmerkmal, sondern eine Entscheidung über die Kontrolle des öffentlichen Eintrittspunkts. Es schafft eine eigene Routing-Identität und kann Abhängigkeiten von einzelnen Netzwerkbetreibern reduzieren. Wirkungsvoll wird es erst zusammen mit verteilter Edge-Infrastruktur, Anycast, redundanten Pfaden und klaren Betriebsprozessen. Die ayedo Edge Cloud ordnet diese Bausteine in einer eigenständigen Edge-Plattform ein und trennt öffentliche Erreichbarkeit von der Wahl der Compute-Umgebung.\u003c/p\u003e\n", "summary": "\nTL;DR Ein eigenes Autonomous System schafft keine vollständige Unabhängigkeit, erweitert aber die Kontrolle über den öffentlichen Traffic-Eintritt. Über BGP lassen sich Erreichbarkeit und Routing eigenständig gestalten. In Verbindung mit eigener Netzwerkinfrastruktur, Anycast und Aktiv-Aktiv-Betrieb wird digitale Souveränität zu einer überprüfbaren Architekturentscheidung.\nEinleitung Ein zentraler Netzwerkbetreiber kann technisch zum Single Point of Control werden, selbst wenn Anwendungen redundant über mehrere Rechenzentren verteilt sind. Entscheidend ist nicht nur, wo Workloads laufen, sondern wer die öffentliche Erreichbarkeit über das Internet steuert. Ein eigenes Autonomous System verschiebt diese Kontrolle: Das Unternehmen oder der Plattformbetreiber kann IP-Präfixe unter eigener Routing-Identität ankündigen und die Abhängigkeit von einzelnen Providern reduzieren. Das bedeutet jedoch nicht, dass BGP automatisch unabhängige oder optimale Pfade garantiert. Souveränität entsteht erst durch das Zusammenspiel aus Routing-Kontrolle, eigener Netzwerkinfrastruktur, redundanten Upstreams und einem belastbaren Betriebsmodell.\n", "image": "https://ayedo.de/digitale-souveranitat-durch-eigenes-autonomous-system.png", "date_published": "2026-09-04T22:25:57Z", "date_modified": "2026-09-04T22:25:57Z", "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}], "tags": ["digital-sovereignty","hosting","politics","operations","kubernetes"], "language": "de" },{ "id": "https://ayedo.de/posts/netzwerk-infrastruktur-als-grundlage-digitaler-souveranitat/", "url": "https://ayedo.de/posts/netzwerk-infrastruktur-als-grundlage-digitaler-souveranitat/", "title": "Netzwerk-Infrastruktur als Grundlage digitaler Souveränität", "content_html": "\u003cp\u003e\u003cimg src=\"/posts/netzwerk-infrastruktur-als-grundlage-digitaler-souveranitat/netzwerk-infrastruktur-als-grundlage-digitaler-souveranitat.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eDigitale Souveränität entsteht nicht allein durch die Wahl einer Cloud-Anwendung. Entscheidend ist, wer Netzwerk, öffentlichen Zugang, Routing und Schutzmechanismen kontrolliert. Eine getrennte Edge- und Compute-Architektur schafft dafür klare Verantwortungsbereiche: Die Edge Cloud steuert den externen Traffic, während Backends unabhängig auf eigenen oder fremden \u003ca href=\"/kubernetes/\"\u003eCompute-Plattformen\u003c/a\u003e\n betrieben werden können.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eDigitale Souveränität wird häufig auf Datenhaltung, Softwareauswahl oder den Betrieb einer einzelnen Cloud-Anwendung reduziert. Diese Perspektive greift technisch zu kurz. Wer den öffentlichen Zugang zu Anwendungen, DNS, Routing und Schutzmechanismen nicht kontrollieren kann, bleibt auch bei souverän betriebenen Backends von einer fremden Netzwerkarchitektur abhängig. Der entscheidende Hebel liegt deshalb in der Trennung von Netzwerk, Edge und Compute. Eine solche Trennung erlaubt, den Eintrittspunkt digitaler Dienste unabhängig vom Ausführungsort der Workloads zu betreiben. Sie verändert damit nicht nur die Architektur, sondern auch Failover, Providerwechsel, Sicherheitskontrolle und betriebliche Verantwortlichkeiten.\u003c/p\u003e\n\u003ch2 id=\"1-souveränität-beginnt-vor-dem-backend\"\u003e1. Souveränität beginnt vor dem Backend\u003c/h2\u003e\n\u003cp\u003eEine Anwendung ist aus Netzwerksicht nicht erst dort relevant, wo ihr Prozess läuft. Bereits DNS-Auflösung, Anycast-Routing, TLS-Terminierung, DDoS-Abwehr und die Auswahl eines erreichbaren Backends bestimmen, wie ein Dienst öffentlich betrieben wird. Liegen diese Funktionen vollständig bei einem einzelnen \u003ca href=\"/kubernetes/\"\u003eCompute- oder Cloud-Anbieter\u003c/a\u003e\n, entsteht eine enge Kopplung zwischen Workload und Zugangsschicht.\u003c/p\u003e\n\u003cp\u003eDas wirkt sich bei Migrationen unmittelbar aus. Ein Wechsel der \u003ca href=\"/kubernetes/\"\u003eCompute-Plattform\u003c/a\u003e\n kann dann Änderungen an DNS, Zertifikaten, IP-Adressen, Firewall-Regeln, Monitoring und Traffic-Verteilung erfordern. Die technische Abhängigkeit liegt nicht nur im Hosting der Anwendung, sondern in der gesamten Kette vor ihr.\u003c/p\u003e\n\u003cp\u003eDigitale Souveränität Netzwerk-Infrastruktur bedeutet daher nicht, jede Komponente selbst zu bauen. Gemeint ist die Fähigkeit, zentrale Netzwerkentscheidungen nachvollziehbar zu steuern und Anbietergrenzen bewusst zu gestalten. Dazu gehören die Kontrolle des öffentlichen Eintrittspunkts, die Sichtbarkeit des Traffics und die Möglichkeit, Backends auszutauschen, ohne die externe Service-Identität neu zu erfinden.\u003c/p\u003e\n\u003ch2 id=\"2-edge-und-compute-sind-unterschiedliche-verantwortungsbereiche\"\u003e2. Edge und Compute sind unterschiedliche Verantwortungsbereiche\u003c/h2\u003e\n\u003cp\u003eDie Edge Cloud übernimmt den öffentlichen Eingang vor Anwendungen und APIs. Sie verarbeitet eingehenden Traffic, schützt ihn und verteilt ihn an geeignete Backends. Dazu gehören beispielsweise Anycast-basiertes Layer-4- und Layer-7-Loadbalancing, Anycast DNS, Multi-Provider-DNS, WAF, DDoS Protection, TLS Termination und Backend Health Checks.\u003c/p\u003e\n\u003cp\u003eDie \u003ca href=\"/kubernetes/\"\u003eCompute-Infrastruktur\u003c/a\u003e\n hat eine andere Aufgabe: Sie führt Anwendungen, Datenverarbeitung und Workloads aus. Diese Trennung ist architektonisch relevant, weil der Edge-Einstiegspunkt nicht an einen bestimmten Cluster oder Provider gebunden sein muss. Backends können in ayedo Managed Kubernetes, in eigenen Kubernetes-Clustern oder bei anderen Providern betrieben werden.\u003c/p\u003e\n\u003cp\u003eBackend Cloaking verstärkt diese Entkopplung. Die eigentlichen Ursprungsadressen müssen nicht als öffentliche Anwendungsendpunkte dienen. Stattdessen kommunizieren externe Clients mit der Edge, während die Backend-Struktur intern und austauschbar bleibt. Das reduziert die Angriffsfläche und erleichtert die kontrollierte Veränderung der Compute-Seite.\u003c/p\u003e\n\u003ch2 id=\"3-eigene-netzwerkinfrastruktur-schafft-operative-kontrolle\"\u003e3. Eigene Netzwerkinfrastruktur schafft operative Kontrolle\u003c/h2\u003e\n\u003cp\u003eKontrolle über die Edge ist mehr als die Konfiguration eines vorgeschalteten Loadbalancers. Entscheidend sind die darunterliegenden Verantwortungsbereiche: Routing, Adressierung, Erreichbarkeit und der Umgang mit Störungen. Eine eigene Netzwerk-Infrastruktur und ein eigenes Autonomous System schaffen dafür eine technische Grundlage. Sie ermöglichen, die Edge als eigenständige Plattform zu betreiben, statt sie lediglich als Funktion eines Compute-Angebots zu betrachten.\u003c/p\u003e\n\u003cp\u003eDie Aktiv-Aktiv-Architektur einer verteilten Multi-PoP-Umgebung wirkt dabei auf die Betriebsführung. Traffic kann über mehrere Edge-Standorte verarbeitet werden, während Health Checks und Failover die Erreichbarkeit der Backends bewerten. Störungen werden damit nicht automatisch zu einem Problem der gesamten Anwendungskette; sie können auf Edge-, Routing- oder Compute-Ebene getrennt analysiert werden.\u003c/p\u003e\n\u003cp\u003eFür Security-Teams entstehen ebenfalls klarere Kontrollpunkte. WAF, DDoS-Scrubbing und TLS Termination liegen an der öffentlichen Grenze. Für Betriebsteams bedeutet das eine eindeutige Zuständigkeit: Die Edge verantwortet den Eintritt und die Verteilung, Compute-Teams verantworten die Workloads. Diese Trennung reduziert organisatorische Kopplung, ersetzt aber keine abgestimmten Betriebsprozesse.\u003c/p\u003e\n\u003ch2 id=\"4-souveränität-braucht-austauschbarkeit-nicht-isolation\"\u003e4. Souveränität braucht Austauschbarkeit, nicht Isolation\u003c/h2\u003e\n\u003cp\u003eEine souveräne Netzwerkarchitektur ist nicht automatisch vollständig unabhängig. Sie bleibt auf Transit, Upstream-Konnektivität, Hardware, Software und externe Dienste angewiesen. Der technische Anspruch sollte deshalb nicht absolute Isolation sein, sondern kontrollierbare Abhängigkeit. Providerunabhängige Nutzung und die Trennung von Edge und Compute erhöhen die Fähigkeit, einzelne Ebenen zu wechseln, ohne den gesamten Dienst neu zu entwerfen.\u003c/p\u003e\n\u003cp\u003eBring Your Own IP kann dabei die externe Identität eines Dienstes stabil halten. Anycast DNS und Multi-Provider-DNS adressieren die Namensauflösung und die Verteilung über mehrere DNS-Infrastrukturen. Proxy Protocol kann relevante Verbindungsinformationen bis zum Backend transportieren, wenn Anwendungen oder Sicherheitskontrollen die ursprüngliche Client-Verbindung auswerten müssen.\u003c/p\u003e\n\u003cp\u003eDiese Funktionen sind kein Ersatz für Architekturentscheidungen. Sie müssen zu Routing, Failover, Zertifikatsmanagement, Logging und Verantwortungsmodellen passen. Der wirtschaftliche Vorteil entsteht vor allem dann, wenn ein Providerwechsel, ein Clusterwechsel oder eine Sicherheitsmaßnahme nicht die gesamte öffentliche Plattform destabilisiert.\u003c/p\u003e\n\u003ch2 id=\"praxis--und-betriebsszenario-wechsel-der-compute-plattform\"\u003ePraxis- und Betriebsszenario: Wechsel der Compute-Plattform\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt eine API in einem \u003ca href=\"/kubernetes/\"\u003eKubernetes-Cluster\u003c/a\u003e\n bei Provider A und plant den Umzug zu einem eigenen Cluster. Bei einer direkt an den Provider gebundenen Architektur ändern sich während der Migration öffentliche IPs, DNS-Einträge, TLS-Konfiguration und Schutzregeln gleichzeitig. Das erhöht die Zahl der Fehlerquellen.\u003c/p\u003e\n\u003cp\u003eIn einer getrennten Architektur bleibt der öffentliche Endpunkt an der Edge bestehen. Das neue Backend wird parallel angebunden, durch Health Checks validiert und schrittweise in die Traffic-Verteilung aufgenommen. Erst wenn die Anwendung stabil arbeitet, wird der alte Ursprung entfernt. Die Edge Cloud entkoppelt damit nicht nur Adressen und Routing vom Compute, sondern macht den Wechsel als kontrollierten Betriebsprozess planbar.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"ist-digitale-souveränität-ohne-eigenen-cloud-betrieb-möglich\"\u003eIst digitale Souveränität ohne eigenen Cloud-Betrieb möglich?\u003c/h3\u003e\n\u003cp\u003eJa. Souveränität kann durch kontrollierte Architekturgrenzen entstehen. Entscheidend ist, welche Netzwerk- und Betriebsentscheidungen ein Unternehmen selbst steuern kann, nicht ob jede \u003ca href=\"/kubernetes/\"\u003eCompute-Komponente\u003c/a\u003e\n im eigenen Rechenzentrum läuft.\u003c/p\u003e\n\u003ch3 id=\"warum-reicht-ein-loadbalancer-im-kubernetes-cluster-nicht-aus\"\u003eWarum reicht ein Loadbalancer im Kubernetes-Cluster nicht aus?\u003c/h3\u003e\n\u003cp\u003eEin clusterinterner Loadbalancer löst primär die Verteilung auf Workloads. DNS, DDoS-Schutz, öffentliche Adressierung, Backend-Cloaking und providerübergreifendes Routing liegen weiterhin außerhalb dieser Funktion.\u003c/p\u003e\n\u003ch3 id=\"muss-die-edge-beim-selben-anbieter-wie-der-compute-liegen\"\u003eMuss die Edge beim selben Anbieter wie der Compute liegen?\u003c/h3\u003e\n\u003cp\u003eNein. Eine Edge-Plattform kann Backends in ayedo Managed Kubernetes, eigenen Clustern oder bei anderen Providern erreichen. Gerade diese Entkopplung reduziert die Bindung an eine einzelne \u003ca href=\"/kubernetes/\"\u003eCompute-Plattform\u003c/a\u003e\n.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eDigitale Souveränität Netzwerk-Infrastruktur ist eine Frage der kontrollierten Beziehungen zwischen Netz, Edge und Compute. Wer den öffentlichen Zugang, Routing und Schutz unabhängig vom Ausführungsort der Workloads gestalten kann, gewinnt technische Beweglichkeit und klarere Betriebsgrenzen. Die ayedo Edge Cloud ordnet diese Ebene als eigenständige, verteilte Plattform mit eigener Netzwerk-Infrastruktur und eigenem Autonomous System ein. Damit bleibt Compute austauschbar, ohne den öffentlichen Zugang zwangsläufig neu zu bauen.\u003c/p\u003e\n", "summary": "\nTL;DR Digitale Souveränität entsteht nicht allein durch die Wahl einer Cloud-Anwendung. Entscheidend ist, wer Netzwerk, öffentlichen Zugang, Routing und Schutzmechanismen kontrolliert. Eine getrennte Edge- und Compute-Architektur schafft dafür klare Verantwortungsbereiche: Die Edge Cloud steuert den externen Traffic, während Backends unabhängig auf eigenen oder fremden Compute-Plattformen betrieben werden können.\nEinleitung Digitale Souveränität wird häufig auf Datenhaltung, Softwareauswahl oder den Betrieb einer einzelnen Cloud-Anwendung reduziert. Diese Perspektive greift technisch zu kurz. Wer den öffentlichen Zugang zu Anwendungen, DNS, Routing und Schutzmechanismen nicht kontrollieren kann, bleibt auch bei souverän betriebenen Backends von einer fremden Netzwerkarchitektur abhängig. Der entscheidende Hebel liegt deshalb in der Trennung von Netzwerk, Edge und Compute. Eine solche Trennung erlaubt, den Eintrittspunkt digitaler Dienste unabhängig vom Ausführungsort der Workloads zu betreiben. Sie verändert damit nicht nur die Architektur, sondern auch Failover, Providerwechsel, Sicherheitskontrolle und betriebliche Verantwortlichkeiten.\n", "image": "https://ayedo.de/netzwerk-infrastruktur-als-grundlage-digitaler-souveranitat.png", "date_published": "2026-09-04T22:25:57Z", "date_modified": "2026-09-04T22:25:57Z", "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}], "tags": ["digital-sovereignty","security","operations","politics","hosting"], "language": "de" },{ "id": "https://ayedo.de/posts/die-betriebskosten-verteilter-edge-hochverfugbarkeit/", "url": "https://ayedo.de/posts/die-betriebskosten-verteilter-edge-hochverfugbarkeit/", "title": "Die Betriebskosten verteilter Edge-Hochverfügbarkeit", "content_html": "\u003cp\u003e\u003cimg src=\"/posts/die-betriebskosten-verteilter-edge-hochverfugbarkeit/die-betriebskosten-verteilter-edge-hochverfugbarkeit.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eEine verteilte Aktiv-Aktiv-Architektur erhöht die Resilienz, verursacht aber zusätzliche Kosten für redundante Kapazitäten, Überwachung, Tests und operative Zuständigkeiten. Ihre Wirtschaftlichkeit zeigt sich deshalb nicht allein an Infrastrukturpreisen. Entscheidend ist, ob die Architektur Ausfallrisiken, Wiederanlaufzeiten und Abhängigkeiten so reduziert, dass ihr Betriebsaufwand zum Schutzbedarf passt.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eHochverfügbarkeit wird häufig als technische Kapazitätsfrage behandelt: Mehrere Standorte, mehrere Instanzen und ein automatisches Failover sollen Ausfälle verhindern. Der wirtschaftliche Trade-off liegt jedoch im laufenden Betrieb. Eine verteilte Aktiv-Aktiv-Infrastruktur muss nicht nur bereitgestellt, sondern kontinuierlich überwacht, getestet, aktualisiert und organisatorisch beherrscht werden. Redundante Systeme erzeugen Kosten, auch wenn sie im Normalbetrieb scheinbar ungenutzt bleiben. Gleichzeitig kann eine zentralisierte Architektur an einem gemeinsamen Netzwerk-, Provider- oder Betriebsrisiko scheitern. Die relevante Frage lautet daher nicht, ob verteilte Hochverfügbarkeit teurer ist, sondern ob die zusätzlichen Kosten zur geschäftlichen Bedeutung der geschützten Anwendungen und APIs passen.\u003c/p\u003e\n\u003ch2 id=\"1-redundante-kapazität-ist-ein-dauerhafter-kostenblock\"\u003e1. Redundante Kapazität ist ein dauerhafter Kostenblock\u003c/h2\u003e\n\u003cp\u003eIn einer Aktiv-Aktiv-Architektur sind mehrere Komponenten gleichzeitig produktiv. Das betrifft nicht nur Rechenleistung, sondern auch Netzwerkpfade, Routing, Traffic-Verarbeitung und Sicherheitsfunktionen. Die Kapazität muss so dimensioniert sein, dass ein verbleibender Teil der Infrastruktur den relevanten Traffic bei Ausfall eines anderen Teils übernehmen kann. Daraus entsteht ein bewusster Overhead: Im Normalbetrieb wird Redundanz vorgehalten, im Störungsfall wird sie benötigt.\u003c/p\u003e\n\u003cp\u003eFür die Total Cost of Ownership zählen deshalb nicht nur monatliche Infrastrukturkosten. Relevant sind ebenso Datenverkehr, Schutz- und Verarbeitungsleistung, Monitoring, Bereitschaft und die technische Pflege der Failover-Mechanismen. Eine rein durchschnittliche Auslastung kann die Wirtschaftlichkeit falsch darstellen, wenn Spitzenlasten oder Ausfallszenarien die Dimensionierung bestimmen. Die Entscheidung muss sich an Wiederanlaufzielen, maximal tolerierbarem Kapazitätsverlust und dem Wert der betroffenen Services orientieren.\u003c/p\u003e\n\u003ch2 id=\"2-verteilte-systeme-erhöhen-den-betriebsaufwand\"\u003e2. Verteilte Systeme erhöhen den Betriebsaufwand\u003c/h2\u003e\n\u003cp\u003eMit jedem zusätzlichen Fehlerbereich wächst die Zahl der Zustände, die ein Betriebsteam verstehen muss. Traffic kann über mehrere Pfade eintreffen, Health Checks können unterschiedliche Ergebnisse liefern, und Änderungen an Routing, TLS, WAF-Regeln oder Backends müssen konsistent ausgerollt werden. Auch ein scheinbar lokaler Fehler kann durch Abhängigkeiten zwischen DNS, Netzwerk und Backend-Erreichbarkeit größere Auswirkungen haben.\u003c/p\u003e\n\u003cp\u003eDer Betriebsaufwand besteht daher nicht nur aus mehr Komponenten, sondern aus mehr Koordination. Runbooks müssen konkrete Fehlerbilder abdecken, Zuständigkeiten zwischen Netzwerk-, Plattform- und Anwendungsteams müssen geklärt sein. Eine Edge-Plattform mit eigener Netzwerk-Infrastruktur und eigenem Autonomous System kann externe Abhängigkeiten im öffentlichen Eingang reduzieren. Sie beseitigt jedoch nicht die organisatorische Verantwortung: Routing, Failover, Konfiguration und Eskalation benötigen weiterhin definierte Betriebsprozesse.\u003c/p\u003e\n\u003ch2 id=\"3-testbarkeit-entscheidet-über-den-realen-nutzen\"\u003e3. Testbarkeit entscheidet über den realen Nutzen\u003c/h2\u003e\n\u003cp\u003eRedundanz ist nur dann belastbar, wenn ihr Verhalten unter Fehlerbedingungen bekannt ist. Ein Failover, das nie kontrolliert getestet wurde, ist zunächst eine Annahme. Tests müssen unter anderem den Ausfall eines Netzwerkpfads, die Nichtverfügbarkeit eines Backends, fehlerhafte Health Checks und die Rückkehr in den Normalbetrieb abbilden. Bei Aktiv-Aktiv-Systemen kommt hinzu, dass beide Seiten gleichzeitig Traffic verarbeiten und Änderungen ohne unbeabsichtigte Asymmetrien wirken müssen.\u003c/p\u003e\n\u003cp\u003eDiese Tests verursachen Aufwand, reduzieren aber das Risiko unbemerkter Fehlkonfigurationen. Sie benötigen Testfenster, klare Abbruchkriterien und eine Auswertung der Auswirkungen auf Anwendungen und Nutzer. Wirtschaftlich relevant ist auch die Nachweisbarkeit: Unternehmen können Betriebs- und Wiederanlaufprozesse belastbarer planen, wenn sie nicht nur theoretische Redundanz, sondern beobachtetes Systemverhalten bewerten. Ohne regelmäßige Tests bleibt ein Teil der Investition ungenutzt.\u003c/p\u003e\n\u003ch2 id=\"4-überwachung-muss-fehlerursachen-statt-nur-verfügbarkeit-messen\"\u003e4. Überwachung muss Fehlerursachen statt nur Verfügbarkeit messen\u003c/h2\u003e\n\u003cp\u003eVerteilte Hochverfügbarkeit erzeugt mehr Messpunkte und mehr mögliche Fehlerursachen. Ein Dienst kann erreichbar sein, während einzelne Backends, Netzwerkpfade oder Schutzkomponenten bereits beeinträchtigt sind. Umgekehrt kann ein Health Check aus Sicht der Edge erfolgreich sein, obwohl die Anwendung funktional fehlerhafte Antworten liefert. Monitoring muss deshalb Traffic, Backend-Zustände, Failover-Ereignisse und Fehlerraten in einen gemeinsamen betrieblichen Kontext setzen.\u003c/p\u003e\n\u003cp\u003eDas beeinflusst sowohl Tooling als auch Personalbedarf. Teams benötigen klare Schwellenwerte, abgestimmte Alarmierung und ausreichend historische Traffic- und Usage-Statistiken, um Kapazitätsentscheidungen zu treffen. Eine verteilte Edge Cloud wie ayedo verbindet dafür den öffentlichen Traffic-Eingang mit Loadbalancing, Backend Health Checks, Failover und zentraler Beobachtung. Der wirtschaftliche Nutzen entsteht nicht automatisch durch diese Funktionen, sondern durch weniger manuelle Diagnose und eine präzisere Steuerung des Betriebs.\u003c/p\u003e\n\u003ch2 id=\"praxis--und-betriebsszenario\"\u003ePraxis- und Betriebsszenario\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt eine geschäftskritische API in mehreren \u003ca href=\"/kubernetes/\"\u003eKubernetes-Clustern\u003c/a\u003e\n bei unterschiedlichen Providern. Ein zentraler Loadbalancer vor nur einem Provider wäre zunächst einfacher und günstiger. Er konzentriert jedoch den öffentlichen Eingang und erzeugt eine zusätzliche Abhängigkeit. Eine verteilte Aktiv-Aktiv-Edge verteilt den Traffic zu mehreren Backends und kann bei deren Ausfall umsteuern. Dafür müssen Kapazitätsreserven, Health Checks, Konfigurationsänderungen und Störungstests geplant werden. Die Entscheidung hängt somit davon ab, ob die Kosten des zusätzlichen Betriebsaufwands geringer sind als die Folgen eines zentralen Ausfallpunkts. Für weniger kritische Services kann die einfachere Architektur wirtschaftlich sinnvoller bleiben.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"ist-aktiv-aktiv-immer-wirtschaftlicher-als-aktiv-passiv\"\u003eIst Aktiv-Aktiv immer wirtschaftlicher als Aktiv-Passiv?\u003c/h3\u003e\n\u003cp\u003eNein. Aktiv-Aktiv nutzt Ressourcen kontinuierlich besser, benötigt aber mehr Koordination und Testaufwand. Die passende Variante hängt von Ausfallkosten, Lastprofil, Wiederanlaufziel und organisatorischer Reife ab.\u003c/p\u003e\n\u003ch3 id=\"welche-kosten-werden-bei-hochverfügbarkeit-häufig-unterschätzt\"\u003eWelche Kosten werden bei Hochverfügbarkeit häufig unterschätzt?\u003c/h3\u003e\n\u003cp\u003eNeben Infrastruktur zählen Monitoring, Bereitschaft, Tests, Change-Management, Dokumentation und Schulung. Besonders teuer werden ungeklärte Zuständigkeiten und manuelle Verfahren im Störungsfall.\u003c/p\u003e\n\u003ch3 id=\"warum-ist-ein-eigenes-autonomous-system-wirtschaftlich-relevant\"\u003eWarum ist ein eigenes Autonomous System wirtschaftlich relevant?\u003c/h3\u003e\n\u003cp\u003eEs kann die Kontrolle über den öffentlichen Netzwerk-Eingang und Routing-Entscheidungen erhöhen. Der Nutzen muss gegen den zusätzlichen fachlichen und organisatorischen Betriebsaufwand bewertet werden.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eDie Kosten verteilter Hochverfügbarkeit entstehen nicht allein durch zusätzliche Infrastruktur. Sie liegen ebenso in Testbarkeit, Überwachung, Kapazitätsplanung und abgestimmten Betriebsprozessen. Eigene Netzwerk-Infrastruktur und ein eigenes Autonomous System können Abhängigkeiten im Edge-Betrieb reduzieren, ersetzen aber keine technische und organisatorische Disziplin. Die ayedo Edge Cloud ist in diesem Zusammenhang als verteilte Plattform für Traffic-Eingang, Schutz, Routing und Failover zu bewerten. Ihre Wirtschaftlichkeit ergibt sich aus dem Verhältnis von zusätzlicher Komplexität und vermiedenem Ausfallrisiko.\u003c/p\u003e\n", "summary": "\nTL;DR Eine verteilte Aktiv-Aktiv-Architektur erhöht die Resilienz, verursacht aber zusätzliche Kosten für redundante Kapazitäten, Überwachung, Tests und operative Zuständigkeiten. Ihre Wirtschaftlichkeit zeigt sich deshalb nicht allein an Infrastrukturpreisen. Entscheidend ist, ob die Architektur Ausfallrisiken, Wiederanlaufzeiten und Abhängigkeiten so reduziert, dass ihr Betriebsaufwand zum Schutzbedarf passt.\nEinleitung Hochverfügbarkeit wird häufig als technische Kapazitätsfrage behandelt: Mehrere Standorte, mehrere Instanzen und ein automatisches Failover sollen Ausfälle verhindern. Der wirtschaftliche Trade-off liegt jedoch im laufenden Betrieb. Eine verteilte Aktiv-Aktiv-Infrastruktur muss nicht nur bereitgestellt, sondern kontinuierlich überwacht, getestet, aktualisiert und organisatorisch beherrscht werden. Redundante Systeme erzeugen Kosten, auch wenn sie im Normalbetrieb scheinbar ungenutzt bleiben. Gleichzeitig kann eine zentralisierte Architektur an einem gemeinsamen Netzwerk-, Provider- oder Betriebsrisiko scheitern. Die relevante Frage lautet daher nicht, ob verteilte Hochverfügbarkeit teurer ist, sondern ob die zusätzlichen Kosten zur geschäftlichen Bedeutung der geschützten Anwendungen und APIs passen.\n", "image": "https://ayedo.de/die-betriebskosten-verteilter-edge-hochverfugbarkeit.png", "date_published": "2026-09-04T22:19:02Z", "date_modified": "2026-09-04T22:19:02Z", "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}], "tags": ["cloud-native","security","development","finops","operations"], "language": "de" },{ "id": "https://ayedo.de/posts/aktiv-aktiv-und-backend-failover-im-zusammenspiel/", "url": "https://ayedo.de/posts/aktiv-aktiv-und-backend-failover-im-zusammenspiel/", "title": "Aktiv-Aktiv und Backend-Failover im Zusammenspiel", "content_html": "\u003cp\u003e\u003cimg src=\"/posts/aktiv-aktiv-und-backend-failover-im-zusammenspiel/aktiv-aktiv-und-backend-failover-im-zusammenspiel.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eAktiv-Aktiv an der Edge beseitigt keinen Backend-Ausfall. Hochverfügbarkeit entsteht erst, wenn beide Ebenen getrennt geplant und technisch gekoppelt werden: Die Edge verteilt eingehenden Traffic redundant, während Backend Health Checks die Erreichbarkeit einzelner Ziele bewerten. Erst daraus entsteht belastbares \u003ca href=\"/kubernetes/\"\u003eBackend-Failover\u003c/a\u003e\n.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eEin redundanter Zugang ist keine hochverfügbare Anwendung. Fällt ein Backend aus, kann auch eine aktiv-aktive Edge den Traffic weiterhin zuverlässig an ein nicht funktionsfähiges Ziel verteilen. Umgekehrt hilft ein redundanter Compute-Cluster wenig, wenn der öffentliche Eingang, das Routing oder die Lastverteilung selbst eine zentrale Fehlerdomäne bildet. Hochverfügbarkeit muss deshalb entlang der gesamten Anforderungskette betrachtet werden: vom Anycast-Eingang über die Edge-Verarbeitung bis zu den Backends. Entscheidend ist dabei die klare Trennung von Edge und Compute. Die Edge Cloud übernimmt Annahme, Schutz, Routing und Verteilung des Traffics. Die Compute-Infrastruktur betreibt die Anwendung. \u003ca href=\"/kubernetes/\"\u003eBackend-Failover\u003c/a\u003e\n verbindet beide Verantwortungsbereiche, ohne sie zu vermischen.\u003c/p\u003e\n\u003ch2 id=\"1-aktiv-aktiv-an-der-edge-reduziert-die-fehlerdomäne\"\u003e1. Aktiv-Aktiv an der Edge reduziert die Fehlerdomäne\u003c/h2\u003e\n\u003cp\u003eBei einer Aktiv-Aktiv-Architektur sind mehrere Edge-Standorte gleichzeitig in der Lage, eingehenden Traffic zu verarbeiten. Anycast sorgt dafür, dass eine IP-Adresse aus verschiedenen Netzwerkpositionen erreichbar ist und der Traffic über die verfügbare Edge-Infrastruktur aufgenommen werden kann. Fällt ein einzelner Edge-Pfad oder eine einzelne Instanz aus, muss nicht der gesamte öffentliche Eingang umgeschaltet werden.\u003c/p\u003e\n\u003cp\u003eDas ist architektonisch etwas anderes als ein einzelner Loadbalancer mit einem Standby-System. Dort existiert häufig ein zentraler Umschaltpunkt, dessen Zustand, Routing und Erreichbarkeit selbst kritisch sind. Eine verteilte Aktiv-Aktiv-Edge mit eigener Netzwerk-Infrastruktur und eigenem Autonomous System reduziert diese Abhängigkeit auf der Zugangsebene.\u003c/p\u003e\n\u003cp\u003eDamit ist jedoch nur eine Fehlerdomäne adressiert. Die Edge kann Anfragen weiterhin annehmen, TLS an der Edge terminieren, Regeln der Web Application Firewall anwenden und Traffic verteilen. Ob ein Backend die Anfrage noch sinnvoll verarbeiten kann, ist eine separate Frage. Aktiv-Aktiv beschreibt daher zunächst die Betriebsbereitschaft der Edge, nicht automatisch die Redundanz der Anwendung.\u003c/p\u003e\n\u003ch2 id=\"2-backend-failover-braucht-belastbare-health-checks\"\u003e2. Backend-Failover braucht belastbare Health Checks\u003c/h2\u003e\n\u003cp\u003e\u003ca href=\"/kubernetes/\"\u003eBackend-Failover\u003c/a\u003e\n basiert auf einer Zustandsentscheidung: Ein Ziel wird verwendet, solange es die definierten Erreichbarkeits- und Funktionskriterien erfüllt. Backend Health Checks liefern dafür die technische Grundlage. Sie prüfen nicht nur, ob ein Port erreichbar ist, sondern sollten möglichst einen für den Dienst aussagekräftigen Zustand abbilden. Ein Prozess kann Verbindungen akzeptieren, obwohl abhängige Datenbanken, Queues oder interne Services bereits nicht verfügbar sind.\u003c/p\u003e\n\u003cp\u003eDie Qualität des Failovers hängt deshalb von mehreren Parametern ab: Prüfintervall, Timeout, Anzahl notwendiger Fehlversuche und Zeit bis zur Wiederaufnahme eines Backends. Zu aggressive Werte können bei kurzen Störungen unnötige Umschaltungen auslösen. Zu konservative Werte halten Traffic dagegen zu lange an einem defekten Ziel. Beides erzeugt betriebliche Risiken: instabile Lastverteilung im ersten Fall, verlängerte Fehlerzeiten im zweiten.\u003c/p\u003e\n\u003cp\u003eHealth Checks sind außerdem kein Ersatz für Anwendungsdesign. Sie erkennen Verfügbarkeit aus Sicht der Edge, aber nicht automatisch fachliche Korrektheit, Datenkonsistenz oder sichere Wiederholbarkeit. Für mutierende Requests müssen Idempotenz, Session-Verhalten und mögliche Nebenwirkungen separat bewertet werden.\u003c/p\u003e\n\u003ch2 id=\"3-edge-und-compute-müssen-als-getrennte-ebenen-geplant-werden\"\u003e3. Edge und Compute müssen als getrennte Ebenen geplant werden\u003c/h2\u003e\n\u003cp\u003eDie Edge Cloud ist der öffentliche Eingang vor Anwendungen und APIs. Sie schützt und verarbeitet eingehenden Traffic, übernimmt Lastverteilung und kann Backends durch Backend Cloaking aus dem öffentlichen Netz herausnehmen. Die Compute-Infrastruktur führt dagegen die Workloads aus und entscheidet über Replikation, Datenhaltung, Clusterbetrieb und Wiederanlauf. Diese Trennung verhindert, dass die Verfügbarkeit eines einzelnen Compute-Providers automatisch mit der Verfügbarkeit des öffentlichen Eingangs gleichgesetzt wird.\u003c/p\u003e\n\u003cp\u003eFür die Architektur bedeutet das: Backends können bei ayedo Managed \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n, in eigenen Kubernetes-Clustern oder bei anderen Providern betrieben werden. Die Edge-Funktionen bleiben dabei eine eigenständige Schicht. Ein Wechsel oder Failover auf ein anderes Backend muss nicht den öffentlichen DNS-Namen oder die externe IP-Struktur der Anwendung verändern.\u003c/p\u003e\n\u003cp\u003eDiese Entkopplung erleichtert auch organisatorische Entscheidungen. Ein Plattformteam kann die Edge zentral betreiben und Policies, Zertifikate, Schutzmechanismen sowie Statistiken standardisieren, während Anwendungsteams ihre Compute-Umgebung unabhängig verantworten. Voraussetzung ist eine klare Zuständigkeit dafür, welche Signale einen Failover auslösen und wer deren Auswirkungen bewertet.\u003c/p\u003e\n\u003ch2 id=\"4-redundanz-braucht-abgestimmte-betriebslogik\"\u003e4. Redundanz braucht abgestimmte Betriebslogik\u003c/h2\u003e\n\u003cp\u003eEin aktiv-aktiver Edge-Eingang und mehrere Backends ergeben nicht automatisch eine aktiv-aktive Anwendung. Backends können parallel produktiv sein, als Primär- und Sekundärsystem betrieben werden oder nur für einen definierten Wiederanlauffall bereitstehen. Die Edge kann anhand von Health Checks verfügbare Ziele berücksichtigen, aber sie kann keine fehlende Datenreplikation oder widersprüchliche Zustände zwischen Anwendungssystemen kompensieren.\u003c/p\u003e\n\u003cp\u003eBesonders relevant ist das bei Sessions, Schreibzugriffen und regional verteilten Daten. Werden Anfragen nach einem Ausfall an ein anderes Backend geleitet, muss dieses den erforderlichen Zustand kennen oder die Anwendung muss stateless arbeiten. Andernfalls führt korrektes technisches Failover zu fachlichen Fehlern. Auch Connection Draining und kontrollierte Wiederaufnahme sind wichtig, damit laufende Verbindungen nicht unnötig abgebrochen werden und ein wiederhergestelltes Backend nicht sofort überlastet wird.\u003c/p\u003e\n\u003cp\u003eBetrieblich sollten Edge-Metriken und Backend-Signale gemeinsam ausgewertet werden. Traffic- und Usage-Statistiken zeigen, wie sich die Verteilung verändert; Health Checks erklären, warum Ziele aus dem Pool entfernt oder wieder aufgenommen wurden. Erst diese Kombination macht Failover nachvollziehbar und testbar.\u003c/p\u003e\n\u003ch2 id=\"praxisszenario-zwei-backends-ein-gemeinsamer-edge-eingang\"\u003ePraxisszenario: Zwei Backends, ein gemeinsamer Edge-Eingang\u003c/h2\u003e\n\u003cp\u003eEine API läuft in zwei getrennten \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n-Umgebungen. Beide sind über die ayedo Edge Cloud erreichbar; der öffentliche Einstieg bleibt durch Anycast und die verteilte Edge-Struktur unabhängig von einem einzelnen Compute-Standort. Backend Health Checks prüfen einen anwendungsnahen Endpunkt. Solange beide Ziele gesund sind, verteilt die Edge den Traffic entsprechend der konfigurierten Lastverteilung.\u003c/p\u003e\n\u003cp\u003eFällt die abhängige Datenbank eines Backends aus, bleibt der Containerprozess möglicherweise erreichbar. Ein einfacher TCP-Check würde das Ziel weiter berücksichtigen. Ein geeigneter Health Check erkennt dagegen den nicht funktionsfähigen Dienst und nimmt das Backend aus der Verteilung. Der Traffic geht auf das verbleibende Ziel. Bei nicht idempotenten Requests müssen Wiederholungen und bereits gestartete Transaktionen trotzdem auf Anwendungsebene behandelt werden.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"ist-aktiv-aktiv-an-der-edge-dasselbe-wie-aktiv-aktiv-im-backend\"\u003eIst Aktiv-Aktiv an der Edge dasselbe wie Aktiv-Aktiv im Backend?\u003c/h3\u003e\n\u003cp\u003eNein. Aktiv-Aktiv an der Edge beschreibt die parallele Verarbeitung des öffentlichen Traffics. Backend-Aktivität, Datenreplikation und fachliche Konsistenz müssen in der Compute- und Anwendungsschicht umgesetzt werden.\u003c/p\u003e\n\u003ch3 id=\"wann-ist-ein-tcp-health-check-ausreichend\"\u003eWann ist ein TCP-Health-Check ausreichend?\u003c/h3\u003e\n\u003cp\u003eFür einfache Erreichbarkeitsprüfungen kann TCP genügen. Für APIs und Anwendungen sollte der Check möglichst einen Dienstzustand prüfen, der auch kritische Abhängigkeiten berücksichtigt.\u003c/p\u003e\n\u003ch3 id=\"verhindert-backend-failover-datenverlust\"\u003eVerhindert Backend-Failover Datenverlust?\u003c/h3\u003e\n\u003cp\u003eNein. Failover verteilt Traffic auf ein verfügbares Ziel. Datenhaltbarkeit, Replikation, Transaktionssicherheit und Wiederholbarkeit bleiben Aufgaben der Anwendung und ihrer Compute-Infrastruktur.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eMehrschichtige Hochverfügbarkeit entsteht nicht durch eine einzelne redundante Komponente. Die Edge muss den öffentlichen Eingang aktiv-aktiv und providerunabhängig bereitstellen, während Backends ihre eigene Verfügbarkeit und Datenkonsistenz sicherstellen. Backend Health Checks bilden die Verbindung zwischen beiden Ebenen, ersetzen aber kein robustes Anwendungsdesign. Die ayedo Edge Cloud ist in diesem Modell eine eigenständige Edge-Plattform vor unterschiedlichen Compute-Umgebungen – nicht lediglich ein Loadbalancer vor einem einzelnen Cluster.\u003c/p\u003e\n", "summary": "\nTL;DR Aktiv-Aktiv an der Edge beseitigt keinen Backend-Ausfall. Hochverfügbarkeit entsteht erst, wenn beide Ebenen getrennt geplant und technisch gekoppelt werden: Die Edge verteilt eingehenden Traffic redundant, während Backend Health Checks die Erreichbarkeit einzelner Ziele bewerten. Erst daraus entsteht belastbares Backend-Failover .\nEinleitung Ein redundanter Zugang ist keine hochverfügbare Anwendung. Fällt ein Backend aus, kann auch eine aktiv-aktive Edge den Traffic weiterhin zuverlässig an ein nicht funktionsfähiges Ziel verteilen. Umgekehrt hilft ein redundanter Compute-Cluster wenig, wenn der öffentliche Eingang, das Routing oder die Lastverteilung selbst eine zentrale Fehlerdomäne bildet. Hochverfügbarkeit muss deshalb entlang der gesamten Anforderungskette betrachtet werden: vom Anycast-Eingang über die Edge-Verarbeitung bis zu den Backends. Entscheidend ist dabei die klare Trennung von Edge und Compute. Die Edge Cloud übernimmt Annahme, Schutz, Routing und Verteilung des Traffics. Die Compute-Infrastruktur betreibt die Anwendung. Backend-Failover verbindet beide Verantwortungsbereiche, ohne sie zu vermischen.\n", "image": "https://ayedo.de/aktiv-aktiv-und-backend-failover-im-zusammenspiel.png", "date_published": "2026-09-04T22:19:01Z", "date_modified": "2026-09-04T22:19:01Z", "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/betriebsmodelle-fur-hochverfugbare-edge-plattformen/", "url": "https://ayedo.de/posts/betriebsmodelle-fur-hochverfugbare-edge-plattformen/", "title": "Betriebsmodelle für hochverfügbare Edge-Plattformen", "content_html": "\u003cp\u003e\u003cimg src=\"/posts/betriebsmodelle-fur-hochverfugbare-edge-plattformen/betriebsmodelle-fur-hochverfugbare-edge-plattformen.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eHochverfügbarkeit an der Edge entsteht nicht allein durch mehrere Standorte oder Aktiv-Aktiv-Routing. Entscheidend ist der Day-two-Betrieb: konsistente Konfigurationen, belastbare Health Checks, aussagekräftige Traffic-Statistiken, geübte Incident Response und kontrollierte Failover. Erst diese Prozesse machen eine verteilte Edge-Plattform dauerhaft beherrschbar.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eEine Aktiv-Aktiv-Edge-Plattform reduziert die Abhängigkeit von einzelnen Standorten, erhöht aber gleichzeitig die Anforderungen an den Betrieb. Jede Änderung an Routing, DNS, TLS, WAF-Regeln oder Backend-Zielen kann mehrere aktive Traffic-Pfade beeinflussen. Ein Ausfall ist dann nicht nur ein Infrastrukturproblem, sondern auch eine Frage der Konfigurationskonsistenz und der Entscheidungsfähigkeit im Incident. Der zentrale Architekturfehler besteht darin, Edge-Hochverfügbarkeit als Bereitstellungsaufgabe zu behandeln. Day-two-Operations müssen bereits beim Design berücksichtigt werden: Wer erkennt eine Fehlverteilung? Welche Signale lösen Failover aus? Und wie wird nach einer Störung nachgewiesen, dass der Normalbetrieb wiederhergestellt ist?\u003c/p\u003e\n\u003ch2 id=\"1-aktiv-aktiv-braucht-ein-verbindliches-betriebsmodell\"\u003e1. Aktiv-Aktiv braucht ein verbindliches Betriebsmodell\u003c/h2\u003e\n\u003cp\u003eIn einer Aktiv-Aktiv-Architektur nehmen mehrere Edge-Standorte gleichzeitig Traffic an. Das verbessert die Fehlertoleranz, erzeugt aber einen zusätzlichen Kontrollbedarf: Routing-Informationen, DNS-Zustände, TLS-Konfigurationen, WAF-Regeln und Backend-Zuordnungen müssen über die beteiligten Komponenten hinweg konsistent sein. Schon kleine Abweichungen können dazu führen, dass identische Anfragen je nach Eintrittspunkt unterschiedlich verarbeitet werden.\u003c/p\u003e\n\u003cp\u003eKonfigurationskonsistenz ist deshalb kein reines Automatisierungsthema. Sie braucht klare Verantwortlichkeiten, versionierte Änderungen, Freigabepunkte und eine nachvollziehbare Rückkehr zu einem bekannten Zustand. Besonders kritisch sind Änderungen, die mehrere Ebenen verbinden, etwa ein neues Backend mit angepassten Health Checks und geänderten TLS- oder WAF-Regeln.\u003c/p\u003e\n\u003cp\u003eFür den Betrieb bedeutet das: Edge-Konfigurationen müssen wie produktiver Code behandelt werden. Ein Betriebsmodell sollte definieren, welche Änderungen automatisch ausgerollt werden dürfen, wann eine gestufte Aktivierung erforderlich ist und welche Prüfkriterien vor der vollständigen Verteilung gelten.\u003c/p\u003e\n\u003ch2 id=\"2-monitoring-muss-traffic-und-zustand-zusammenführen\"\u003e2. Monitoring muss Traffic und Zustand zusammenführen\u003c/h2\u003e\n\u003cp\u003eEin einzelner Verfügbarkeitscheck beschreibt den Zustand einer Edge-Plattform nur unvollständig. Ein Dienst kann technisch erreichbar sein, während Fehlerraten, Antwortzeiten, TLS-Fehler oder bestimmte Routing-Pfade bereits auffällig sind. Umgekehrt kann ein einzelnes Backend ausfallen, ohne dass die gesamte Edge-Plattform beeinträchtigt ist.\u003c/p\u003e\n\u003cp\u003eSinnvolles Edge Operations verbindet daher mehrere Signaltypen: Erreichbarkeit der Frontends, Backend Health Checks, DNS- und Routing-Zustände, Status der Schutzfunktionen sowie Traffic- und Usage-Statistiken. Letztere helfen, normale Lastmuster von Fehlverteilungen oder unerwarteten Traffic-Spitzen zu unterscheiden. Wichtig ist dabei die Korrelation: Ein Anstieg von 5xx-Fehlern erhält eine andere Bedeutung, wenn parallel nur ein Backend betroffen ist, als bei einem regionalen Ausfall eines Edge-Pfads.\u003c/p\u003e\n\u003cp\u003eDie ayedo Edge Cloud stellt dafür Backend Health Checks, Failover sowie Traffic- und Usage-Statistiken als Bestandteile der Edge-Plattform bereit. Die betriebliche Aufgabe bleibt jedoch beim Unternehmen: Schwellenwerte, Alerting, Eskalationen und die Interpretation der Signale müssen zum jeweiligen Service und dessen Kritikalität passen.\u003c/p\u003e\n\u003ch2 id=\"3-health-checks-steuern-verhalten--sie-ersetzen-keine-diagnose\"\u003e3. Health Checks steuern Verhalten – sie ersetzen keine Diagnose\u003c/h2\u003e\n\u003cp\u003eHealth Checks sind ein Steuerungsmechanismus für Failover. Sie entscheiden, ob ein Backend weiterhin Traffic erhalten soll. Daraus folgt eine wichtige Einschränkung: Ein Check kann die technische Erreichbarkeit prüfen, aber nicht automatisch die fachliche Korrektheit einer Anwendung bewerten.\u003c/p\u003e\n\u003cp\u003eZu großzügige Checks lassen fehlerhafte Backends im Pool. Zu strenge oder falsch platzierte Checks entfernen dagegen funktionierende Kapazität und können eine Störung verstärken. Deshalb sollten Checks gezielt die Abhängigkeiten abbilden, die für die Annahme von Traffic relevant sind. Ein einfacher TCP-Check kann für eine bestimmte Schicht genügen, für eine HTTP-Anwendung aber zu wenig Aussagekraft besitzen.\u003c/p\u003e\n\u003cp\u003eFailover muss außerdem beobachtbar und reversibel sein. Teams müssen erkennen können, wann ein Backend aus dem Traffic genommen wurde, welcher alternative Pfad aktiv ist und ob sich die Last dort verändert. Nach der Wiederherstellung darf ein Backend nicht unkontrolliert sofort wieder vollständig belastet werden. Kontrollierte Rückführung und anschließende Validierung gehören zum Betriebsprozess, nicht nur zur Implementierung des Checks.\u003c/p\u003e\n\u003ch2 id=\"4-incident-response-und-failover-müssen-geübt-werden\"\u003e4. Incident Response und Failover müssen geübt werden\u003c/h2\u003e\n\u003cp\u003eIm Incident zählt nicht nur, ob Failover technisch möglich ist. Entscheidend ist, ob das Team die Situation schnell einordnen und ohne widersprüchliche Eingriffe handeln kann. Dafür braucht es definierte Rollen, Eskalationswege, Runbooks und eine klare Trennung zwischen Diagnose, Mitigation und Wiederherstellung.\u003c/p\u003e\n\u003cp\u003eFailover-Übungen sollten reale Betriebsannahmen prüfen: Was geschieht bei einem nicht erreichbaren Backend, einer fehlerhaften Konfiguration oder einem Problem mit einem Traffic-Pfad? Welche Statistiken bestätigen die Wirkung? Wie wird verhindert, dass eine lokale Störung durch manuelle Änderungen auf weitere Edge-Standorte übertragen wird?\u003c/p\u003e\n\u003cp\u003eEine Übung ist erst dann aussagekräftig, wenn auch die Rückkehr zum Normalbetrieb betrachtet wird. Dazu gehören die Wiederherstellung der Konfigurationskonsistenz, die Überprüfung der Health-Check-Ergebnisse und die Analyse der Traffic-Verteilung. Für Unternehmen ist das zugleich eine wirtschaftliche Frage: Geübte Abläufe verkürzen Ausfälle und reduzieren das Risiko, dass mehrere Teams gleichzeitig unkoordinierte Änderungen durchführen.\u003c/p\u003e\n\u003ch2 id=\"betriebsszenario-failover-bei-fehlerhaftem-backend\"\u003eBetriebsszenario: Failover bei fehlerhaftem Backend\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt eine API auf mehreren \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n-Clustern, die bei unterschiedlichen Providern liegen. Die ayedo Edge Cloud nimmt den öffentlichen Traffic an, schützt die HTTP-Schnittstelle und verteilt Anfragen über definierte Backend-Ziele. Fällt ein Cluster aus, melden die Health Checks den Zustand und der Traffic wird auf verfügbare Ziele gelenkt.\u003c/p\u003e\n\u003cp\u003eIm Betrieb reichen die Checks allein nicht aus. Das Team prüft zusätzlich Traffic-Statistiken, Fehlerraten und die Auslastung der verbleibenden Backends. Nach der Entstörung wird das betroffene Ziel zunächst kontrolliert wieder zugeschaltet. Erst wenn die Verteilung, die Anwendungssignale und die Konfiguration konsistent sind, gilt der Incident als beendet. So wird Failover als überprüfbarer Betriebsablauf behandelt, nicht als unkontrollierte Nebenwirkung eines Ausfalls.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"welche-konfigurationen-sind-besonders-kritisch\"\u003eWelche Konfigurationen sind besonders kritisch?\u003c/h3\u003e\n\u003cp\u003eRouting, DNS, TLS, WAF-Regeln, Backend-Ziele und Health Checks. Änderungen an diesen Ebenen können direkt beeinflussen, welcher Traffic wo verarbeitet oder verworfen wird.\u003c/p\u003e\n\u003ch3 id=\"wie-oft-sollten-failover-übungen-stattfinden\"\u003eWie oft sollten Failover-Übungen stattfinden?\u003c/h3\u003e\n\u003cp\u003eDie Frequenz hängt von Kritikalität und Änderungsrate ab. Zusätzlich zu regelmäßigen Übungen sind Tests nach größeren Architektur-, Routing- oder Backend-Änderungen sinnvoll.\u003c/p\u003e\n\u003ch3 id=\"ist-aktiv-aktiv-automatisch-fehlertoleranter\"\u003eIst Aktiv-Aktiv automatisch fehlertoleranter?\u003c/h3\u003e\n\u003cp\u003eNein. Aktiv-Aktiv reduziert einzelne Ausfallabhängigkeiten, erhöht aber die Anforderungen an Konsistenz, Beobachtbarkeit, Lastverteilung und Incident Response.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eDer Betrieb hochverfügbarer Edge-Plattformen ist vor allem eine Frage kontrollierter Zustände: konsistente Konfigurationen, verständliche Signale, belastbare Health Checks und geübte Entscheidungen im Incident. Eine verteilte Aktiv-Aktiv-Architektur entfaltet ihren Wert erst, wenn diese Prozesse dauerhaft beherrscht werden. Die ayedo Edge Cloud ordnet öffentliche Erreichbarkeit, Schutz, Routing und Failover in einer eigenen Edge-Infrastruktur ein. Der eigentliche Hochverfügbarkeitsgewinn entsteht jedoch durch das Betriebsmodell, das diese Fähigkeiten reproduzierbar nutzt.\u003c/p\u003e\n", "summary": "\nTL;DR Hochverfügbarkeit an der Edge entsteht nicht allein durch mehrere Standorte oder Aktiv-Aktiv-Routing. Entscheidend ist der Day-two-Betrieb: konsistente Konfigurationen, belastbare Health Checks, aussagekräftige Traffic-Statistiken, geübte Incident Response und kontrollierte Failover. Erst diese Prozesse machen eine verteilte Edge-Plattform dauerhaft beherrschbar.\nEinleitung Eine Aktiv-Aktiv-Edge-Plattform reduziert die Abhängigkeit von einzelnen Standorten, erhöht aber gleichzeitig die Anforderungen an den Betrieb. Jede Änderung an Routing, DNS, TLS, WAF-Regeln oder Backend-Zielen kann mehrere aktive Traffic-Pfade beeinflussen. Ein Ausfall ist dann nicht nur ein Infrastrukturproblem, sondern auch eine Frage der Konfigurationskonsistenz und der Entscheidungsfähigkeit im Incident. Der zentrale Architekturfehler besteht darin, Edge-Hochverfügbarkeit als Bereitstellungsaufgabe zu behandeln. Day-two-Operations müssen bereits beim Design berücksichtigt werden: Wer erkennt eine Fehlverteilung? Welche Signale lösen Failover aus? Und wie wird nach einer Störung nachgewiesen, dass der Normalbetrieb wiederhergestellt ist?\n", "image": "https://ayedo.de/betriebsmodelle-fur-hochverfugbare-edge-plattformen.png", "date_published": "2026-09-04T22:19:01Z", "date_modified": "2026-09-04T22:19:01Z", "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}], "tags": ["operations","automation","cloud-native","kubernetes","digital-sovereignty"], "language": "de" },{ "id": "https://ayedo.de/posts/failover-an-der-edge-routing-zustande-und-grenzen/", "url": "https://ayedo.de/posts/failover-an-der-edge-routing-zustande-und-grenzen/", "title": "Failover an der Edge: Routing, Zustände und Grenzen", "content_html": "\u003cp\u003e\u003cimg src=\"/posts/failover-an-der-edge-routing-zustande-und-grenzen/failover-an-der-edge-routing-zustande-und-grenzen.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eEdge-Failover ist keine einzelne Umschaltentscheidung. Anycast, Routing-Konvergenz, Backend Health Checks und Protokollzustände greifen in mehreren Schritten ineinander. Sie lösen unterschiedliche Fehlerklassen und haben eigene zeitliche Grenzen. Wer diese Ebenen vermischt, überschätzt die Geschwindigkeit, Reichweite und Automatisierung eines Failovers.\u003c/p\u003e\n\u003cp\u003eEin Edge-Failover besteht aus mehreren Zustandsänderungen: Ein Backend kann aus dem Pool genommen werden, während das \u003ca href=\"/kubernetes/\"\u003eAnycast-Netzwerk\u003c/a\u003e\n weiterhin erreichbar ist. Umgekehrt kann ein Routing- oder PoP-Problem den öffentlichen Zugang beeinflussen, obwohl die Backends selbst gesund arbeiten. Erst die getrennte Betrachtung dieser Ebenen macht sichtbar, welche Ausfälle tatsächlich automatisch behandelt werden können.\u003c/p\u003e\n\u003ch2 id=\"1-anycast-und-routing-lösen-ein-anderes-problem-als-backend-failover\"\u003e1. Anycast und Routing lösen ein anderes Problem als Backend-Failover\u003c/h2\u003e\n\u003cp\u003eAnycast stellt dieselbe IP-Adresse über mehrere Netzwerkstandorte bereit. Das \u003ca href=\"/kubernetes/\"\u003eAnycast-Netzwerk\u003c/a\u003e\n verteilt eingehenden Traffic auf Basis der jeweils gültigen Routing-Informationen. Fällt ein Edge-Standort oder ein relevanter Netzwerkpfad aus, kann sich die bevorzugte Route ändern. Die Clients senden dann nach der Routing-Konvergenz zu einem anderen erreichbaren Einstiegspunkt.\u003c/p\u003e\n\u003cp\u003eDas ist jedoch kein Health Check für die Anwendung. Routing erkennt nicht automatisch, ob ein bestimmtes Backend HTTP-Fehler produziert, Datenbankverbindungen verliert oder nur einen einzelnen API-Pfad nicht mehr bedienen kann. Diese Zustände liegen auf einer anderen Ebene.\u003c/p\u003e\n\u003cp\u003eDie ayedo Edge Cloud nutzt ein eigenes Autonomous System und eigene Netzwerk-Infrastruktur in einer verteilten Multi-PoP-Architektur. Das schafft die Grundlage für \u003ca href=\"/kubernetes/\"\u003eAnycast\u003c/a\u003e\n und ein Aktiv-Aktiv-Modell. Es bedeutet aber nicht, dass jede Anfrage bei jedem Fehler ohne Unterbrechung neu zugestellt wird. Routing-Entscheidungen und bestehende Transportverbindungen haben jeweils eigene Zustände.\u003c/p\u003e\n\u003ch2 id=\"2-backend-health-checks-steuern-den-traffic-pool\"\u003e2. Backend Health Checks steuern den Traffic-Pool\u003c/h2\u003e\n\u003cp\u003eBackend Health Checks prüfen, ob ein Ziel aus Sicht der Edge weiterhin für neue Verbindungen oder Requests geeignet ist. Je nach Protokoll und Konfiguration können dabei unterschiedliche Kriterien relevant sein: Erreichbarkeit auf Layer 4, eine erfolgreiche Anwendungskommunikation auf Layer 7 oder ein definierter Health-Endpunkt.\u003c/p\u003e\n\u003cp\u003eErkennt die Edge ein fehlerhaftes Backend, kann sie dieses aus der Verteilung nehmen oder einen Failover auf andere Backends einleiten. Das ist Backend-Failover, nicht Routing-Failover. Die öffentliche Anycast-Adresse bleibt dabei grundsätzlich dieselbe; geändert wird die Auswahl innerhalb der Edge-Plattform.\u003c/p\u003e\n\u003cp\u003eWichtig ist der zeitliche Verlauf: Ein Health Check läuft in Intervallen und benötigt möglicherweise mehrere fehlerhafte Prüfungen, bevor ein Statuswechsel erfolgt. Nach der Wiederherstellung darf ein Backend ebenfalls nicht zwingend sofort wieder produktiv werden. Schwellenwerte, Prüfintervalle und Wiederanlaufverhalten sollen Fehlentscheidungen vermeiden, begrenzen aber die Reaktionsgeschwindigkeit. Ein zu aggressiver Check kann bei kurzen Lastspitzen unnötige Failover auslösen.\u003c/p\u003e\n\u003ch2 id=\"3-failover-besteht-aus-zuständen-nicht-aus-einem-schalter\"\u003e3. Failover besteht aus Zuständen, nicht aus einem Schalter\u003c/h2\u003e\n\u003cp\u003eDie Aussage „das System schaltet bei Ausfall automatisch um“ ist technisch unvollständig. Zunächst muss ein Fehler erkannt werden. Danach wird ein neuer Zustand bewertet und verteilt: etwa ein als unhealthy markiertes Backend, ein geänderter Routing-Pfad oder ein anderer erreichbarer Edge-Standort. Erst anschließend kann neuer Traffic entsprechend behandelt werden.\u003c/p\u003e\n\u003cp\u003eDabei unterscheiden sich neue und bestehende Verbindungen. Eine bereits etablierte TCP-Verbindung kann nicht beliebig an ein anderes Backend verschoben werden, weil ihr Verbindungszustand am bisherigen Pfad und Ziel hängt. Bei HTTP können Wiederholungen oder neue Verbindungen einen alternativen Pfad nutzen; das hängt jedoch vom Client, vom Protokoll und von der Anwendung ab. Nicht jede Anfrage ist gefahrlos wiederholbar.\u003c/p\u003e\n\u003cp\u003eAuch TLS-Sessions, langlebige Verbindungen, WebSockets und zustandsbehaftete Anwendungen setzen dem Failover Grenzen. TLS Termination an der Edge kann den Übergang vereinfachen, ersetzt aber keine Zustandsstrategie im Backend. Failover verschiebt Traffic – es repliziert keine Anwendungssitzung und korrigiert keine inkonsistenten Daten.\u003c/p\u003e\n\u003ch2 id=\"4-reichweite-und-automatisierungsgrad-müssen-konkret-bewertet-werden\"\u003e4. Reichweite und Automatisierungsgrad müssen konkret bewertet werden\u003c/h2\u003e\n\u003cp\u003eEin automatischer Failover kann nur die Fehlerklasse behandeln, für die ein Mechanismus Zustände erfassen und eine alternative Route oder ein alternatives Ziel bestimmen kann. Ein ausgefallener Service-Endpunkt ist eine andere Situation als ein vollständiger Provider-Ausfall, ein Fehler im Routing oder eine Überlastung aller verfügbaren Backends.\u003c/p\u003e\n\u003cp\u003eAuch die Reichweite ist begrenzt. Backend Health Checks können ein Ziel aus dem Traffic-Pool entfernen, aber sie beweisen nicht, dass eine gesamte Anwendung fachlich korrekt arbeitet. Anycast kann den Zugang über eine andere Netzwerkroute ermöglichen, garantiert jedoch nicht, dass dort eine gesunde Anwendung verfügbar ist. Routing-Konvergenz wiederum benötigt Zeit, und Resolver, Clients oder bestehende Sessions können alte Zustände weiterverwenden.\u003c/p\u003e\n\u003cp\u003eDeshalb sollte Failover als Prozess mit beobachtbaren Übergängen modelliert werden: Erkennung, Bewertung, Steuerung und Stabilisierung. Dazu gehören Health- und Traffic-Statistiken, definierte Zuständigkeiten und Tests für Teil- und Gesamtausfälle. Wirtschaftlich entscheidet diese Präzision darüber, ob ein Ausfall begrenzt wird oder nur zwischen mehreren Komponenten weitergereicht wird.\u003c/p\u003e\n\u003ch2 id=\"szenario-backend-ausfall-ohne-edge-ausfall\"\u003eSzenario: Backend-Ausfall ohne Edge-Ausfall\u003c/h2\u003e\n\u003cp\u003eEine API läuft aktiv auf zwei \u003ca href=\"/kubernetes/\"\u003eKubernetes-Clustern\u003c/a\u003e\n, die bei unterschiedlichen Providern betrieben werden. Beide Cluster sind über die ayedo Edge Cloud erreichbar. Ein Cluster verliert seine Datenbankverbindung; die Nodes und das Netzwerk bleiben jedoch erreichbar. Ein passiver TCP-Check würde den Fehler möglicherweise nicht erkennen. Ein passender Layer-7-Health-Check kann dagegen feststellen, dass der Service fachlich nicht mehr verfügbar ist, und das Backend aus der Verteilung nehmen.\u003c/p\u003e\n\u003cp\u003eDie Anycast-Adresse bleibt unverändert. Für neue Requests übernimmt das verbleibende Backend. Bereits offene Verbindungen können trotzdem fehlschlagen, und Requests mit nicht idempotenten Schreiboperationen dürfen nicht blind wiederholt werden. Fällt dagegen ein Edge-PoP oder ein Routing-Pfad aus, liegt die Fehlerbehandlung auf der Anycast- und Routing-Ebene – unabhängig davon, ob beide Backends gesund sind.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"ist-anycast-allein-ein-failover-mechanismus\"\u003eIst Anycast allein ein Failover-Mechanismus?\u003c/h3\u003e\n\u003cp\u003eNein. \u003ca href=\"/kubernetes/\"\u003eAnycast\u003c/a\u003e\n verteilt Erreichbarkeit über Routing-Pfade. Es ersetzt weder Backend Health Checks noch die Prüfung, ob eine Anwendung fachlich korrekt arbeitet.\u003c/p\u003e\n\u003ch3 id=\"wie-schnell-ist-edge-failover\"\u003eWie schnell ist Edge-Failover?\u003c/h3\u003e\n\u003cp\u003eDas hängt von Erkennungsintervallen, Schwellwerten, Routing-Konvergenz, Verbindungszuständen und Clientverhalten ab. Eine pauschale Umschaltzeit lässt sich technisch nicht seriös angeben.\u003c/p\u003e\n\u003ch3 id=\"funktioniert-failover-auch-bei-zustandsbehafteten-anwendungen\"\u003eFunktioniert Failover auch bei zustandsbehafteten Anwendungen?\u003c/h3\u003e\n\u003cp\u003eNur eingeschränkt. Die Edge kann Traffic umleiten, aber Sitzungen, Transaktionen und Datenkonsistenz müssen durch die Anwendung und ihre Backend-Architektur abgesichert werden.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eEdge-Failover ist eine Kette aus Zustandsbewertung und Verkehrssteuerung, kein einzelner Schalter. Anycast und Routing adressieren Erreichbarkeit auf Netzwerkebene; Health Checks steuern die Auswahl gesunder Backends. Die ayedo Edge Cloud verbindet diese Ebenen in einer providerunabhängig nutzbaren Edge-Plattform, ohne die Grenzen von Sessions, Routing-Konvergenz oder Anwendungszuständen aufzuheben. Belastbare Failover-Architekturen planen deshalb nicht nur den Wechsel, sondern auch Erkennung, Rückkehr und fachliche Konsistenz.\u003c/p\u003e\n", "summary": "\nTL;DR Edge-Failover ist keine einzelne Umschaltentscheidung. Anycast, Routing-Konvergenz, Backend Health Checks und Protokollzustände greifen in mehreren Schritten ineinander. Sie lösen unterschiedliche Fehlerklassen und haben eigene zeitliche Grenzen. Wer diese Ebenen vermischt, überschätzt die Geschwindigkeit, Reichweite und Automatisierung eines Failovers.\nEin Edge-Failover besteht aus mehreren Zustandsänderungen: Ein Backend kann aus dem Pool genommen werden, während das Anycast-Netzwerk weiterhin erreichbar ist. Umgekehrt kann ein Routing- oder PoP-Problem den öffentlichen Zugang beeinflussen, obwohl die Backends selbst gesund arbeiten. Erst die getrennte Betrachtung dieser Ebenen macht sichtbar, welche Ausfälle tatsächlich automatisch behandelt werden können.\n", "image": "https://ayedo.de/failover-an-der-edge-routing-zustande-und-grenzen.png", "date_published": "2026-09-04T22:19:01Z", "date_modified": "2026-09-04T22:19:01Z", "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}], "tags": ["automation","cloud-native","development","operations","kubernetes"], "language": "de" },{ "id": "https://ayedo.de/posts/hochverfugbarkeit-ohne-single-point-of-failure/", "url": "https://ayedo.de/posts/hochverfugbarkeit-ohne-single-point-of-failure/", "title": "Hochverfügbarkeit ohne Single Point of Failure", "content_html": "\u003cp\u003e\u003cimg src=\"/posts/hochverfugbarkeit-ohne-single-point-of-failure/hochverfugbarkeit-ohne-single-point-of-failure.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eEine redundante Edge beseitigt keinen Single Point of Failure, wenn DNS, Routing, TLS-Termination, WAF oder Backends weiterhin von einzelnen Komponenten oder Providern abhängen. Hochverfügbarkeit entsteht erst durch eine Ende-zu-Ende-Betrachtung aller Abhängigkeiten. Die ayedo Edge Cloud kann zentrale Edge-Risiken reduzieren, ersetzt aber keine redundante Backend- und Betriebsarchitektur.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eEine Anwendung ist nicht hochverfügbar, nur weil ihre Edge-Plattform über mehrere Standorte verteilt ist. Fällt ein einzelner DNS-Anbieter aus, erreicht der Traffic die Edge möglicherweise gar nicht. Ist die TLS-Termination an einen isolierten Dienst gebunden oder existiert das Backend nur in einer Availability Zone, bleibt die Anwendung trotz redundanter Traffic-Verteilung unerreichbar. Hochverfügbarkeit ohne Single Point of Failure ist deshalb keine Eigenschaft einer einzelnen Schicht. Sie entsteht erst, wenn DNS, Routing, Schutzfunktionen, Termination, Edge-Verteilung, Netzwerkanbindung und Backends als zusammenhängende Kette betrachtet werden.\u003c/p\u003e\n\u003ch2 id=\"1-hochverfügbarkeit-beginnt-vor-der-edge\"\u003e1. Hochverfügbarkeit beginnt vor der Edge\u003c/h2\u003e\n\u003cp\u003eDer erste mögliche Single Point of Failure liegt häufig im DNS. Eine Anwendung kann über mehrere Edge-Standorte verfügen und dennoch nicht erreichbar sein, wenn autoritative Nameserver, DNS-Provider oder Delegationen auf eine einzelne Infrastruktur verweisen. Auch eine redundante DNS-Konfiguration hilft nur, wenn Resolver, Provider-Anbindungen und Failover-Mechanismen unabhängig voneinander funktionieren.\u003c/p\u003e\n\u003cp\u003eBeim Routing entsteht ein ähnliches Bild. Anycast kann den öffentlichen Einstieg über mehrere Netzwerkstandorte verteilen, beseitigt aber nicht automatisch jede Abhängigkeit. Relevant sind unter anderem das Autonomous System, Transit- und Peering-Beziehungen, IP-Adressräume sowie die Fähigkeit, bei Störungen alternative Wege zu nutzen. Bring Your Own IP kann die Identität und Erreichbarkeit einer Anwendung unterstützen, ersetzt jedoch keine redundante Anbindung.\u003c/p\u003e\n\u003cp\u003eEine Ende-zu-Ende-Betrachtung fragt daher nicht nur: „Wie viele Edge-Standorte gibt es?“ Sie fragt, welche Komponente den Traffic tatsächlich erreichen, ankündigen und weiterleiten muss. Die ayedo Edge Cloud kombiniert Anycast DNS, Multi-Provider-DNS, eigenes Autonomous System und eigene Netzwerk-Infrastruktur. Dadurch werden bestimmte Abhängigkeiten an der öffentlichen Eintrittsschicht anders strukturiert. Die nachgelagerten Systeme bleiben jedoch eine separate Verantwortung.\u003c/p\u003e\n\u003ch2 id=\"2-redundanz-muss-jede-verarbeitungsstufe-abdecken\"\u003e2. Redundanz muss jede Verarbeitungsstufe abdecken\u003c/h2\u003e\n\u003cp\u003eNach DNS und Routing folgen mehrere Verarbeitungsschritte: TLS-Termination, WAF, Layer-4- oder Layer-7-Loadbalancing und die Weiterleitung zum Backend. Jede Stufe kann zum Engpass werden, wenn sie nur an einem Standort, in einer Zone oder bei einem Provider verfügbar ist. Eine redundante Architektur muss deshalb nicht nur Netzwerkpfade, sondern auch Zustände und Konfigurationen berücksichtigen.\u003c/p\u003e\n\u003cp\u003eTLS-Zertifikate, WAF-Regeln und Routing-Informationen müssen an allen relevanten Edge-Instanzen konsistent wirksam sein. Andernfalls kann ein Standort zwar erreichbar sein, Anfragen aber wegen fehlender Konfiguration ablehnen oder anders behandeln. Bei zustandsbehafteten Anwendungen kommt hinzu, dass Session-Daten, Token, Caches oder Uploads nicht implizit zwischen Standorten synchronisiert sind.\u003c/p\u003e\n\u003cp\u003eEine Aktiv-Aktiv-Architektur reduziert die Abhängigkeit von einer einzelnen aktiven Instanz. Sie verhindert aber nicht automatisch Konfigurationsfehler oder fehlerhafte Regeln, die gleichzeitig an allen Standorten ausgerollt werden. Die ayedo Edge Cloud ist als verteilte Multi-PoP-Plattform im Aktiv-Aktiv-Prinzip ausgelegt und übernimmt TLS-Termination, WAF sowie L4- und L7-Loadbalancing an der Edge. Das reduziert zentrale Edge-Abhängigkeiten, macht Änderungsprozesse und Konfigurationsvalidierung aber nicht überflüssig.\u003c/p\u003e\n\u003ch2 id=\"3-failover-endet-nicht-beim-backend-health-check\"\u003e3. Failover endet nicht beim Backend-Health-Check\u003c/h2\u003e\n\u003cp\u003eEin Health-Check beantwortet zunächst nur eine begrenzte Frage: Ist ein bestimmter Endpunkt erreichbar und liefert er ein erwartetes Ergebnis? Daraus folgt nicht automatisch, dass die Anwendung fachlich funktionsfähig ist. Ein Backend kann HTTP-Anfragen beantworten, während Datenbankverbindungen erschöpft, abhängige APIs nicht erreichbar oder Schreibvorgänge fehlerhaft sind.\u003c/p\u003e\n\u003cp\u003eFür eine belastbare Ende-zu-Ende-Verfügbarkeit müssen daher auch Backend-Topologie, Datenhaltung, Queues, externe Dienste und Verwaltungszugänge betrachtet werden. Mehrere \u003ca href=\"https://www.kubernetes.io/\" target=\"_blank\" rel=\"noopener\"\u003eKubernetes\u003c/a\u003e\n Replikas in einem Cluster schützen beispielsweise nicht vor dem Ausfall des gesamten Clusters, seines Netzwerks oder einer gemeinsamen Datenbank. Zwei Cluster bei unterschiedlichen Providern erhöhen die Unabhängigkeit, bringen aber zusätzliche Anforderungen an Datenreplikation, Zustandsverteilung und Deployment-Prozesse mit sich.\u003c/p\u003e\n\u003cp\u003eDie ayedo Edge Cloud kann Backends über Health Checks überwachen, Traffic verteilen und Failover unterstützen. Backend Cloaking verhindert zudem, dass die eigentlichen Backend-Endpunkte öffentlich exponiert werden müssen. Das verbessert die Trennung zwischen öffentlichem Eingang und Compute-Infrastruktur. Die Edge kann jedoch weder die Konsistenz einer Datenbank garantieren noch eine fehlerhafte Anwendung logisch reparieren. Hochverfügbarkeit endet deshalb nicht am Übergang von Edge zu Backend.\u003c/p\u003e\n\u003ch2 id=\"4-verfügbarkeit-ist-auch-eine-betriebs--und-abhängigkeitsfrage\"\u003e4. Verfügbarkeit ist auch eine Betriebs- und Abhängigkeitsfrage\u003c/h2\u003e\n\u003cp\u003eTechnische Redundanz verliert ihren Wert, wenn der Betrieb selbst einen gemeinsamen Ausfallpunkt bildet. Ein zentraler Zugriff auf DNS, Zertifikate, Routing oder Cluster kann Änderungen während eines Teil-Ausfalls verhindern. Ebenso problematisch sind identische Fehlkonfigurationen, nicht getestete Failover-Pfade und Abhängigkeiten von einem einzigen Provider für Monitoring, Identity Management oder Incident-Kommunikation.\u003c/p\u003e\n\u003cp\u003eFür die Bewertung sollten Unternehmen Abhängigkeiten dokumentieren und Ausfälle entlang realistischer Fehlerbilder testen: DNS-Provider nicht erreichbar, ein Edge-Standort gestört, TLS-Konfiguration fehlerhaft, ein Backend-Cluster isoliert oder eine Datenbank nur lesbar. Entscheidend ist nicht, ob irgendwo Redundanz vorhanden ist, sondern ob der verbleibende Pfad den vorgesehenen Service tatsächlich liefern kann.\u003c/p\u003e\n\u003cp\u003eProviderunabhängige Nutzung kann dabei eine strategische Option sein. Die ayedo Edge Cloud lässt sich mit ayedo Managed \u003ca href=\"https://www.kubernetes.io/\" target=\"_blank\" rel=\"noopener\"\u003eKubernetes\u003c/a\u003e\n sowie mit eigenen oder bei anderen Providern betriebenen Kubernetes-Clustern einsetzen. Damit kann die Edge als eigenständige öffentliche Zugangsschicht betrieben werden. Das schafft keine automatische Gesamtverfügbarkeit, ermöglicht aber eine klarere Trennung von Edge- und Compute-Risiken und verhindert, dass beide Bereiche zwingend an dieselbe Infrastruktur gekoppelt sind.\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 bei unterschiedlichen Providern. Beide Cluster sind über eine redundante ayedo Edge Cloud erreichbar. Ein Backend-Health-Check erkennt den Ausfall eines Clusters und leitet neue Verbindungen zum verbleibenden Cluster.\u003c/p\u003e\n\u003cp\u003eFällt jedoch die gemeinsame Datenbank aus, bleiben beide Cluster zwar technisch erreichbar, die API kann ihre Kernfunktion aber nicht mehr erfüllen. Ein anderes Szenario betrifft DNS: Ist nur ein autoritativer DNS-Anbieter konfiguriert, kann bereits dessen Ausfall den Zugriff auf die Edge verhindern. Erst die Kombination aus redundanter DNS-Struktur, unabhängigen Backend-Pfaden, getesteten Failover-Regeln und belastbarer Datenhaltung ergibt eine tragfähige Ende-zu-Ende-Architektur.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"ist-eine-multi-pop-edge-automatisch-hochverfügbar\"\u003eIst eine Multi-PoP-Edge automatisch hochverfügbar?\u003c/h3\u003e\n\u003cp\u003eNein. Sie reduziert Ausfallrisiken an der Edge. DNS, Routing, Konfigurationen, Backends, Datenbanken und betriebliche Abhängigkeiten müssen separat bewertet und redundant ausgelegt werden.\u003c/p\u003e\n\u003ch3 id=\"beseitigt-anycast-jeden-netzwerk-single-point-of-failure\"\u003eBeseitigt Anycast jeden Netzwerk-Single-Point-of-Failure?\u003c/h3\u003e\n\u003cp\u003eNein. Anycast verteilt Erreichbarkeit, beseitigt aber keine Abhängigkeiten von Autonomous System, Transit, Peering, DNS oder fehlerhaften Routing-Konfigurationen.\u003c/p\u003e\n\u003ch3 id=\"kann-die-edge-einen-ausgefallenen-cluster-vollständig-ersetzen\"\u003eKann die Edge einen ausgefallenen Cluster vollständig ersetzen?\u003c/h3\u003e\n\u003cp\u003eNein. Sie kann gesunde Backends erkennen und Traffic umleiten. Daten, Anwendungskonsistenz und abhängige Services müssen außerhalb der Edge verfügbar bleiben.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eHochverfügbarkeit ohne Single Point of Failure ist eine Eigenschaft der gesamten Servicekette, nicht einzelner Plattformen. Eine redundante Edge kann DNS-, Routing-, Schutz- und Verteilungsrisiken reduzieren, aber keine nicht redundanten Backends, Datenbanken oder Betriebsprozesse kompensieren. Die ayedo Edge Cloud ist in diesem Modell eine eigenständige, aktiv-aktive Eingangsschicht. Ihren technischen Wert entfaltet sie dort, wo Unternehmen Edge- und Compute-Abhängigkeiten getrennt analysieren und als zusammenhängende Ende-zu-Ende-Architektur betreiben.\u003c/p\u003e\n", "summary": "\nTL;DR Eine redundante Edge beseitigt keinen Single Point of Failure, wenn DNS, Routing, TLS-Termination, WAF oder Backends weiterhin von einzelnen Komponenten oder Providern abhängen. Hochverfügbarkeit entsteht erst durch eine Ende-zu-Ende-Betrachtung aller Abhängigkeiten. Die ayedo Edge Cloud kann zentrale Edge-Risiken reduzieren, ersetzt aber keine redundante Backend- und Betriebsarchitektur.\nEinleitung Eine Anwendung ist nicht hochverfügbar, nur weil ihre Edge-Plattform über mehrere Standorte verteilt ist. Fällt ein einzelner DNS-Anbieter aus, erreicht der Traffic die Edge möglicherweise gar nicht. Ist die TLS-Termination an einen isolierten Dienst gebunden oder existiert das Backend nur in einer Availability Zone, bleibt die Anwendung trotz redundanter Traffic-Verteilung unerreichbar. Hochverfügbarkeit ohne Single Point of Failure ist deshalb keine Eigenschaft einer einzelnen Schicht. Sie entsteht erst, wenn DNS, Routing, Schutzfunktionen, Termination, Edge-Verteilung, Netzwerkanbindung und Backends als zusammenhängende Kette betrachtet werden.\n", "image": "https://ayedo.de/hochverfugbarkeit-ohne-single-point-of-failure.png", "date_published": "2026-09-04T22:19:01Z", "date_modified": "2026-09-04T22:19:01Z", "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}], "tags": ["operations","kubernetes","hosting","cloud-native","digital-sovereignty"], "language": "de" },{ "id": "https://ayedo.de/posts/failure-domains-in-verteilten-edge-architekturen/", "url": "https://ayedo.de/posts/failure-domains-in-verteilten-edge-architekturen/", "title": "Failure Domains in verteilten Edge-Architekturen", "content_html": "\u003cp\u003e\u003cimg src=\"/posts/failure-domains-in-verteilten-edge-architekturen/failure-domains-in-verteilten-edge-architekturen.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eEine Multi-PoP-Architektur reduziert Ausfälle nicht automatisch. Entscheidend ist, welche Komponenten, Leitungen, Routingpfade und Backends dieselbe \u003ca href=\"https://de.wikipedia.org/wiki/Failure_Domain\" target=\"_blank\" rel=\"noopener\"\u003eFailure Domain\u003c/a\u003e\n teilen. Wer Fehlergrenzen statt Einzelkomponenten analysiert, erkennt gemeinsame Abhängigkeiten früher und kann Traffic, Schutzfunktionen und Failover gezielt entkoppeln.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eEin zusätzlicher Point of Presence erhöht die Verfügbarkeit nur dann, wenn ein Fehler nicht gleichzeitig mehrere Standorte oder zentrale Abhängigkeiten erreicht. Genau hier liegt ein häufiger Architekturfehler: Unternehmen zählen PoPs, Loadbalancer oder Backend-Instanzen, bewerten aber nicht, welche davon an dasselbe Netzwerk, dieselbe Routingentscheidung oder denselben Ursprung gekoppelt sind. Eine belastbare Ausfallanalyse beginnt deshalb nicht bei einzelnen Komponenten, sondern bei \u003ca href=\"/kubernetes/\"\u003eFailure Domains\u003c/a\u003e\n. Sie untersucht, welche Teile der Architektur gemeinsam ausfallen können, wie sich Fehler ausbreiten und welche Funktionsebene den Traffic noch übernehmen kann. Das betrifft die Edge selbst, die Netzwerkanbindung, DNS, Sicherheitsfunktionen und die Backends.\u003c/p\u003e\n\u003ch2 id=\"1-failure-domains-sind-fehlergrenzen-keine-komponentenlisten\"\u003e1. Failure Domains sind Fehlergrenzen, keine Komponentenlisten\u003c/h2\u003e\n\u003cp\u003eEine Failure Domain umfasst alle Ressourcen, die durch eine gemeinsame Ursache beeinträchtigt werden können. Das kann ein einzelner PoP sein, aber ebenso ein Provider, ein Transitpfad, eine Routingkonfiguration, eine DNS-Abhängigkeit oder ein gemeinsam genutztes Backend. Zwei Loadbalancer in getrennten Racks bilden daher nicht automatisch zwei unabhängige Fehlergrenzen, wenn sie dieselbe Stromversorgung, dasselbe Netzwerksegment oder denselben Upstream nutzen.\u003c/p\u003e\n\u003cp\u003eFür eine Multi-PoP-Architektur ist diese Unterscheidung zentral. Die relevante Frage lautet nicht: „Wie viele Standorte gibt es?“ Sondern: „Welche Fehler können mehrere Standorte gleichzeitig erreichen?“ Daraus entstehen Ebenen der Analyse: physischer Standort, Netzwerkpfad, Routing und DNS, Edge-Funktion sowie Backend. Jede Ebene benötigt eigene Annahmen über Ausfall, Erkennung und Wiederherstellung. Erst daraus lässt sich ableiten, ob Aktiv-Aktiv-Betrieb tatsächlich Fehler isoliert oder lediglich Kapazität verteilt.\u003c/p\u003e\n\u003ch2 id=\"2-gemeinsame-abhängigkeiten-zwischen-edge-und-netzwerk\"\u003e2. Gemeinsame Abhängigkeiten zwischen Edge und Netzwerk\u003c/h2\u003e\n\u003cp\u003eDie Edge kann Traffic nur verarbeiten, wenn sie erreichbar ist und Routingentscheidungen den Traffic zu funktionsfähigen Instanzen führen. Anycast reduziert dabei die Abhängigkeit von einem einzelnen Einstiegspunkt, beseitigt aber nicht jede gemeinsame Ursache. Routing, Upstream-Konnektivität, DNS und die Erreichbarkeit der einzelnen PoPs bleiben Teil derselben Ausfallanalyse.\u003c/p\u003e\n\u003cp\u003eEine eigene Netzwerk-Infrastruktur und ein eigenes Autonomous System schaffen in diesem Zusammenhang eine klarere technische Verantwortungsgrenze. Routing und Erreichbarkeit liegen stärker in einer zusammenhängenden Plattform, statt ausschließlich von der Netzwerktopologie eines einzelnen Infrastrukturproviders abzuhängen. Das ist keine vollständige Unabhängigkeit von externen Netzen: Transit- und Peering-Abhängigkeiten müssen weiterhin betrachtet werden. Der Beitrag liegt vielmehr in besserer Fehlerzuordnung, kontrollierbaren Routingpfaden und einer Architektur, in der Netzwerkredundanz bewusst gestaltet werden kann.\u003c/p\u003e\n\u003ch2 id=\"3-edge-funktionen-und-backends-bilden-getrennte-domänen\"\u003e3. Edge-Funktionen und Backends bilden getrennte Domänen\u003c/h2\u003e\n\u003cp\u003eDie Edge und die Compute-Infrastruktur erfüllen unterschiedliche Aufgaben. An der Edge werden öffentlicher Traffic angenommen, TLS terminiert, Anfragen geprüft, verteilt und bei Bedarf durch DDoS-Scrubbing geschützt. Die Anwendung läuft dagegen im Backend. Ein Ausfall der Edge ist deshalb ein anderer Fehler als ein Ausfall des Clusters oder der Datenbank. Beide können jedoch dieselbe Anwendung unzugänglich machen.\u003c/p\u003e\n\u003cp\u003eBackend Health Checks und Failover helfen nur, wenn tatsächlich alternative Backends verfügbar sind und deren Abhängigkeiten funktionieren. Ein zweiter \u003ca href=\"/kubernetes/\"\u003eKubernetes-Cluster\u003c/a\u003e\n in einer anderen Fehlerzone isoliert beispielsweise nicht automatisch einen gemeinsamen Datenbankdienst oder eine zentrale Netzwerkverbindung. Backend Cloaking begrenzt zwar die direkte öffentliche Erreichbarkeit der Ursprünge und reduziert damit die Angriffs- und Kopplungsfläche. Es ersetzt jedoch keine Analyse der Rückwege, Kapazitäten und Zustandsabhängigkeiten zwischen Edge und Backend.\u003c/p\u003e\n\u003ch2 id=\"4-fehlerisolierung-muss-verhalten-und-betrieb-einbeziehen\"\u003e4. Fehlerisolierung muss Verhalten und Betrieb einbeziehen\u003c/h2\u003e\n\u003cp\u003eFailure Domains sind nicht nur ein Infrastrukturthema. Entscheidend ist auch, wie die Plattform auf einen Fehler reagiert. Ein PoP-Ausfall kann durch Anycast und Aktiv-Aktiv-Verteilung abgefangen werden, sofern verbleibende PoPs ausreichend Kapazität besitzen und Routing sowie Health Checks den Fehler erkennen. Ein langsames oder teilweise gestörtes Backend stellt dagegen andere Anforderungen als ein harter Verbindungsabbruch. Falsche Schwellenwerte können Traffic zu einem überlasteten Ziel weiterleiten oder gesunde Backends unnötig aus dem Pool entfernen.\u003c/p\u003e\n\u003cp\u003eDeshalb sollte jede Fehlergrenze mit vier Fragen bewertet werden: Was fällt aus? Wie wird der Fehler erkannt? Welche Funktion bleibt verfügbar? Welche abhängigen Systeme werden dadurch belastet? Diese Sicht macht auch wirtschaftliche Folgen sichtbar. Eine größere Edge-Redundanz kann ihren Nutzen verlieren, wenn ein gemeinsamer Ursprung zum Engpass wird. Umgekehrt kann eine zentral betriebene Edge den Aufwand für Schutz, Routing und Failover über mehrere Backend-Umgebungen hinweg reduzieren.\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-Clustern\u003c/a\u003e\n und veröffentlicht sie über mehrere Edge-PoPs. Fällt ein PoP vollständig aus, kann Anycast den Traffic zu anderen erreichbaren PoPs führen. Die Anwendung bleibt verfügbar, wenn die verbleibende Edge-Kapazität, die Backend-Anbindung und die Health Checks funktionieren.\u003c/p\u003e\n\u003cp\u003eAnders sieht es bei einer Störung des gemeinsamen Transitpfads zu beiden Clustern aus. Dann sind die PoPs zwar erreichbar, können aber keine erfolgreichen Backend-Verbindungen herstellen. Ein gutes Runbook behandelt deshalb beide Fälle getrennt: Beim PoP-Ausfall wird die Edge-Verteilung geprüft; beim Backend- oder Netzwerkausfall werden Ursprungserreichbarkeit, Failover-Ziele und deren Kapazität bewertet. Die Fehlergrenze liegt nicht dort, wo der erste Alarm erscheint.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"ist-jeder-pop-eine-eigene-failure-domain\"\u003eIst jeder PoP eine eigene Failure Domain?\u003c/h3\u003e\n\u003cp\u003eNein. Ein PoP ist nur dann eine unabhängige Fehlergrenze, wenn gemeinsame Abhängigkeiten wie Netzwerk, Routing, Stromversorgung und zentrale Dienste ausreichend entkoppelt sind.\u003c/p\u003e\n\u003ch3 id=\"welche-rolle-spielt-dns-bei-der-ausfallanalyse\"\u003eWelche Rolle spielt DNS bei der Ausfallanalyse?\u003c/h3\u003e\n\u003cp\u003eDNS bestimmt, wie Clients den Einstiegspunkt auflösen. Anycast DNS und Multi-Provider-DNS können Abhängigkeiten verteilen, müssen aber gemeinsam mit Routing, Caching und Failover-Verhalten bewertet werden.\u003c/p\u003e\n\u003ch3 id=\"verhindert-backend-cloaking-backend-ausfälle\"\u003eVerhindert Backend Cloaking Backend-Ausfälle?\u003c/h3\u003e\n\u003cp\u003eNein. Backend Cloaking schützt die Ursprünge vor direkter öffentlicher Erreichbarkeit. Verfügbarkeit erfordert zusätzlich redundante Backends, funktionierende Health Checks und belastbare Abhängigkeiten.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eFailure Domains liefern die belastbarere Perspektive auf Verfügbarkeit als eine reine Komponenten- oder PoP-Zählung. Sie zeigen, welche Fehler isoliert werden können und wo gemeinsame Abhängigkeiten weiterhin bestehen. Die ayedo Edge Cloud verbindet dafür eine verteilte Multi-PoP-Architektur, Aktiv-Aktiv-Prinzip, eigenes Autonomous System und eigene Netzwerk-Infrastruktur mit Funktionen für Routing, Schutz und Backend-Failover. Ihr technischer Wert zeigt sich vor allem dann, wenn diese Ebenen gemeinsam analysiert und betrieben werden.\u003c/p\u003e\n", "summary": "\nTL;DR Eine Multi-PoP-Architektur reduziert Ausfälle nicht automatisch. Entscheidend ist, welche Komponenten, Leitungen, Routingpfade und Backends dieselbe Failure Domain teilen. Wer Fehlergrenzen statt Einzelkomponenten analysiert, erkennt gemeinsame Abhängigkeiten früher und kann Traffic, Schutzfunktionen und Failover gezielt entkoppeln.\nEinleitung Ein zusätzlicher Point of Presence erhöht die Verfügbarkeit nur dann, wenn ein Fehler nicht gleichzeitig mehrere Standorte oder zentrale Abhängigkeiten erreicht. Genau hier liegt ein häufiger Architekturfehler: Unternehmen zählen PoPs, Loadbalancer oder Backend-Instanzen, bewerten aber nicht, welche davon an dasselbe Netzwerk, dieselbe Routingentscheidung oder denselben Ursprung gekoppelt sind. Eine belastbare Ausfallanalyse beginnt deshalb nicht bei einzelnen Komponenten, sondern bei Failure Domains . Sie untersucht, welche Teile der Architektur gemeinsam ausfallen können, wie sich Fehler ausbreiten und welche Funktionsebene den Traffic noch übernehmen kann. Das betrifft die Edge selbst, die Netzwerkanbindung, DNS, Sicherheitsfunktionen und die Backends.\n", "image": "https://ayedo.de/failure-domains-in-verteilten-edge-architekturen.png", "date_published": "2026-09-04T22:19:00Z", "date_modified": "2026-09-04T22:19:00Z", "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}], "tags": ["security","cloud-native","hosting","kubernetes","digital-sovereignty"], "language": "de" },{ "id": "https://ayedo.de/posts/multi-pop-aktiv-aktiv-verfugbarkeit-richtig-planen/", "url": "https://ayedo.de/posts/multi-pop-aktiv-aktiv-verfugbarkeit-richtig-planen/", "title": "Multi-PoP-Aktiv-Aktiv: Verfügbarkeit richtig planen", "content_html": "\u003cp\u003e\u003cimg src=\"/posts/multi-pop-aktiv-aktiv-verfugbarkeit-richtig-planen/multi-pop-aktiv-aktiv-verfugbarkeit-richtig-planen.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eMulti-PoP-Aktiv-Aktiv erhöht die Verfügbarkeit nicht allein durch mehrere Standorte. Entscheidend sind konsistente Traffic-Verteilung, belastbare Health Checks, klar definierte Failover-Regeln und ausreichend dimensionierte Backends. Die ayedo Edge Cloud verbindet dafür Anycast, verteilte PoPs, Aktiv-Aktiv-Betrieb und Backend-Failover – ersetzt aber keine Kapazitäts- und Abhängigkeitsplanung.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eEine Multi-PoP-Aktiv-Aktiv-Architektur wird häufig mit hoher Verfügbarkeit gleichgesetzt. Das ist ein gefährlicher Kurzschluss: Mehrere aktive PoPs verteilen den Traffic, lösen aber weder überlastete Backends noch fehlerhafte Health Checks oder unklare Failover-Zustände. Verfügbarkeit entsteht erst durch das Zusammenspiel von Edge, Routing, Prüfmechanismen und Compute-Kapazität. Wer nur die Anzahl der PoPs betrachtet, plant die sichtbare Infrastruktur, nicht den tatsächlichen Service. Deshalb muss die Verfügbarkeitsplanung von der Anfrage bis zur Anwendung reichen – einschließlich Zustandsabhängigkeiten, Wiederanlaufverhalten und Kapazitätsreserven.\u003c/p\u003e\n\u003ch2 id=\"1-aktiv-aktiv-beginnt-mit-einer-klaren-traffic-verteilung\"\u003e1. Aktiv-Aktiv beginnt mit einer klaren Traffic-Verteilung\u003c/h2\u003e\n\u003cp\u003eIn einer Aktiv-Aktiv-Architektur sind mehrere PoPs gleichzeitig in der Lage, Anfragen zu verarbeiten. Bei Anycast wird eine IP-Adresse über mehrere Netzwerkstandorte angekündigt. Das Routing führt Clients typischerweise zu einem geeigneten Netzpfad, ohne dass die Anwendung selbst mehrere öffentliche Endpunkte verwalten muss. Für Layer-7-Traffic kann die Edge zusätzlich Routing- und Verteilungsentscheidungen auf Anwendungsebene treffen.\u003c/p\u003e\n\u003cp\u003eDiese Architektur reduziert die Abhängigkeit von einem einzelnen Standort, verteilt Last aber nicht automatisch gleichmäßig. Routingpfade, Client-Netze, TCP-Verbindungen und unterschiedliche Anfrageprofile beeinflussen die tatsächliche Verteilung. Auch langlebige Verbindungen können dazu führen, dass ein PoP stärker belastet bleibt als andere.\u003c/p\u003e\n\u003cp\u003eFür die Planung braucht es deshalb messbare Annahmen: Welche Traffic-Anteile werden je PoP erwartet? Wie verändert sich die Last beim Ausfall eines Standorts? Und welche Verteilung ist für die Backends zulässig? Anycast und die eigene Netzwerk-Infrastruktur der ayedo Edge Cloud schaffen die technische Basis für diese Verteilung. Die Kapazitätsplanung muss dennoch die reale Lastverteilung berücksichtigen, nicht nur die theoretische Gesamtleistung.\u003c/p\u003e\n\u003ch2 id=\"2-health-checks-müssen-den-richtigen-fehler-erkennen\"\u003e2. Health Checks müssen den richtigen Fehler erkennen\u003c/h2\u003e\n\u003cp\u003eHealth Checks sind die Grundlage jeder automatisierten Failover-Logik. Ein einfacher TCP-Check beantwortet lediglich, ob ein Port erreichbar ist. Ein HTTP-Check kann zusätzlich prüfen, ob ein Endpoint antwortet. Für die Verfügbarkeitsplanung ist jedoch entscheidend, ob der geprüfte Zustand tatsächlich etwas über die Nutzbarkeit des Dienstes aussagt.\u003c/p\u003e\n\u003cp\u003eEin Endpoint kann HTTP 200 liefern, obwohl eine abhängige Datenbank nicht verfügbar ist oder neue Transaktionen nicht verarbeitet werden können. Umgekehrt kann ein einzelner fehlerhafter Checkpunkt einen gesunden Service vorübergehend aus dem Traffic nehmen. Checks müssen daher zur Fehlerdomäne passen: Sie sollten relevante Anwendungspfade prüfen, aber keine unnötigen Abhängigkeiten einbeziehen, die zu Fehlentscheidungen führen.\u003c/p\u003e\n\u003cp\u003eWichtig sind außerdem Ausfall- und Wiederanlaufkriterien. Wie viele fehlgeschlagene Prüfungen lösen ein Failover aus? Wie schnell wird ein Backend wieder zugeschaltet? Gibt es Hysterese, damit instabile Systeme nicht ständig zwischen aktiv und inaktiv wechseln? Die ayedo Edge Cloud unterstützt Backend Health Checks und Failover. Die fachliche Definition eines aussagekräftigen Checks bleibt jedoch eine Aufgabe der Service- und Plattformverantwortlichen.\u003c/p\u003e\n\u003ch2 id=\"3-failover-verändert-die-lastverteilung-und-die-betriebsrisiken\"\u003e3. Failover verändert die Lastverteilung und die Betriebsrisiken\u003c/h2\u003e\n\u003cp\u003eEin Failover entfernt normalerweise keine Last, sondern verschiebt sie. Fällt ein PoP aus, müssen andere PoPs und die dahinterliegenden Backends zusätzliche Anfragen übernehmen. Wird ein Backend aus dem Pool genommen, verteilt sich dessen Traffic auf verbleibende Systeme. Ohne Reserve kann ein korrekt ausgelöstes Failover eine Überlastungskaskade auslösen.\u003c/p\u003e\n\u003cp\u003eDeshalb sollte die Planung mindestens zwei Zustände betrachten: den Normalbetrieb und den Fehlerbetrieb. Für jeden relevanten Ausfall – etwa ein nicht erreichbarer PoP, ein Backend-Pool oder ein kompletter Providerpfad – muss bekannt sein, welche Kapazität verfügbar bleibt. Dabei sind nicht nur Requests pro Sekunde relevant. TLS-Verbindungen, Antwortgrößen, Session-Zustände und rechenintensive Endpunkte verändern die tatsächliche Last.\u003c/p\u003e\n\u003cp\u003eAuch das Failback braucht Regeln. Ein zu frühes Zurückschalten kann Fehler erneut verteilen; ein zu spätes Zuschalten reduziert die verfügbare Kapazität. Automatisierung ist sinnvoll, wenn Zustände, Schwellenwerte und Verantwortlichkeiten dokumentiert sind. Ohne diese Definitionen wird Failover zu einer schwer nachvollziehbaren Betriebsentscheidung statt zu einem kontrollierten Mechanismus.\u003c/p\u003e\n\u003ch2 id=\"4-backend-kapazität-ist-teil-der-edge-verfügbarkeitsplanung\"\u003e4. Backend-Kapazität ist Teil der Edge-Verfügbarkeitsplanung\u003c/h2\u003e\n\u003cp\u003eDie Edge kann Traffic annehmen, schützen, terminieren und verteilen. Sie kann jedoch keine fehlende Verarbeitungskapazität im Backend ersetzen. Diese Trennung zwischen Edge und Compute ist für die Architektur entscheidend: Ein verfügbarer Edge-Service bedeutet nicht automatisch, dass die Anwendung hinter ihm ausreichend Kapazität besitzt.\u003c/p\u003e\n\u003cp\u003eBei mehreren aktiven PoPs müssen Backends entweder gemeinsam nutzbar oder eindeutig den jeweiligen Traffic-Pfaden zugeordnet sein. Gemeinsame Backends vereinfachen die Verteilung, erhöhen aber Anforderungen an Datenkonsistenz, Sessions und Netzwerkanbindung. Getrennte Backends reduzieren bestimmte Abhängigkeiten, können jedoch zu ungleichmäßiger Auslastung und komplexerem Failover führen.\u003c/p\u003e\n\u003cp\u003eIn die Planung gehören daher Basiskapazität, Spitzenlast, Ausfallreserve und Wiederanlaufkapazität. Ein Backend darf im Normalbetrieb nicht so stark ausgelastet sein, dass der Ausfall eines PoPs unmittelbar zur Überlast führt. Health Checks sollten zudem berücksichtigen, ob ein System noch ausreichend Kapazität besitzt – nicht nur, ob es formal erreichbar ist. Providerunabhängige Nutzung der ayedo Edge Cloud kann dabei helfen, Edge und Compute organisatorisch sowie infrastrukturell getrennt zu planen, ersetzt aber keine Abstimmung zwischen beiden Bereichen.\u003c/p\u003e\n\u003ch2 id=\"praxis--und-betriebsszenario\"\u003ePraxis- und Betriebsszenario\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt eine API hinter mehreren aktiven Edge-PoPs. Im Normalbetrieb werden die Anfragen verteilt; die Backends laufen mit bewusst eingeplanter Reserve. Fällt ein PoP aus, übernehmen die übrigen Standorte den Traffic. Gleichzeitig steigt die Last auf den Backends. Ein TCP-Health-Check würde möglicherweise weiterhin Erfolg melden, obwohl die Anwendung wegen erschöpfter Datenbankverbindungen kaum noch Anfragen verarbeitet.\u003c/p\u003e\n\u003cp\u003eEine belastbare Planung kombiniert deshalb einen anwendungsnahen Check mit definierten Schwellenwerten und prüft den Fehlerbetrieb unter kontrollierten Bedingungen. Das Team vergleicht dabei mindestens drei Szenarien: Normalbetrieb, Ausfall eines PoPs und Ausfall eines Backend-Pools. Erst wenn Traffic-Verteilung, Health Checks und Backend-Kapazität in allen Szenarien zusammenpassen, ist Aktiv-Aktiv operativ belastbar.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"ist-anycast-allein-eine-aktiv-aktiv-architektur\"\u003eIst Anycast allein eine Aktiv-Aktiv-Architektur?\u003c/h3\u003e\n\u003cp\u003eNein. Anycast verteilt Erreichbarkeit über mehrere Netzwerkstandorte. Aktiv-Aktiv erfordert zusätzlich mehrere tatsächlich nutzbare Verarbeitungspfade, geeignete Health Checks, Failover-Regeln und ausreichende Backend-Kapazität.\u003c/p\u003e\n\u003ch3 id=\"muss-jedes-backend-an-jedem-pop-erreichbar-sein\"\u003eMuss jedes Backend an jedem PoP erreichbar sein?\u003c/h3\u003e\n\u003cp\u003eNicht zwingend. Gemeinsame Backends vereinfachen die Verteilung, lokale oder getrennte Backends können Abhängigkeiten reduzieren. Entscheidend sind konsistente Routing-, Zustands- und Failover-Regeln.\u003c/p\u003e\n\u003ch3 id=\"wie-wird-ein-failover-sinnvoll-getestet\"\u003eWie wird ein Failover sinnvoll getestet?\u003c/h3\u003e\n\u003cp\u003eDurch kontrollierte Ausfälle einzelner PoPs, Backend-Pools und Abhängigkeiten. Gemessen werden Traffic-Verteilung, Umschaltzeit, Fehlerraten, Backend-Auslastung und das Verhalten beim Failback.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eMulti-PoP-Aktiv-Aktiv ist keine reine Standortentscheidung, sondern ein Zusammenspiel aus Routing, Prüfmechanismen, Failover und Compute-Kapazität. Die zentrale Frage lautet nicht, wie viele PoPs vorhanden sind, sondern ob der verbleibende Pfad einen Fehlerbetrieb zuverlässig tragen kann. Die ayedo Edge Cloud bietet dafür Anycast, verteilte Aktiv-Aktiv-Infrastruktur und Backend-Failover. Die belastbare Verfügbarkeit entsteht jedoch erst durch eine darauf abgestimmte Architektur- und Betriebsplanung.\u003c/p\u003e\n", "summary": "\nTL;DR Multi-PoP-Aktiv-Aktiv erhöht die Verfügbarkeit nicht allein durch mehrere Standorte. Entscheidend sind konsistente Traffic-Verteilung, belastbare Health Checks, klar definierte Failover-Regeln und ausreichend dimensionierte Backends. Die ayedo Edge Cloud verbindet dafür Anycast, verteilte PoPs, Aktiv-Aktiv-Betrieb und Backend-Failover – ersetzt aber keine Kapazitäts- und Abhängigkeitsplanung.\nEinleitung Eine Multi-PoP-Aktiv-Aktiv-Architektur wird häufig mit hoher Verfügbarkeit gleichgesetzt. Das ist ein gefährlicher Kurzschluss: Mehrere aktive PoPs verteilen den Traffic, lösen aber weder überlastete Backends noch fehlerhafte Health Checks oder unklare Failover-Zustände. Verfügbarkeit entsteht erst durch das Zusammenspiel von Edge, Routing, Prüfmechanismen und Compute-Kapazität. Wer nur die Anzahl der PoPs betrachtet, plant die sichtbare Infrastruktur, nicht den tatsächlichen Service. Deshalb muss die Verfügbarkeitsplanung von der Anfrage bis zur Anwendung reichen – einschließlich Zustandsabhängigkeiten, Wiederanlaufverhalten und Kapazitätsreserven.\n", "image": "https://ayedo.de/multi-pop-aktiv-aktiv-verfugbarkeit-richtig-planen.png", "date_published": "2026-09-04T22:19:00Z", "date_modified": "2026-09-04T22:19:00Z", "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/primar-sekundar-oder-aktiv-aktiv-an-der-edge/", "url": "https://ayedo.de/posts/primar-sekundar-oder-aktiv-aktiv-an-der-edge/", "title": "Primär, Sekundär oder Aktiv-Aktiv an der Edge?", "content_html": "\u003cp\u003e\u003cimg src=\"/posts/primar-sekundar-oder-aktiv-aktiv-an-der-edge/primar-sekundar-oder-aktiv-aktiv-an-der-edge.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eBeim öffentlichen Traffic-Eingang ist die Wahl zwischen Primär-Sekundär, Cold-Standby und Aktiv-Aktiv keine reine Verfügbarkeitsfrage. Entscheidend sind Failover-Zeit, Auslastung, Betriebsaufwand, Zustandsmanagement und die Beherrschbarkeit von Fehlerfällen. Aktiv-Aktiv nutzt Ressourcen besser, verlangt aber eine konsistente Architektur und belastbare Betriebsprozesse.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eEin Standby-System, das im Normalbetrieb keinen Traffic verarbeitet, ist nicht automatisch die sicherste Architektur. Es reduziert zwar die Komplexität im Regelbetrieb, bringt aber eigene Risiken mit: unbekannte Fehler im Reservepfad, veraltete Konfigurationen und ein Failover, das erst unter Störung validiert wird. Für den öffentlichen Traffic-Eingang muss deshalb getrennt betrachtet werden, wie Routing, Zustandswechsel, Kapazität und Betrieb zusammenspielen. Ein Primär-Sekundär-Modell kann für bestimmte Anforderungen sinnvoll sein. Eine Cold-Standby-Architektur passt zu anderen Randbedingungen. Aktiv-Aktiv bietet eine andere Balance zwischen Auslastung und Resilienz. Die richtige Entscheidung hängt nicht von einem pauschalen Architekturideal ab.\u003c/p\u003e\n\u003ch2 id=\"1-primär-sekundär-klare-rollen-kontrollierter-failover\"\u003e1. Primär-Sekundär: klare Rollen, kontrollierter Failover\u003c/h2\u003e\n\u003cp\u003eIm Primär-Sekundär-Modell verarbeitet eine aktive Instanz den regulären Traffic. Die sekundäre Instanz bleibt verfügbar, übernimmt aber erst nach einem erkannten Fehler. Diese klare Rollenverteilung vereinfacht Konfiguration, Fehlersuche und Zuständigkeiten. Insbesondere wenn Anwendungen oder Netzwerkpfade nicht problemlos parallel betrieben werden können, kann Primär-Sekundär eine pragmatische Lösung sein.\u003c/p\u003e\n\u003cp\u003eDer Preis liegt in der ungenutzten Kapazität und im Failover-Risiko. Die sekundäre Umgebung muss regelmäßig mit Konfigurationen, Zertifikaten, Routing-Informationen und Sicherheitsregeln synchronisiert werden. Andernfalls existiert zwar technisch ein Reservepfad, aber kein verlässlich gleichwertiger. Zusätzlich muss definiert sein, wer den Wechsel auslöst, wie DNS- oder Routing-Änderungen propagiert werden und wie ein Rückwechsel erfolgt. Ein Primär-Sekundär-Modell ist daher nur dann robust, wenn Failover-Strategie und Rückführung als wiederholbare Betriebsprozesse behandelt werden.\u003c/p\u003e\n\u003ch2 id=\"2-cold-standby-geringe-laufende-kosten-hohe-umschaltabhängigkeit\"\u003e2. Cold-Standby: geringe laufende Kosten, hohe Umschaltabhängigkeit\u003c/h2\u003e\n\u003cp\u003eBei Cold Standby ist die Reserve nicht oder nur eingeschränkt aktiv. Ressourcen werden erst im Störungsfall gestartet, hochskaliert oder in den Traffic-Pfad gebracht. Das kann wirtschaftlich attraktiv sein, wenn Ausfälle selten sind und die Anforderungen an Wiederanlaufzeit begrenzt bleiben. Auch für Systeme mit hohen Kapazitätskosten kann dieses Modell nachvollziehbar sein.\u003c/p\u003e\n\u003cp\u003eFür den öffentlichen Eingang ist Cold Standby jedoch besonders kritisch. Der Ausfall umfasst nicht nur eine einzelne Komponente, sondern potenziell Bereitstellung, Konfiguration, Routing, TLS-Terminierung, Sicherheitsfunktionen und Backend-Erreichbarkeit. Jeder zusätzliche Aktivierungsschritt verlängert die Wiederherstellung und vergrößert die Zahl möglicher Fehlerquellen. Außerdem wird die Reserve im Regelbetrieb nicht vollständig belastet. Defekte oder veraltete Abhängigkeiten bleiben dadurch leichter unentdeckt. Cold Standby eignet sich deshalb vor allem dort, wo ein längerer Failover toleriert, der Aktivierungsprozess automatisiert und regelmäßig getestet werden kann.\u003c/p\u003e\n\u003ch2 id=\"3-aktiv-aktiv-auslastung-und-resilienz-gemeinsam-planen\"\u003e3. Aktiv-Aktiv: Auslastung und Resilienz gemeinsam planen\u003c/h2\u003e\n\u003cp\u003eAktiv-Aktiv bedeutet, dass mehrere Edge-Pfade gleichzeitig produktiven Traffic verarbeiten. Fällt ein Pfad aus, kann der verbleibende Teil weiterarbeiten. Im Normalbetrieb wird die vorhandene Kapazität genutzt, wodurch Investitionen in Reserve-Systeme wirtschaftlich besser ausgelastet werden. Bei verteilten Edge-Architekturen kann Anycast den Traffic an erreichbare Standorte oder Netzwerkpunkte lenken, während Health Checks und Routing-Logik die Erreichbarkeit der Backends berücksichtigen.\u003c/p\u003e\n\u003cp\u003eAktiv-Aktiv ist allerdings kein automatischer Sicherheitsgewinn. Konfigurationen müssen konsistent verteilt, Zertifikate und Policies synchron gehalten und Zustände korrekt behandelt werden. Stateful-Anwendungen, Session-Bindungen oder asymmetrische Netzwerkpfade können die Architektur erschweren. Zudem müssen Überlastszenarien betrachtet werden: Wenn ein Teil ausfällt, muss die verbleibende Kapazität den zusätzlichen Traffic aufnehmen können. Aktiv-Aktiv verlagert den Aufwand also von der manuellen Umschaltung in Design, Automatisierung, Monitoring und Kapazitätsplanung.\u003c/p\u003e\n\u003ch2 id=\"4-entscheidungskriterien-für-den-öffentlichen-traffic-eingang\"\u003e4. Entscheidungskriterien für den öffentlichen Traffic-Eingang\u003c/h2\u003e\n\u003cp\u003eDie zentrale Frage lautet nicht „Aktiv-Aktiv versus Aktiv-Passiv?“, sondern: Welche Fehler können auftreten, wie schnell muss der Traffic weiterlaufen und welche Betriebsprozesse sind beherrschbar? Relevante Kriterien sind Recovery Time Objective, erwartete Ausfallbilder, Kapazitätsreserven, Konfigurationskonsistenz und die Möglichkeit, Failover regelmäßig zu testen. Auch die Trennung von Edge und Compute ist wichtig: Ein aktiver Edge-Pfad kann den Traffic weiterhin annehmen, obwohl ein einzelnes Backend ausgefallen ist. Backend Health Checks und Failover sind deshalb nicht dasselbe wie der Wechsel zwischen zwei Edge-Installationen.\u003c/p\u003e\n\u003cp\u003eFür Unternehmen mit mehreren Providern oder \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n-Clustern gewinnt außerdem die Entkopplung an Bedeutung. Die Edge sollte den öffentlichen Eingang, TLS-Terminierung, Schutz und Verteilung unabhängig vom Ort der Workloads steuern können. Die ayedo Edge Cloud ist dafür als verteilte Multi-PoP-Plattform mit eigenem Autonomous System und Aktiv-Aktiv-Prinzip ausgelegt. Sie kann Traffic zu ayedo Managed \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n ebenso wie zu eigenen oder extern betriebenen \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n-Clustern führen. Damit wird das Betriebsmodell der Edge nicht an einen einzelnen Compute-Standort gebunden.\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. Im Primär-Sekundär-Modell führt der normale Traffic ausschließlich zum ersten Cluster. Der zweite Cluster muss synchron gehalten und im Störungsfall über Routing oder DNS aktiviert werden. Bei Cold Standby kommen zusätzlich Start- und Bereitstellungszeiten hinzu.\u003c/p\u003e\n\u003cp\u003eIn einer Aktiv-Aktiv-Architektur nehmen beide Pfade Traffic an. Health Checks entfernen nicht erreichbare Backends aus der Verteilung, während die Edge den öffentlichen Zugang und die Schutzfunktionen zentral hält. Dafür müssen beide Cluster dieselben API-Verträge, Sicherheitsregeln und Kapazitätsannahmen erfüllen. Der Vergleich zeigt: Aktiv-Aktiv reduziert Umschaltabhängigkeiten, erhöht aber die Anforderungen an Konsistenz und Betrieb.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"ist-aktiv-aktiv-immer-verfügbarer-als-primär-sekundär\"\u003eIst Aktiv-Aktiv immer verfügbarer als Primär-Sekundär?\u003c/h3\u003e\n\u003cp\u003eNein. Aktiv-Aktiv reduziert bestimmte Failover-Abhängigkeiten, kann aber durch inkonsistente Konfigurationen oder unzureichende Restkapazität selbst ausfallen. Entscheidend ist die Qualität der Betriebsprozesse.\u003c/p\u003e\n\u003ch3 id=\"wann-ist-cold-standby-vertretbar\"\u003eWann ist Cold Standby vertretbar?\u003c/h3\u003e\n\u003cp\u003eWenn längere Wiederanlaufzeiten akzeptiert werden, der Aktivierungsprozess automatisiert ist und die Reserve regelmäßig getestet wird. Für zeitkritische öffentliche APIs ist das Modell häufig zu träge.\u003c/p\u003e\n\u003ch3 id=\"muss-aktiv-aktiv-auch-für-die-backends-gelten\"\u003eMuss Aktiv-Aktiv auch für die Backends gelten?\u003c/h3\u003e\n\u003cp\u003eNein. Edge und Compute können unterschiedlich betrieben werden. Die Edge kann aktiv redundant arbeiten, während Backends über Health Checks priorisiert, verteilt oder im Fehlerfall aus dem Traffic-Pfad genommen werden.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eDie Wahl des Betriebsmodells ist eine Entscheidung über Fehlerverhalten, Kapazitätsnutzung und organisatorische Disziplin. Primär-Sekundär schafft klare Rollen, Cold Standby senkt laufende Reservekosten, Aktiv-Aktiv reduziert Umschaltabhängigkeiten und nutzt Infrastruktur kontinuierlich. Für den öffentlichen Traffic-Eingang ist entscheidend, ob Routing, Schutz, TLS, Health Checks und Backend-Anbindung als zusammenhängender Prozess betrieben werden können. Die ayedo Edge Cloud ordnet diese Aufgaben in einer eigenen, verteilten Aktiv-Aktiv-Edge ein, ohne die Wahl der Compute-Plattform vorzugeben.\u003c/p\u003e\n", "summary": "\nTL;DR Beim öffentlichen Traffic-Eingang ist die Wahl zwischen Primär-Sekundär, Cold-Standby und Aktiv-Aktiv keine reine Verfügbarkeitsfrage. Entscheidend sind Failover-Zeit, Auslastung, Betriebsaufwand, Zustandsmanagement und die Beherrschbarkeit von Fehlerfällen. Aktiv-Aktiv nutzt Ressourcen besser, verlangt aber eine konsistente Architektur und belastbare Betriebsprozesse.\nEinleitung Ein Standby-System, das im Normalbetrieb keinen Traffic verarbeitet, ist nicht automatisch die sicherste Architektur. Es reduziert zwar die Komplexität im Regelbetrieb, bringt aber eigene Risiken mit: unbekannte Fehler im Reservepfad, veraltete Konfigurationen und ein Failover, das erst unter Störung validiert wird. Für den öffentlichen Traffic-Eingang muss deshalb getrennt betrachtet werden, wie Routing, Zustandswechsel, Kapazität und Betrieb zusammenspielen. Ein Primär-Sekundär-Modell kann für bestimmte Anforderungen sinnvoll sein. Eine Cold-Standby-Architektur passt zu anderen Randbedingungen. Aktiv-Aktiv bietet eine andere Balance zwischen Auslastung und Resilienz. Die richtige Entscheidung hängt nicht von einem pauschalen Architekturideal ab.\n", "image": "https://ayedo.de/primar-sekundar-oder-aktiv-aktiv-an-der-edge.png", "date_published": "2026-09-04T22:19:00Z", "date_modified": "2026-09-04T22:19:00Z", "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}], "tags": ["security","operations","cloud-native","kubernetes","digital-sovereignty"], "language": "de" },{ "id": "https://ayedo.de/posts/aktiv-aktiv-statt-cold-standby-edge-ha-erklart/", "url": "https://ayedo.de/posts/aktiv-aktiv-statt-cold-standby-edge-ha-erklart/", "title": "Aktiv-Aktiv statt Cold Standby: Edge-HA erklärt", "content_html": "\u003cp\u003e\u003cimg src=\"/posts/aktiv-aktiv-statt-cold-standby-edge-ha-erklart/aktiv-aktiv-statt-cold-standby-edge-ha-erklart.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eBeim Aktiv-Aktiv-Betrieb verarbeiten mehrere Edge-Instanzen dauerhaft produktiven Traffic. Fällt ein Standort oder Verarbeitungspfad aus, wird der Traffic auf verbleibende Ressourcen verteilt. Cold Standby aktiviert eine Reserve erst im Fehlerfall und muss deshalb Umschaltung, Kapazität und Betriebszustand zusätzlich beherrschen.\u003c/p\u003e\n\u003cp\u003eEin Cold-Standby-Modell wirkt auf den ersten Blick effizient: Eine Reserve-Infrastruktur steht bereit, verursacht aber im Normalbetrieb möglichst wenig Aufwand. Für die Hochverfügbarkeit am öffentlichen Anwendungseingang entsteht dadurch ein zusätzlicher Betriebsprozess. Die Reserve muss im Fehlerfall erreichbar, ausreichend dimensioniert, korrekt konfiguriert und schnell aktivierbar sein. Gleichzeitig muss das Routing den Ausfall erkennen und den Traffic umleiten.\u003c/p\u003e\n\u003cp\u003eAktiv-Aktiv verfolgt einen anderen Ansatz. Mehrere Edge-Ressourcen sind gleichzeitig produktiv und teilen sich den eingehenden Traffic. Hochverfügbarkeit entsteht nicht durch eine ungenutzte Ersatzumgebung, sondern durch verteilte Verarbeitungskapazität und die Fähigkeit, den Traffic bei Ausfällen neu zu verteilen.\u003c/p\u003e\n\u003ch2 id=\"aktiv-aktiv-und-cold-standby-im-architekturvergleich\"\u003eAktiv-Aktiv und Cold Standby im Architekturvergleich\u003c/h2\u003e\n\u003cp\u003eBei Cold Standby verarbeitet eine primäre Umgebung den Traffic. Die Reserve ist während des Normalbetriebs entweder abgeschaltet oder nicht in den aktiven Datenpfad eingebunden. Ein Failover muss daher mehrere Schritte koordinieren: Fehlererkennung, Aktivierung der Reserve, Aktualisierung des Routings und gegebenenfalls das Bereitstellen aktueller Konfigurationen.\u003c/p\u003e\n\u003cp\u003eIm Aktiv-Aktiv-Betrieb sind mehrere Edge-Ressourcen bereits Teil der produktiven Architektur. Anycast kann Anfragen an verfügbare Edge-Standorte lenken, während Loadbalancing die Verteilung innerhalb der Plattform übernimmt. Die einzelnen Ressourcen sind nicht lediglich Ersatz, sondern tragen kontinuierlich zur Verarbeitung bei.\u003c/p\u003e\n\u003cp\u003eDer Unterschied liegt damit nicht nur in der Umschaltlogik. Cold Standby verschiebt einen Teil des Risikos in den Fehlerfall. Aktiv-Aktiv verteilt den Betriebsaufwand über den Normalbetrieb und reduziert die Abhängigkeit von einer einzelnen Aktivierungsprozedur. Dafür müssen Zustände, Konfigurationen und Kapazitätsgrenzen über die aktiven Pfade hinweg konsistent betrieben werden.\u003c/p\u003e\n\u003ch2 id=\"traffic-verteilung-und-failover-an-der-edge\"\u003eTraffic-Verteilung und Failover an der Edge\u003c/h2\u003e\n\u003cp\u003eEdge-Hochverfügbarkeit beginnt mit der Frage, wie ein Ausfall erkannt wird. Backend Health Checks prüfen, ob nachgelagerte Anwendungen erreichbar und funktionsfähig sind. Für die Edge selbst sind verfügbare Verarbeitungspfade, Routing-Informationen und die Erreichbarkeit der jeweiligen Ressourcen entscheidend. Fällt ein Pfad aus, darf der Traffic nicht weiter dorthin verteilt werden.\u003c/p\u003e\n\u003cp\u003eIn einer Anycast-Architektur kündigen mehrere Edge-Standorte dieselbe öffentliche Erreichbarkeit an. Das Routing kann Anfragen dadurch zu einem anderen verfügbaren Standort führen, wenn ein Standort oder ein Netzwerkpfad nicht mehr erreichbar ist. Innerhalb der Edge übernehmen Layer-4- und Layer-7-Loadbalancing die weitere Verteilung.\u003c/p\u003e\n\u003cp\u003eCold Standby benötigt dagegen eine explizite Aktivierung oder Umschaltung. Je nach Mechanismus können DNS-TTLs, Routing-Konvergenz oder die Initialisierung der Reserve die Wiederherstellungszeit beeinflussen. Failover ist dann ein Ablauf mit mehreren Abhängigkeiten. Aktiv-Aktiv beseitigt nicht jeden Fehler, verkürzt aber die Strecke zwischen Fehlererkennung und Weiterverarbeitung, weil die Zielressourcen bereits aktiv sind.\u003c/p\u003e\n\u003ch2 id=\"auslastung-kapazität-und-betriebskosten\"\u003eAuslastung, Kapazität und Betriebskosten\u003c/h2\u003e\n\u003cp\u003eDer wichtigste wirtschaftliche Unterschied betrifft die Nutzung der bereitgestellten Ressourcen. Im Cold-Standby-Modell bleibt ein Teil der Infrastruktur im Normalbetrieb ungenutzt. Das kann sinnvoll sein, wenn die Reserve nur für seltene Ausfälle benötigt wird. Gleichzeitig bezahlt das Unternehmen für Redundanz, ohne aus ihr laufenden Durchsatz zu gewinnen.\u003c/p\u003e\n\u003cp\u003eAktiv-Aktiv verteilt den produktiven Traffic auf mehrere Ressourcen. Dadurch wird vorhandene Kapazität besser genutzt, und Lastspitzen können sich auf mehrere Verarbeitungspfade verteilen. Die Dimensionierung muss jedoch nicht nur den Normalbetrieb abdecken. Fällt ein Standort aus, müssen die verbleibenden Ressourcen den zusätzlichen Traffic zumindest innerhalb der geplanten Grenzen verarbeiten können.\u003c/p\u003e\n\u003cp\u003eDas verändert auch die Betriebsaufgaben. Statt eine Reserve regelmäßig auf Funktionsfähigkeit zu testen, muss ein Aktiv-Aktiv-System vor allem Verteilung, Kapazitätsreserven, Health Checks und Fehlerszenarien überwachen. Traffic- und Usage-Statistiken unterstützen dabei, reale Lastverteilungen zu bewerten. Der Betriebsaufwand verschwindet nicht; er verlagert sich von der Aktivierung einer Reserve zur kontinuierlichen Kontrolle eines verteilten Systems.\u003c/p\u003e\n\u003ch2 id=\"sicherheits--und-architekturfolgen-des-aktiv-aktiv-betriebs\"\u003eSicherheits- und Architekturfolgen des Aktiv-Aktiv-Betriebs\u003c/h2\u003e\n\u003cp\u003eDie Edge ist der öffentliche Eingang vor Anwendungen und APIs. Deshalb müssen Sicherheitsfunktionen während eines Failovers nicht erst nachgeladen oder neu aktiviert werden. TLS Termination, Web Application Firewall und DDoS Protection sollten an den aktiven Edge-Pfaden konsistent verfügbar sein. Andernfalls kann die Umschaltung zwar technisch funktionieren, aber Sicherheits- oder Routing-Eigenschaften verändern.\u003c/p\u003e\n\u003cp\u003eBackend Cloaking begrenzt zusätzlich die direkte Sichtbarkeit der eigentlichen Backends. Der Traffic wird an der Edge verarbeitet und anschließend über definierte Pfade weitergeleitet. Für \u003ca href=\"https://www.kubernetes.io/\" target=\"_blank\" rel=\"noopener\"\u003eKubernetes\u003c/a\u003e\n kann die Edge Cloud dabei mit ayedo Managed \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n oder mit eigenen Clustern und Clustern anderer Provider verbunden werden. Die Hochverfügbarkeit der Edge bleibt somit vom konkreten Compute-Provider getrennt.\u003c/p\u003e\n\u003cp\u003eDie ayedo Edge Cloud verbindet dafür Anycast, eine eigene Netzwerk-Infrastruktur, ein eigenes Autonomous System und eine verteilte Multi-PoP-Architektur mit einem Aktiv-Aktiv-Prinzip. Das ist kein Synonym für eine bestimmte \u003ca href=\"https://www.kubernetes.io/\" target=\"_blank\" rel=\"noopener\"\u003eKubernetes\u003c/a\u003e\n -Bereitstellung. Die Edge übernimmt öffentlichen Traffic-Eingang, Schutz, Termination und Verteilung; die Compute-Infrastruktur führt die Workloads aus. Diese Trennung verhindert, dass ein einzelner Cluster oder Provider automatisch zum Maßstab für die Edge-Hochverfügbarkeit wird.\u003c/p\u003e\n\u003ch2 id=\"praxisszenario-ausfall-eines-edge-standorts\"\u003ePraxisszenario: Ausfall eines Edge-Standorts\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt eine API auf \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n, wobei die Cluster bei einem externen Provider laufen. Der öffentliche Endpunkt liegt an der Edge. Im Cold-Standby-Modell würde ein primärer Edge-Pfad den Traffic verarbeiten. Bei dessen Ausfall müsste eine Reserve aktiviert und anschließend über DNS oder Routing erreichbar gemacht werden. Die Wiederherstellung hängt damit von mehreren zeitlich aufeinanderfolgenden Schritten ab.\u003c/p\u003e\n\u003cp\u003eIm Aktiv-Aktiv-Modell verarbeiten mehrere Edge-Standorte bereits produktive Anfragen. Fällt einer aus, wird der Traffic auf verfügbare Standorte verteilt. Die Backends bleiben dabei unverändert erreichbar; nur der öffentliche Verarbeitungspfad ändert sich. Entscheidend ist, dass die verbleibenden Ressourcen ausreichend Kapazität besitzen und die Sicherheits- sowie Routing-Konfigurationen konsistent sind.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"ist-aktiv-aktiv-automatisch-ausfallsicher\"\u003eIst Aktiv-Aktiv automatisch ausfallsicher?\u003c/h3\u003e\n\u003cp\u003eNein. Aktiv-Aktiv reduziert die Abhängigkeit von einer einzelnen Ressource. Es benötigt weiterhin korrekte Health Checks, ausreichende Restkapazität, konsistente Konfigurationen und getestete Fehlerannahmen.\u003c/p\u003e\n\u003ch3 id=\"was-ist-der-zentrale-nachteil-von-cold-standby\"\u003eWas ist der zentrale Nachteil von Cold Standby?\u003c/h3\u003e\n\u003cp\u003eDie Reserve muss im Fehlerfall erst aktiviert und erreichbar gemacht werden. Dadurch entstehen zusätzliche Abhängigkeiten bei Routing, Initialisierung, Konfigurationsstand und Wiederanlauf.\u003c/p\u003e\n\u003ch3 id=\"muss-aktiv-aktiv-auf-demselben-provider-betrieben-werden\"\u003eMuss Aktiv-Aktiv auf demselben Provider betrieben werden?\u003c/h3\u003e\n\u003cp\u003eNein. Die Edge kann unabhängig von der Compute-Plattform betrieben werden. \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n -Cluster können bei ayedo, im eigenen Rechenzentrum oder bei anderen Providern laufen.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eAktiv-Aktiv ist kein reines Verteilungsmodell, sondern eine Betriebsentscheidung: Redundante Edge-Ressourcen werden dauerhaft genutzt, überwacht und in die Kapazitätsplanung einbezogen. Cold Standby kann Ressourcen im Normalbetrieb schonen, verlagert aber wesentliche Risiken in den Fehlerfall. Für Unternehmen mit verteilten Anwendungen und APIs ist deshalb entscheidend, Edge und Compute getrennt zu betrachten. Die ayedo Edge Cloud setzt diese Trennung mit einer verteilten Aktiv-Aktiv-Architektur, Anycast und eigenem Netzwerkbetrieb um.\u003c/p\u003e\n", "summary": "\nTL;DR Beim Aktiv-Aktiv-Betrieb verarbeiten mehrere Edge-Instanzen dauerhaft produktiven Traffic. Fällt ein Standort oder Verarbeitungspfad aus, wird der Traffic auf verbleibende Ressourcen verteilt. Cold Standby aktiviert eine Reserve erst im Fehlerfall und muss deshalb Umschaltung, Kapazität und Betriebszustand zusätzlich beherrschen.\nEin Cold-Standby-Modell wirkt auf den ersten Blick effizient: Eine Reserve-Infrastruktur steht bereit, verursacht aber im Normalbetrieb möglichst wenig Aufwand. Für die Hochverfügbarkeit am öffentlichen Anwendungseingang entsteht dadurch ein zusätzlicher Betriebsprozess. Die Reserve muss im Fehlerfall erreichbar, ausreichend dimensioniert, korrekt konfiguriert und schnell aktivierbar sein. Gleichzeitig muss das Routing den Ausfall erkennen und den Traffic umleiten.\n", "image": "https://ayedo.de/aktiv-aktiv-statt-cold-standby-edge-ha-erklart.png", "date_published": "2026-09-04T22:18:59Z", "date_modified": "2026-09-04T22:18:59Z", "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}], "tags": ["operations","cloud-native","kubernetes","digital-sovereignty","software-delivery"], "language": "de" },{ "id": "https://ayedo.de/posts/anycast-und-routing-failover-an-der-edge-verstehen/", "url": "https://ayedo.de/posts/anycast-und-routing-failover-an-der-edge-verstehen/", "title": "Anycast und Routing: Failover an der Edge verstehen", "content_html": "\u003cp\u003e\u003cimg src=\"/posts/anycast-und-routing-failover-an-der-edge-verstehen/anycast-und-routing-failover-an-der-edge-verstehen.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eAnycast Failover verlagert Traffic nicht automatisch auf ein gesundes Backend. Anycast Routing entscheidet zunächst, welche Edge-Struktur eine Anfrage erreicht. Backend Health Checks bewerten anschließend die Erreichbarkeit nachgelagerter Dienste. Erst Zusammenspiel und klare Zuständigkeiten ergeben ein belastbares Failover-Modell.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eEin häufiger Architekturfehler besteht darin, Anycast mit vollständigem Failover gleichzusetzen. Anycast sorgt zunächst dafür, dass eine IP-Adresse von mehreren Netzwerkknoten erreichbar ist und Routingentscheidungen den Traffic zu einer verfügbaren Edge-Struktur lenken können. Damit ist jedoch noch nicht entschieden, ob das eigentliche Backend gesund ist oder eine Anwendung ihren Dienst korrekt erbringt. Für den Betrieb müssen deshalb drei Ebenen getrennt betrachtet werden: das Routing zum öffentlichen Eingang, die Verfügbarkeit der Edge-Struktur und die Erreichbarkeit der nachgelagerten Services. Genau an dieser Abgrenzung entscheidet sich, ob Failover kontrollierbar oder nur scheinbar vorhanden ist.\u003c/p\u003e\n\u003ch2 id=\"1-anycast-bestimmt-den-öffentlichen-eingang\"\u003e1. Anycast bestimmt den öffentlichen Eingang\u003c/h2\u003e\n\u003cp\u003eBei Anycast wird dieselbe IP-Adresse aus mehreren geografisch oder netzwerktopologisch verteilten Strukturen angekündigt. Das Internet wählt anhand seiner Routinglogik einen geeigneten Pfad. Fällt eine Edge-Struktur aus oder wird ihre Route zurückgezogen, können andere Strukturen den Traffic übernehmen. Der Client verwendet dabei weiterhin denselben öffentlichen Endpunkt.\u003c/p\u003e\n\u003cp\u003eFür den öffentlichen Traffic-Eingang reduziert das die Abhängigkeit von einem einzelnen Standort oder Netzwerkpfad. Die ayedo Edge Cloud nutzt dafür Anycast-basierte Layer-4- und Layer-7-Funktionen, eine eigene Netzwerk-Infrastruktur und ein eigenes Autonomous System. Ihre verteilte Multi-PoP-Architektur ist auf Aktiv-Aktiv-Betrieb ausgelegt. Routing-Failover bedeutet dabei nicht, dass jede einzelne Verbindung nahtlos fortgesetzt wird. Bereits etablierte Sessions können bei einem Ausfall abbrechen und müssen je nach Protokoll oder Anwendung neu aufgebaut werden.\u003c/p\u003e\n\u003ch2 id=\"2-routing-failover-ist-kein-backend-failover\"\u003e2. Routing-Failover ist kein Backend-Failover\u003c/h2\u003e\n\u003cp\u003eRouting beantwortet die Frage: Welche Edge-Struktur soll eine Anfrage erreichen? Backend Health Checks beantworten eine andere Frage: Ist der nachgelagerte Dienst erreichbar und für Traffic geeignet? Diese Prüfung kann beispielsweise die Verbindung zu einem Zielsystem oder einen definierten Dienststatus bewerten. Beide Mechanismen liegen auf unterschiedlichen Ebenen und haben unterschiedliche Fehlerbilder.\u003c/p\u003e\n\u003cp\u003eEin gesund erreichbarer Edge-Knoten kann weiterhin ein nicht verfügbares Backend ansprechen. Umgekehrt kann ein Backend gesund sein, während ein Netzwerkpfad oder eine Edge-Struktur ausfällt. Die ayedo Edge Cloud verbindet Anycast Routing mit Backend Health Checks und Failover-Mechanismen. Dadurch lässt sich der Traffic zunächst an eine verfügbare Edge-Struktur führen und anschließend zu einem geeigneten Backend verteilen. Die Health-Check-Logik ersetzt jedoch keine Routingentscheidung und umgekehrt. Wer beide Ebenen in einem einzigen Failover-Begriff zusammenfasst, erschwert Diagnose und Verantwortungszuordnung.\u003c/p\u003e\n\u003ch2 id=\"3-edge-failover-und-anwendungsfailover-liegen-getrennt\"\u003e3. Edge-Failover und Anwendungsfailover liegen getrennt\u003c/h2\u003e\n\u003cp\u003eSelbst wenn Routing und Backend-Zustand korrekt bewertet werden, kann die Anwendung fachlich nicht verfügbar sein. Ein HTTP-Statuscode kann beispielsweise einen Fehler melden, obwohl Netzwerkverbindungen funktionieren. Ebenso kann eine Anwendung antworten, aber keine Datenbankzugriffe ausführen oder keine neuen Transaktionen annehmen. Solche Zustände gehören zum Anwendungs- oder Plattformfailover, nicht zum Anycast Routing.\u003c/p\u003e\n\u003cp\u003eDie Edge kann den öffentlichen Zugang schützen, terminieren und verteilen. TLS Termination, Web Application Firewall, DDoS Protection und Backend Cloaking liegen vor den eigentlichen Workloads. Sie verbessern die Kontrollierbarkeit des Eingangs, lösen aber keine fachlichen Abhängigkeiten innerhalb der Anwendung. Deshalb müssen Health Checks passend zur Architektur gewählt und mit den Mechanismen der Anwendung abgestimmt werden. Ein zu oberflächlicher Check lässt fehlerhafte Backends erreichbar erscheinen; ein zu strenger Check kann funktionierende Kapazität unnötig aus dem Traffic-Routing nehmen.\u003c/p\u003e\n\u003ch2 id=\"4-failover-braucht-beobachtbare-zuständigkeiten\"\u003e4. Failover braucht beobachtbare Zuständigkeiten\u003c/h2\u003e\n\u003cp\u003eEin belastbares Failover-Modell benötigt klare Signale und eine nachvollziehbare Reihenfolge. Zuerst muss erkennbar sein, ob der öffentliche Pfad die Edge erreicht. Danach ist zu prüfen, ob die Edge das Backend über den vorgesehenen Pfad kontaktieren kann. Erst anschließend stellt sich die Frage, ob die Anwendung fachlich korrekt arbeitet. Traffic- und Usage-Statistiken sowie Backend-Zustände helfen, diese Ebenen im Betrieb auseinanderzuhalten.\u003c/p\u003e\n\u003cp\u003eFür Plattformteams ist diese Trennung auch organisatorisch relevant. Netzwerkverantwortliche beurteilen Routing und Erreichbarkeit der Edge, während Plattform- und Anwendungsteams Backend- und Servicezustände verantworten. Ein providerunabhängiger Edge-Eingang kann dabei konsistente Schutz- und Routingfunktionen vor \u003ca href=\"/kubernetes/\"\u003eKubernetes-Clustern\u003c/a\u003e\n oder anderen Backends bereitstellen. Die ayedo Edge Cloud ist deshalb nicht auf ayedo Managed Kubernetes beschränkt, sondern kann auch mit eigenen oder bei anderen Providern betriebenen Kubernetes-Clustern genutzt werden.\u003c/p\u003e\n\u003ch2 id=\"praxisszenario-zwei-fehler-zwei-reaktionen\"\u003ePraxisszenario: Zwei Fehler, zwei Reaktionen\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt eine API auf zwei \u003ca href=\"/kubernetes/\"\u003eKubernetes-Clustern\u003c/a\u003e\n bei unterschiedlichen Providern. Fällt eine ayedo Edge-Struktur aus, kann Anycast Routing den öffentlichen Traffic zu einer anderen verfügbaren Struktur führen. Die API bleibt erreichbar, sofern die Session neu aufgebaut werden kann.\u003c/p\u003e\n\u003cp\u003eFällt dagegen nur der Backend-Service eines Clusters aus, bleibt die Edge erreichbar. Backend Health Checks erkennen das Zielproblem und verhindern, dass weitere Anfragen an dieses Backend verteilt werden. Die öffentliche IP und die Schutzfunktionen bleiben unverändert. Erst wenn beide Backends nicht verfügbar sind oder die Anwendung selbst einen fachlichen Failover ausführt, liegt ein nachgelagertes Anwendungsproblem vor. Diese Unterscheidung verkürzt die Fehlersuche und verhindert falsche Maßnahmen am Routing.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"was-bedeutet-anycast-failover\"\u003eWas bedeutet Anycast Failover?\u003c/h3\u003e\n\u003cp\u003eAnycast Failover bezeichnet die Übernahme des öffentlichen Traffic-Eingangs durch eine andere Edge-Struktur, wenn eine Routing-Ankündigung oder ein erreichbarer Pfad ausfällt.\u003c/p\u003e\n\u003ch3 id=\"erkennen-anycast-routen-defekte-backends\"\u003eErkennen Anycast-Routen defekte Backends?\u003c/h3\u003e\n\u003cp\u003eNein. Anycast Routing bewertet den Pfad zur Edge. Ob ein Backend nutzbar ist, wird über separate Backend Health Checks und Failover-Regeln bestimmt.\u003c/p\u003e\n\u003ch3 id=\"bleiben-bestehende-verbindungen-bei-edge-failover-erhalten\"\u003eBleiben bestehende Verbindungen bei Edge-Failover erhalten?\u003c/h3\u003e\n\u003cp\u003eNicht grundsätzlich. Bei einem Wechsel der Edge-Struktur können bestehende Sessions abbrechen. Das Verhalten hängt vom Protokoll, der Sessionverwaltung und der Anwendung ab.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eAnycast Failover ist ein Mechanismus für den öffentlichen Zugang, nicht für die gesamte Verfügbarkeitslogik einer Anwendung. Routing, Edge-Zustand, Backend Health Checks und fachliches Anwendungsfailover müssen getrennt modelliert und gemeinsam betrieben werden. Die ayedo Edge Cloud ordnet diese Ebenen in einer verteilten Aktiv-Aktiv-Architektur ein und kann den Traffic-Eingang vor unterschiedlichen Backend- und \u003ca href=\"/kubernetes/\"\u003eKubernetes-Umgebungen\u003c/a\u003e\n konsistent bereitstellen.\u003c/p\u003e\n", "summary": "\nTL;DR Anycast Failover verlagert Traffic nicht automatisch auf ein gesundes Backend. Anycast Routing entscheidet zunächst, welche Edge-Struktur eine Anfrage erreicht. Backend Health Checks bewerten anschließend die Erreichbarkeit nachgelagerter Dienste. Erst Zusammenspiel und klare Zuständigkeiten ergeben ein belastbares Failover-Modell.\nEinleitung Ein häufiger Architekturfehler besteht darin, Anycast mit vollständigem Failover gleichzusetzen. Anycast sorgt zunächst dafür, dass eine IP-Adresse von mehreren Netzwerkknoten erreichbar ist und Routingentscheidungen den Traffic zu einer verfügbaren Edge-Struktur lenken können. Damit ist jedoch noch nicht entschieden, ob das eigentliche Backend gesund ist oder eine Anwendung ihren Dienst korrekt erbringt. Für den Betrieb müssen deshalb drei Ebenen getrennt betrachtet werden: das Routing zum öffentlichen Eingang, die Verfügbarkeit der Edge-Struktur und die Erreichbarkeit der nachgelagerten Services. Genau an dieser Abgrenzung entscheidet sich, ob Failover kontrollierbar oder nur scheinbar vorhanden ist.\n", "image": "https://ayedo.de/anycast-und-routing-failover-an-der-edge-verstehen.png", "date_published": "2026-09-04T22:18:59Z", "date_modified": "2026-09-04T22:18:59Z", "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}], "tags": ["operations","cloud-native","kubernetes","digital-sovereignty","software-delivery"], "language": "de" },{ "id": "https://ayedo.de/posts/aktiv-aktiv-architektur-fur-hochverfugbare-backends/", "url": "https://ayedo.de/posts/aktiv-aktiv-architektur-fur-hochverfugbare-backends/", "title": "Aktiv-Aktiv-Architektur für hochverfügbare Backends", "content_html": "\u003cp\u003e\u003cimg src=\"/posts/aktiv-aktiv-architektur-fur-hochverfugbare-backends/aktiv-aktiv-architektur-fur-hochverfugbare-backends.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eHochverfügbarkeit entsteht nicht allein durch redundante Backends. Auch die Eingangsschicht muss Ausfälle einzelner Standorte, Netzpfade oder Komponenten verkraften können. Eine verteilte Aktiv-Aktiv-Architektur kombiniert deshalb mehrere aktive Edge-Instanzen mit Backend Health Checks und kontrolliertem Failover. Entscheidend ist die gemeinsame Betrachtung von Edge und \u003ca href=\"/kubernetes/\"\u003eCompute\u003c/a\u003e\n.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eEin redundantes Backend ist nicht hochverfügbar, wenn der gesamte öffentliche Traffic über eine einzelne aktive Eingangsschicht läuft. Fällt dieser zentrale Einstiegspunkt aus, bleiben gesunde Anwendungen unerreichbar. Umgekehrt hilft auch eine verteilte Edge-Architektur nicht weiter, wenn sie weiterhin Traffic an nicht erreichbare oder fehlerhafte Backends verteilt. Hochverfügbarkeit ist daher eine Kette aus mindestens zwei Ebenen: der verteilten Annahme und Verarbeitung des Traffics sowie der kontrollierten Erreichbarkeit nachgelagerter Workloads. Eine Aktiv-Aktiv-Architektur muss beide Ebenen zusammenführen und Zustände kontinuierlich bewerten.\u003c/p\u003e\n\u003ch2 id=\"1-aktiv-aktiv-beginnt-am-öffentlichen-eingang\"\u003e1. Aktiv-Aktiv beginnt am öffentlichen Eingang\u003c/h2\u003e\n\u003cp\u003eBei einer Aktiv-Aktiv-Architektur sind mehrere Edge-Instanzen gleichzeitig produktiv. Traffic wird nicht erst nach dem Ausfall einer primären Instanz auf eine passive Reserve umgeschaltet, sondern verteilt sich grundsätzlich über mehrere aktive Komponenten oder Standorte. Dadurch entfällt ein einzelner aktiver Einstiegspunkt als kritische Abhängigkeit.\u003c/p\u003e\n\u003cp\u003eFür die Edge Cloud bedeutet das eine verteilte Multi-PoP-Architektur mit eigener Netzwerk-Infrastruktur und eigenem Autonomous System. Anycast kann dabei den öffentlichen Zugang über mehrere erreichbare Edge-Standorte abbilden. Der konkrete Traffic-Pfad hängt anschließend von Routing, Erreichbarkeit und den verfügbaren Edge-Funktionen ab.\u003c/p\u003e\n\u003cp\u003eDer betriebliche Vorteil liegt nicht nur in der Ausfalltoleranz. Wartungsarbeiten, Störungen einzelner Standorte oder Beeinträchtigungen bestimmter Netzpfade müssen nicht zwangsläufig den gesamten Dienst unterbrechen. Voraussetzung ist allerdings, dass die aktiven Edge-Komponenten denselben Dienst logisch repräsentieren und nicht jeweils einen isolierten Zustand bilden. Sonst entsteht trotz verteilter Infrastruktur ein versteckter Single Point of Failure.\u003c/p\u003e\n\u003ch2 id=\"2-edge-verfügbarkeit-und-backend-zustand-sind-getrennte-ebenen\"\u003e2. Edge-Verfügbarkeit und Backend-Zustand sind getrennte Ebenen\u003c/h2\u003e\n\u003cp\u003eDie Erreichbarkeit der Edge sagt nichts darüber aus, ob die Anwendung dahinter funktionsfähig ist. Ein Anycast-Endpunkt kann weiterhin Anfragen annehmen, während ein Backend wegen eines Ausfalls, einer Überlastung oder eines Netzproblems nicht mehr antwortet. Deshalb müssen Edge-Verfügbarkeit und Backend-Verfügbarkeit getrennt gemessen und anschließend zusammengeführt werden.\u003c/p\u003e\n\u003cp\u003eBackend Health Checks prüfen, ob definierte nachgelagerte Ziele erreichbar und für Traffic geeignet sind. Dabei ist die Wahl des Prüfpunktes relevant: Ein Netzwerk-Check bestätigt möglicherweise nur die Erreichbarkeit eines Ports, während ein HTTP- oder HTTPS-Check zusätzlich eine verwertbare Antwort des Dienstes prüfen kann. Welche Prüftiefe sinnvoll ist, hängt vom Protokoll und vom Fehlerbild ab.\u003c/p\u003e\n\u003cp\u003eIm Fehlerfall darf die Edge nicht weiter blind an ein ungesundes Ziel verteilen. Failover muss deshalb an einen definierten Zustand gekoppelt sein: etwa an das Ausbleiben erfolgreicher Health Checks oder an den Verlust einer Backend-Gruppe. So wird aus reiner Redundanz eine betriebsfähige Hochverfügbarkeitslogik. Die Edge Cloud verbindet dafür Loadbalancing, Health Checks und Failover, ohne die \u003ca href=\"/kubernetes/\"\u003eCompute\u003c/a\u003e\n Infrastruktur selbst zu ersetzen.\u003c/p\u003e\n\u003ch2 id=\"3-failover-braucht-klare-zustände-und-kontrollierte-entscheidungen\"\u003e3. Failover braucht klare Zustände und kontrollierte Entscheidungen\u003c/h2\u003e\n\u003cp\u003eFailover ist kein Synonym für „bei Fehlern einfach umschalten“. Eine belastbare Architektur muss festlegen, wann ein Backend als nicht verfügbar gilt, wie lange dieser Zustand beobachtet wird und welches alternative Ziel verwendet wird. Zu aggressive Umschaltungen können bei kurzen Netzstörungen unnötige Wechsel auslösen. Zu träge Entscheidungen verlängern dagegen die Zeit, in der Nutzer fehlerhafte Backends erreichen.\u003c/p\u003e\n\u003cp\u003eBesonders wichtig ist die Unterscheidung zwischen einem einzelnen fehlerhaften Backend und einem größeren Ausfall. Fällt nur eine Instanz aus, sollte Traffic möglichst auf gesunde Ziele derselben Gruppe verteilt werden. Ist eine gesamte Backend-Zone oder ein Cluster nicht erreichbar, braucht es ein Failover auf eine andere verfügbare Backend-Gruppe. Die Architektur muss dabei sicherstellen, dass das alternative Ziel tatsächlich Kapazität und die erforderlichen Daten oder Zustände besitzt.\u003c/p\u003e\n\u003cp\u003eAuch Protokoll und Anwendung beeinflussen die Entscheidung. Bei zustandslosen APIs ist ein Wechsel meist einfacher als bei lang laufenden Verbindungen oder Sitzungen mit lokalem Zustand. Health Checks und Failover lösen daher nicht automatisch jede Anwendungseigenschaft. Sie schaffen die technische Grundlage; Session-Handling, Replikation und Datenkonsistenz bleiben Aufgaben der Backend- und \u003ca href=\"/kubernetes/\"\u003eCompute\u003c/a\u003e\n Architektur.\u003c/p\u003e\n\u003ch2 id=\"4-die-gemeinsame-betriebsverantwortung-darf-nicht-unsichtbar-bleiben\"\u003e4. Die gemeinsame Betriebsverantwortung darf nicht unsichtbar bleiben\u003c/h2\u003e\n\u003cp\u003eEine verteilte Edge reduziert das Ausfallrisiko am öffentlichen Eingang, verlagert die Betriebsaufmerksamkeit aber nicht vollständig von den Teams weg. Verantwortlichkeiten müssen zwischen Edge und Compute klar getrennt sein. Die Edge Cloud übernimmt Annahme, Routing, Schutz und Verteilung des Traffics. Die Compute-Infrastruktur verantwortet Anwendungen, Workloads, Daten und deren interne Redundanz.\u003c/p\u003e\n\u003cp\u003eDiese Trennung ist auch für die Fehleranalyse entscheidend. Ein Timeout kann durch einen nicht erreichbaren Edge-Pfad, ein fehlerhaftes Routing, einen ausgefallenen Backend-Service oder eine Überlastung im Cluster entstehen. Traffic- und Usage-Statistiken sowie der Status der Backend Health Checks liefern dafür unterschiedliche Perspektiven. Erst ihre gemeinsame Auswertung macht sichtbar, ob ein Problem am Eingang oder im nachgelagerten Dienst liegt.\u003c/p\u003e\n\u003cp\u003eFür Unternehmen hat das eine organisatorische und wirtschaftliche Konsequenz: Redundanz muss Ende zu Ende geplant werden. Mehrere Backend-Instanzen rechtfertigen keine Hochverfügbarkeitsaussage, wenn DNS, Edge oder Netzpfad zentralisiert bleiben. Umgekehrt kann eine aktive Edge keinen fehlenden Replikations- oder Failover-Mechanismus im Backend kompensieren.\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. Beide Cluster stellen denselben Dienst bereit, sind aber nicht identisch an den öffentlichen Traffic angebunden. Eine verteilte Edge nimmt Anfragen über Anycast entgegen und nutzt Health Checks für beide Backend-Gruppen.\u003c/p\u003e\n\u003cp\u003eFällt eine Anwendungspod-Gruppe in Cluster A aus, verteilt die Edge den Traffic auf verbleibende gesunde Ziele. Wird der gesamte Cluster A unerreichbar, greift das Failover auf Cluster B. Fällt dagegen ein Edge-Standort aus, bleibt der Dienst über andere aktive Edge-Standorte erreichbar. Die Hochverfügbarkeit entsteht somit erst durch das Zusammenspiel aus verteilter Eingangsschicht, geprüften Backend-Zielen und einer tatsächlich nutzbaren zweiten \u003ca href=\"/kubernetes/\"\u003eCompute\u003c/a\u003e\n Umgebung.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"ist-eine-aktiv-aktiv-edge-automatisch-ein-aktiv-aktiv-backend\"\u003eIst eine Aktiv-Aktiv-Edge automatisch ein Aktiv-Aktiv-Backend?\u003c/h3\u003e\n\u003cp\u003eNein. Aktiv-Aktiv auf der Edge beschreibt die gleichzeitig betriebene Eingangsschicht. Die Backends müssen zusätzlich selbst redundant betrieben und über geeignete Routing- und Failover-Regeln eingebunden werden.\u003c/p\u003e\n\u003ch3 id=\"was-passiert-wenn-alle-backends-gesund-aber-ein-edge-standort-nicht-erreichbar-ist\"\u003eWas passiert, wenn alle Backends gesund, aber ein Edge-Standort nicht erreichbar ist?\u003c/h3\u003e\n\u003cp\u003eBei einer verteilten Aktiv-Aktiv-Architektur kann Traffic über andere aktive Edge-Standorte verarbeitet werden. Das setzt voraus, dass Routing und Erreichbarkeit den verbleibenden Pfad unterstützen.\u003c/p\u003e\n\u003ch3 id=\"reichen-backend-health-checks-für-hochverfügbarkeit-aus\"\u003eReichen Backend Health Checks für Hochverfügbarkeit aus?\u003c/h3\u003e\n\u003cp\u003eNein. Health Checks erkennen Zustände und ermöglichen Entscheidungen. Sie ersetzen weder redundante Backends noch Replikation, Kapazitätsplanung, Session-Handling oder einen getesteten Betriebsprozess.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eHochverfügbarkeit ist eine Ende-zu-Ende-Eigenschaft und kein Merkmal einzelner Komponenten. Eine verteilte Aktiv-Aktiv-Architektur schützt den öffentlichen Eingang, während Backend Health Checks und Failover die Erreichbarkeit der nachgelagerten Dienste bewerten. Die ayedo Edge Cloud ordnet diese Ebenen in einer eigenen, verteilten Netzwerk-Infrastruktur ein und kann dabei auch mit \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n Clustern außerhalb von ayedo Managed Kubernetes betrieben werden. Entscheidend bleibt die abgestimmte Architektur von Edge und \u003ca href=\"/kubernetes/\"\u003eCompute\u003c/a\u003e\n.\u003c/p\u003e\n", "summary": "\nTL;DR Hochverfügbarkeit entsteht nicht allein durch redundante Backends. Auch die Eingangsschicht muss Ausfälle einzelner Standorte, Netzpfade oder Komponenten verkraften können. Eine verteilte Aktiv-Aktiv-Architektur kombiniert deshalb mehrere aktive Edge-Instanzen mit Backend Health Checks und kontrolliertem Failover. Entscheidend ist die gemeinsame Betrachtung von Edge und Compute .\nEinleitung Ein redundantes Backend ist nicht hochverfügbar, wenn der gesamte öffentliche Traffic über eine einzelne aktive Eingangsschicht läuft. Fällt dieser zentrale Einstiegspunkt aus, bleiben gesunde Anwendungen unerreichbar. Umgekehrt hilft auch eine verteilte Edge-Architektur nicht weiter, wenn sie weiterhin Traffic an nicht erreichbare oder fehlerhafte Backends verteilt. Hochverfügbarkeit ist daher eine Kette aus mindestens zwei Ebenen: der verteilten Annahme und Verarbeitung des Traffics sowie der kontrollierten Erreichbarkeit nachgelagerter Workloads. Eine Aktiv-Aktiv-Architektur muss beide Ebenen zusammenführen und Zustände kontinuierlich bewerten.\n", "image": "https://ayedo.de/aktiv-aktiv-architektur-fur-hochverfugbare-backends.png", "date_published": "2026-09-04T22:12:59Z", "date_modified": "2026-09-04T22:12:59Z", "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/die-edge-als-schutzschicht-fur-anwendungen-und-apis/", "url": "https://ayedo.de/posts/die-edge-als-schutzschicht-fur-anwendungen-und-apis/", "title": "Die Edge als Schutzschicht für Anwendungen und APIs", "content_html": "\u003cp\u003e\u003cimg src=\"/posts/die-edge-als-schutzschicht-fur-anwendungen-und-apis/die-edge-als-schutzschicht-fur-anwendungen-und-apis.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eÖffentlich erreichbare Anwendungen und APIs sollten nicht direkt mit ihren Backends verbunden sein. Eine vorgelagerte Edge-Schicht übernimmt DDoS Protection und Scrubbing, WAF-Prüfungen, TLS-Termination und die Abschirmung der Ursprungsinfrastruktur. So entsteht Security-by-Architecture: Schutz wird dort verankert, wo eingehender Traffic erstmals kontrolliert verarbeitet wird.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eEin häufiger Architekturfehler besteht darin, öffentliche APIs direkt über die Infrastruktur des jeweiligen Clusters oder Cloud-Providers erreichbar zu machen. Dadurch treffen volumetrische Angriffe, fehlerhafte Requests und legitimer Datenverkehr auf derselben Ebene zusammen wie die eigentliche Anwendung. Schutzfunktionen werden dann nachträglich in einzelne Workloads, Ingress-Komponenten oder Provider-Dienste integriert.\u003c/p\u003e\n\u003cp\u003eSecurity-by-Architecture verfolgt den umgekehrten Ansatz: Der öffentliche Traffic wird zunächst an einer kontrollierten Edge verarbeitet. Erst danach erreicht er die Backends. Diese Trennung reduziert die Angriffsfläche, zentralisiert sicherheitsrelevante Entscheidungen und entkoppelt den Schutz öffentlich erreichbarer Services von ihrer Compute-Infrastruktur.\u003c/p\u003e\n\u003ch2 id=\"1-ddos-protection-beginnt-vor-der-anwendung\"\u003e1. DDoS Protection beginnt vor der Anwendung\u003c/h2\u003e\n\u003cp\u003eDDoS-Angriffe unterscheiden sich in Volumen, Protokoll und Ziel. Ein Angriff auf Layer 3 oder Layer 4 belastet Netzwerkpfade und Verbindungen, während ein Layer-7-Angriff formal korrekte HTTP-Anfragen gegen konkrete Endpunkte richtet. In beiden Fällen ist entscheidend, wo der Traffic erstmals bewertet und verworfen werden kann.\u003c/p\u003e\n\u003cp\u003eDDoS Protection und Scrubbing an der Edge verschieben diese Aufgabe vor die Backends. Schädlicher oder nicht verwertbarer Traffic wird möglichst früh aus dem Request-Flow entfernt, bevor er Anwendungspods, Datenbanken oder interne Netzwerkkomponenten belastet. Das schützt nicht nur die Verfügbarkeit, sondern reduziert auch den operativen Druck während eines Angriffs.\u003c/p\u003e\n\u003cp\u003eDie ayedo Edge Cloud übernimmt diesen öffentlichen Eingang über eine verteilte Multi-PoP-Architektur, Anycast und ein eigenes Autonomous System. Das Aktiv-Aktiv-Prinzip unterstützt dabei eine Architektur, in der der Schutz nicht an einen einzelnen Eintrittspunkt gebunden ist. Für Unternehmen ist relevant: DDoS-Abwehr wird zu einer zentralen Edge-Funktion statt zu einer individuellen Aufgabe jedes Backends.\u003c/p\u003e\n\u003ch2 id=\"2-waf-und-api-sicherheit-im-request-flow\"\u003e2. WAF und API-Sicherheit im Request-Flow\u003c/h2\u003e\n\u003cp\u003eEine Web Application Firewall prüft HTTP- und HTTPS-Traffic auf Merkmale, die auf missbräuchliche oder unerlaubte Anfragen hindeuten. Für APIs betrifft das beispielsweise manipulierte Parameter, auffällige Request-Muster oder Zugriffe auf nicht vorgesehene Pfade. Die WAF ersetzt keine Authentifizierung und keine sichere Anwendungsentwicklung, bildet aber eine zusätzliche Kontrollschicht vor dem Service.\u003c/p\u003e\n\u003cp\u003eIhre Position im Request-Flow ist entscheidend. Wird die Prüfung erst im Backend oder in jedem einzelnen Service umgesetzt, entstehen unterschiedliche Regeln, Konfigurationen und Betriebsprozesse. Eine zentrale Edge reduziert diese Streuung und ermöglicht, Schutzentscheidungen vor der Weiterleitung an die Anwendung zu treffen.\u003c/p\u003e\n\u003cp\u003eBei der ayedo Edge Cloud ist die WAF Bestandteil der vorgelagerten Plattform für HTTP-/HTTPS-Services. Das macht sie auch für API-Landschaften relevant, die über \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n, eine klassische Plattform oder Infrastruktur bei einem anderen Provider betrieben werden. API-Sicherheit wird damit nicht an einen bestimmten Compute-Ort gebunden.\u003c/p\u003e\n\u003ch2 id=\"3-tls-termination-schafft-eine-kontrollierte-prüfstelle\"\u003e3. TLS-Termination schafft eine kontrollierte Prüfstelle\u003c/h2\u003e\n\u003cp\u003eVerschlüsselter Traffic schützt die Übertragung, verhindert aber zugleich eine Prüfung des Inhalts an Stellen, die den Request nicht terminieren. TLS-Termination an der Edge schafft einen definierten Übergang: Die Verbindung des Clients endet dort, und der Traffic kann für nachgelagerte Funktionen wie WAF-Prüfung, Routing und Lastverteilung verarbeitet werden.\u003c/p\u003e\n\u003cp\u003eDas verändert die Sicherheitsarchitektur. Zertifikatsverwaltung und die Verarbeitung öffentlicher HTTPS-Verbindungen liegen an einem zentralen Eintrittspunkt, statt über zahlreiche Backends und Cluster verteilt zu sein. Gleichzeitig muss klar dokumentiert werden, wie der Traffic zwischen Edge und Backend abgesichert und welche Vertrauensgrenze damit eingeführt wird. TLS-Termination ist daher keine rein technische Komfortfunktion, sondern eine bewusste Architekturentscheidung.\u003c/p\u003e\n\u003cp\u003eIn der ayedo Edge Cloud ist TLS-Termination mit den weiteren Edge-Funktionen verbunden. Dadurch kann ein Request vor der Weiterleitung geschützt, geprüft und an das passende Backend verteilt werden. Die Compute-Umgebung bleibt für die Anwendung verantwortlich, während die Edge den öffentlichen HTTPS-Eingang kontrolliert.\u003c/p\u003e\n\u003ch2 id=\"4-backend-cloaking-trennt-öffentlichkeit-und-ursprung\"\u003e4. Backend Cloaking trennt Öffentlichkeit und Ursprung\u003c/h2\u003e\n\u003cp\u003eSelbst gut geschützte Anwendungen bleiben angreifbar, wenn ihre Origin-Adressen öffentlich bekannt und direkt erreichbar sind. Backend Cloaking reduziert diese Kopplung: Clients kommunizieren mit der Edge, nicht unmittelbar mit den tatsächlichen Backend-Endpunkten. Das erschwert direkte Zugriffe und verhindert, dass die Edge-Schutzschicht einfach umgangen wird.\u003c/p\u003e\n\u003cp\u003eDiese Trennung ist besonders wichtig bei API-Plattformen mit mehreren Clustern, Providern oder Umgebungen. Ändert sich das Backend, muss der öffentliche Einstiegspunkt nicht zwangsläufig geändert werden. Health Checks und Failover können die Erreichbarkeit der Backends überwachen, während die öffentliche Adresse an der Edge stabil bleibt.\u003c/p\u003e\n\u003cp\u003eDer betriebliche Nutzen liegt in einer klareren Verantwortungsgrenze: Die Edge kontrolliert öffentlichen Traffic, die Compute-Infrastruktur führt Workloads aus. Die ayedo Edge Cloud kann dabei vor ayedo Managed \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n ebenso eingesetzt werden wie vor eigenen oder bei anderen Providern betriebenen Kubernetes-Clustern. Providerunabhängigkeit wird so zu einem Bestandteil der Sicherheitsarchitektur.\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 \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n-Clustern bei unterschiedlichen Providern. Ohne Edge-Schicht zeigen DNS-Einträge direkt auf Ingress-Endpunkte; DDoS-Schutz, TLS und Filterregeln müssen je Umgebung abgestimmt werden. Bei einem Angriff bleiben die Ursprungsadressen sichtbar und die Cluster tragen die Last der ersten Abwehr.\u003c/p\u003e\n\u003cp\u003eMit einer vorgelagerten Edge werden DNS und öffentliche Erreichbarkeit an einen zentralen Einstiegspunkt gebunden. DDoS Protection und Scrubbing entfernen schädlichen Traffic, die WAF prüft HTTP-Anfragen, TLS wird an der Edge terminiert und nur zugelassener Traffic erreicht die Backends. Backend Cloaking verhindert direkte Zugriffe; Health Checks ermöglichen die Weiterleitung an verfügbare Umgebungen. Die Sicherheitslogik folgt damit dem Request-Flow statt der jeweiligen Providerstruktur.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"ist-eine-waf-allein-ausreichender-api-schutz\"\u003eIst eine WAF allein ausreichender API-Schutz?\u003c/h3\u003e\n\u003cp\u003eNein. Eine WAF ergänzt Authentifizierung, Autorisierung, sichere API-Implementierung und Monitoring. Sie reduziert bestimmte Angriffsvektoren, ersetzt aber keine fachliche Zugriffskontrolle.\u003c/p\u003e\n\u003ch3 id=\"warum-sollte-die-edge-nicht-im-selben-cluster-wie-die-anwendung-laufen\"\u003eWarum sollte die Edge nicht im selben Cluster wie die Anwendung laufen?\u003c/h3\u003e\n\u003cp\u003eEine gemeinsame Platzierung koppelt Schutz und Workload an dieselbe Ausfall- und Ressourcenebene. Eine vorgelagerte Edge kann Traffic verarbeiten, bevor der Cluster erreicht wird.\u003c/p\u003e\n\u003ch3 id=\"gilt-edge-security-nur-für-kubernetes\"\u003eGilt Edge-Security nur für Kubernetes?\u003c/h3\u003e\n\u003cp\u003eNein. Die Schutzschicht kann vor Anwendungen und APIs unabhängig von ihrer Compute-Plattform eingesetzt werden, auch vor eigenen oder bei anderen Providern betriebenen Umgebungen.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eEdge-Security für APIs ist vor allem eine Frage der Platzierung. DDoS Protection, Scrubbing, WAF und TLS-Termination wirken am effektivsten als zusammenhängende Kontrollschicht vor der Anwendung. Backend Cloaking ergänzt diese Architektur, indem es die Ursprungsinfrastruktur aus dem öffentlichen Zugriff herausnimmt. Die ayedo Edge Cloud ordnet diese Funktionen in einer providerunabhängigen, aktiv-aktiven Edge-Plattform ein und trennt damit öffentlichen Traffic sauber von der Compute-Verantwortung.\u003c/p\u003e\n", "summary": "\nTL;DR Öffentlich erreichbare Anwendungen und APIs sollten nicht direkt mit ihren Backends verbunden sein. Eine vorgelagerte Edge-Schicht übernimmt DDoS Protection und Scrubbing, WAF-Prüfungen, TLS-Termination und die Abschirmung der Ursprungsinfrastruktur. So entsteht Security-by-Architecture: Schutz wird dort verankert, wo eingehender Traffic erstmals kontrolliert verarbeitet wird.\nEinleitung Ein häufiger Architekturfehler besteht darin, öffentliche APIs direkt über die Infrastruktur des jeweiligen Clusters oder Cloud-Providers erreichbar zu machen. Dadurch treffen volumetrische Angriffe, fehlerhafte Requests und legitimer Datenverkehr auf derselben Ebene zusammen wie die eigentliche Anwendung. Schutzfunktionen werden dann nachträglich in einzelne Workloads, Ingress-Komponenten oder Provider-Dienste integriert.\n", "image": "https://ayedo.de/die-edge-als-schutzschicht-fur-anwendungen-und-apis.png", "date_published": "2026-09-04T22:12:59Z", "date_modified": "2026-09-04T22:12:59Z", "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}], "tags": ["security","operations","kubernetes","cloud-native","development"], "language": "de" },{ "id": "https://ayedo.de/posts/edge-plattform-statt-add-on-architekturgrenzen-verstehen/", "url": "https://ayedo.de/posts/edge-plattform-statt-add-on-architekturgrenzen-verstehen/", "title": "Edge-Plattform statt Add-on: Architekturgrenzen verstehen", "content_html": "\u003cp\u003e\u003cimg src=\"/posts/edge-plattform-statt-add-on-architekturgrenzen-verstehen/edge-plattform-statt-add-on-architekturgrenzen-verstehen.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eDie ayedo Edge Cloud ist keine einzelne Zusatzfunktion für Managed \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n und kein vorgeschalteter Loadbalancer. Sie bildet eine eigenständige Architekturschicht für öffentlichen Traffic: DNS, Routing, Schutz, TLS, Lastverteilung und Backend-Anbindung werden zentral vor unterschiedlichen Compute-Umgebungen betrieben. Dadurch bleiben Anwendungen und Cluster austauschbar, ohne den öffentlichen Zugang neu zu entwerfen.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eEin häufiger Architekturfehler besteht darin, den öffentlichen Zugang zu einer Anwendung mit dem Loadbalancing innerhalb ihrer Compute-Umgebung gleichzusetzen. Ein \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n-Service oder ein externer Loadbalancer kann Traffic an Pods verteilen, löst aber nicht automatisch DNS-Redundanz, DDoS-Schutz, TLS-Termination, Backend-Cloaking oder die providerunabhängige Anbindung verschiedener Cluster. Genau hier liegt die Grenze zwischen Compute und Edge. Wer diese Ebenen vermischt, koppelt öffentliche Erreichbarkeit unnötig an einen Cluster, einen Provider oder eine einzelne Plattform. Eine belastbare Edge-Plattform behandelt den Eingang des Traffics als eigenständige Architekturaufgabe.\u003c/p\u003e\n\u003ch2 id=\"1-die-edge-beginnt-vor-dem-cluster\"\u003e1. Die Edge beginnt vor dem Cluster\u003c/h2\u003e\n\u003cp\u003eEin Loadbalancer innerhalb oder unmittelbar vor einem Clusters erfüllt typischerweise eine klar begrenzte Aufgabe: Er verteilt Anfragen auf verfügbare Backends. Die Edge Cloud betrachtet dagegen den gesamten Weg vom Client bis zum Backend. Dazu gehören Anycast DNS beziehungsweise Multi-Provider-DNS, Anycast-basiertes Layer-4- und Layer-7-Loadbalancing, TLS-Termination, WAF und DDoS Protection mit Scrubbing an der Edge.\u003c/p\u003e\n\u003cp\u003eDiese Funktionen wirken zusammen. DNS bestimmt, wohin Clients auflösen. Anycast-Routing führt den Traffic in die verteilte Edge-Infrastruktur. Dort können Sicherheitsregeln und TLS-Verarbeitung greifen, bevor eine Verbindung das Backend erreicht. Erst danach erfolgt die Lastverteilung auf konkrete Ziele. Das reduziert nicht nur die Angriffsfläche, sondern trennt auch öffentliche Adressierung und Sicherheitsrichtlinien von der internen Topologie. Ein einzelnes Loadbalancer-Feature kann diese Kette nicht ersetzen, weil ihm die übergreifende Verantwortung für Namensauflösung, Schutz und Backend-Zugang fehlt.\u003c/p\u003e\n\u003ch2 id=\"2-compute-entkopplung-ist-eine-architekturentscheidung\"\u003e2. Compute-Entkopplung ist eine Architekturentscheidung\u003c/h2\u003e\n\u003cp\u003eCompute-Entkopplung bedeutet, dass Anwendungen dort betrieben werden können, wo es fachlich oder betrieblich sinnvoll ist, während der öffentliche Zugang stabil bleibt. Das Backend kann in ayedo Managed \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n, in einem eigenen Kubernetes-Cluster oder bei einem anderen Provider liegen. Die Edge Cloud bleibt dabei die zentrale Schicht für Routing, Schutz und Verteilung.\u003c/p\u003e\n\u003cp\u003eDiese Trennung verändert den Migrationsaufwand. Ein Clusterwechsel muss nicht zwangsläufig eine neue öffentliche Architektur, neue DNS-Konzepte und verteilte Sicherheitskonfigurationen auslösen. Backend Health Checks und Failover können Ziele nach Verfügbarkeit berücksichtigen. Backend Cloaking verhindert zusätzlich, dass interne Backend-Adressen als öffentliche Zielstruktur vorausgesetzt werden. Proxy Protocol kann relevante Verbindungsinformationen an unterstützte Backends weitergeben, ohne die Verantwortungsgrenzen zwischen Edge und Anwendung aufzulösen.\u003c/p\u003e\n\u003cp\u003eFür Platform-Teams entsteht damit ein klareres Betriebsmodell: Cluster werden nach Compute-Anforderungen verwaltet, die Edge nach Anforderungen an Erreichbarkeit und öffentlichen Traffic. Beide Ebenen bleiben integrierbar, sind aber nicht identisch.\u003c/p\u003e\n\u003ch2 id=\"3-sicherheit-und-tls-gehören-in-die-vorgelagerte-schicht\"\u003e3. Sicherheit und TLS gehören in die vorgelagerte Schicht\u003c/h2\u003e\n\u003cp\u003eWird Sicherheit ausschließlich im Cluster umgesetzt, muss jeder Compute-Standort wesentliche Schutzfunktionen selbst bereitstellen. Das führt zu unterschiedlichen Konfigurationen, mehreren Betriebsverantwortungen und einer größeren Abhängigkeit von der jeweiligen Umgebung. Besonders bei mehreren Clustern oder Providern wird aus einer lokalen Schutzmaßnahme schnell ein verteiltes Governance-Problem.\u003c/p\u003e\n\u003cp\u003eEine Edge-Plattform bündelt diese Aufgaben vor den Backends. Die WAF verarbeitet HTTP- und HTTPS-Traffic an der Edge, DDoS Protection und Scrubbing halten schädlichen Traffic möglichst außerhalb der Compute-Infrastruktur, und TLS kann an der Edge terminiert werden. Dadurch erreichen nur weitergeleitete Anfragen die Backends. Der Nutzen liegt nicht darin, dass interne Sicherheitskontrollen überflüssig werden. Vielmehr entsteht eine zusätzliche, zentral steuerbare Schutz- und Terminationsebene.\u003c/p\u003e\n\u003cp\u003eFür die Architektur ist entscheidend: Diese Funktionen sind unabhängig davon relevant, ob das Backend in Managed \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n läuft. Die Edge ist daher keine Kubernetes-Erweiterung, sondern eine vorgelagerte Sicherheits- und Zugangsschicht für Anwendungen und APIs.\u003c/p\u003e\n\u003ch2 id=\"4-eigene-infrastruktur-schafft-eine-eigenständige-verantwortung\"\u003e4. Eigene Infrastruktur schafft eine eigenständige Verantwortung\u003c/h2\u003e\n\u003cp\u003eEine Edge-Plattform ist auch deshalb mehr als ein Add-on, weil sie eigene Netzwerk- und Betriebsverantwortung trägt. Die ayedo Edge Cloud nutzt eine eigene Netzwerk-Infrastruktur und ein eigenes Autonomous System. Ihre verteilte Multi-PoP-Architektur und das Aktiv-Aktiv-Prinzip ordnen den öffentlichen Traffic nicht einem einzelnen Cluster oder Compute-Standort unter.\u003c/p\u003e\n\u003cp\u003eFür Unternehmen ist das relevant, wenn öffentliche Erreichbarkeit, Providerunabhängigkeit und kontrollierte Adressierung strategische Anforderungen sind. Bring Your Own IP kann dabei die Einbindung bestehender Adressräume unterstützen. Traffic- und Usage-Statistiken schaffen zusätzlich eine Grundlage, um Nutzung und Verteilung auf der Edge-Ebene zu beobachten, statt nur einzelne Backend-Systeme zu betrachten.\u003c/p\u003e\n\u003cp\u003eDamit verschiebt sich auch die Zuständigkeit im Betrieb. Teams müssen nicht jeden Cluster als separaten Internetzugang behandeln. Sie können eine gemeinsame Edge-Schicht definieren und dahinter unterschiedliche Compute-Plattformen betreiben. Diese Zentralisierung reduziert nicht automatisch jede Komplexität; sie macht sie jedoch an einer Stelle sichtbar, an der Routing, Schutz und öffentliche Services tatsächlich zusammengehören.\u003c/p\u003e\n\u003ch2 id=\"praxis--und-architekturszenario\"\u003ePraxis- und Architekturszenario\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt eine API in ayedo Managed \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n und eine zweite Anwendung in einem eigenen Cluster bei einem anderen Provider. Ein reiner Cluster-Loadbalancer würde beide Zugänge getrennt behandeln. DNS, TLS, WAF-Regeln und Failover müssten je Umgebung abgestimmt werden.\u003c/p\u003e\n\u003cp\u003eMit einer Edge-Plattform liegen öffentliche DNS-Zuordnung, TLS-Termination, Schutzfunktionen und Lastverteilung vor beiden Backends. Health Checks können den Zustand der Zielsysteme berücksichtigen; die Anwendungen bleiben hinter der Edge verborgen. Wird später ein Backend verschoben, bleibt die öffentliche Eingangsschicht weitgehend unverändert. Der Architekturgewinn entsteht somit nicht durch einen einzelnen Loadbalancer, sondern durch die Entkopplung des öffentlichen Traffics von der Compute-Auswahl.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"ist-die-ayedo-edge-cloud-nur-für-ayedo-managed-kubernetes-gedacht\"\u003eIst die ayedo Edge Cloud nur für ayedo Managed Kubernetes gedacht?\u003c/h3\u003e\n\u003cp\u003eNein. Sie kann auch mit eigenen \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n-Clustern sowie mit Kubernetes-Umgebungen anderer Provider genutzt werden. Managed Kubernetes ist eine mögliche Compute-Umgebung, nicht die Voraussetzung für die Edge-Schicht.\u003c/p\u003e\n\u003ch3 id=\"ersetzt-die-edge-cloud-interne-loadbalancer\"\u003eErsetzt die Edge Cloud interne Loadbalancer?\u003c/h3\u003e\n\u003cp\u003eNein. Interne oder clusternahe Loadbalancer können weiterhin für die Verteilung innerhalb der Compute-Umgebung erforderlich sein. Die Edge Cloud übernimmt den öffentlichen Eingang und die vorgelagerte Verarbeitung.\u003c/p\u003e\n\u003ch3 id=\"warum-ist-dns-teil-der-edge-architektur\"\u003eWarum ist DNS Teil der Edge-Architektur?\u003c/h3\u003e\n\u003cp\u003eDNS bestimmt die öffentliche Erreichbarkeit und kann bei verteilten Architekturen nicht isoliert vom Routing betrachtet werden. Anycast DNS und Multi-Provider-DNS verbinden Namensauflösung mit der resilienten Traffic-Zuführung.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eDie zentrale Architekturentscheidung lautet nicht „welchen Loadbalancer setzen wir vor Kubernetes?“, sondern „wo verantworten wir den öffentlichen Eingang unserer Anwendungen?“. Eine eigenständige Edge-Schicht trennt Routing, Schutz, TLS und Backend-Anbindung von der Compute-Infrastruktur. Die ayedo Edge Cloud ist in diesem Modell providerunabhängig nutzbar und für unterschiedliche Compute-Umgebungen ausgelegt. Genau diese Compute-Entkopplung macht sie zu einer Plattformkomponente – nicht zu einem einzelnen Add-on.\u003c/p\u003e\n", "summary": "\nTL;DR Die ayedo Edge Cloud ist keine einzelne Zusatzfunktion für Managed Kubernetes und kein vorgeschalteter Loadbalancer. Sie bildet eine eigenständige Architekturschicht für öffentlichen Traffic: DNS, Routing, Schutz, TLS, Lastverteilung und Backend-Anbindung werden zentral vor unterschiedlichen Compute-Umgebungen betrieben. Dadurch bleiben Anwendungen und Cluster austauschbar, ohne den öffentlichen Zugang neu zu entwerfen.\nEinleitung Ein häufiger Architekturfehler besteht darin, den öffentlichen Zugang zu einer Anwendung mit dem Loadbalancing innerhalb ihrer Compute-Umgebung gleichzusetzen. Ein Kubernetes -Service oder ein externer Loadbalancer kann Traffic an Pods verteilen, löst aber nicht automatisch DNS-Redundanz, DDoS-Schutz, TLS-Termination, Backend-Cloaking oder die providerunabhängige Anbindung verschiedener Cluster. Genau hier liegt die Grenze zwischen Compute und Edge. Wer diese Ebenen vermischt, koppelt öffentliche Erreichbarkeit unnötig an einen Cluster, einen Provider oder eine einzelne Plattform. Eine belastbare Edge-Plattform behandelt den Eingang des Traffics als eigenständige Architekturaufgabe.\n", "image": "https://ayedo.de/edge-plattform-statt-add-on-architekturgrenzen-verstehen.png", "date_published": "2026-09-04T22:12:59Z", "date_modified": "2026-09-04T22:12:59Z", "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}], "tags": ["kubernetes","operations","security","cloud-native","hosting"], "language": "de" },{ "id": "https://ayedo.de/posts/eigene-netzwerkarchitektur-und-digitale-souveranitat/", "url": "https://ayedo.de/posts/eigene-netzwerkarchitektur-und-digitale-souveranitat/", "title": "Eigene Netzwerkarchitektur und digitale Souveränität", "content_html": "\u003cp\u003e\u003cimg src=\"/posts/eigene-netzwerkarchitektur-und-digitale-souveranitat/eigene-netzwerkarchitektur-und-digitale-souveranitat.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eDigitale Souveränität in der öffentlichen Edge-Schicht zeigt sich nicht durch Herkunftsversprechen, sondern durch technische Kontrollpunkte: Wer steuert Routing, IP-Adressierung, Traffic-Verteilung, Schutzfunktionen und den Betrieb? Ein eigenes \u003ca href=\"/kubernetes/\"\u003eAutonomous System\u003c/a\u003e\n und eigene Netzwerkinfrastruktur schaffen dafür die architektonische Grundlage – ersetzen aber keine belastbaren Betriebsprozesse.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eEine öffentliche Edge-Schicht ist nur dann strategisch kontrollierbar, wenn Unternehmen nicht ausschließlich von den Routing- und Betriebsentscheidungen eines vorgelagerten Providers abhängen. Die zentrale Architekturfrage lautet deshalb nicht, ob Infrastruktur „aus einer Hand“ stammt, sondern welche technischen Kontrollpunkte tatsächlich selbst beherrscht werden. Ein eigenes \u003ca href=\"/kubernetes/\"\u003eAutonomous System\u003c/a\u003e\n und eigene Netzwerkinfrastruktur beeinflussen, wie Traffic angekündigt, verteilt, geschützt und bei Ausfällen umgeleitet wird. Digitale Souveränität wird damit zu einer konkreten Frage der Netzwerkarchitektur und Betriebsverantwortung. Sie entsteht dort, wo Routing, Adressierung und Edge-Funktionen nachvollziehbar zugeordnet und unabhängig von einzelnen Compute-Umgebungen betrieben werden können.\u003c/p\u003e\n\u003ch2 id=\"1-das-autonomous-system-als-kontrollpunkt-für-öffentliches-routing\"\u003e1. Das Autonomous System als Kontrollpunkt für öffentliches Routing\u003c/h2\u003e\n\u003cp\u003eEin \u003ca href=\"/kubernetes/\"\u003eAutonomous System\u003c/a\u003e\n bündelt ein Netzwerk unter einer eigenen Routing- und Betriebsidentität. Für eine öffentliche Edge-Schicht ist das relevant, weil Routing damit nicht nur als implizite Funktion eines Infrastrukturproviders betrachtet wird. Die Ankündigung und Erreichbarkeit öffentlicher Präfixe lassen sich als eigenständige Architekturkomponente planen und betreiben.\u003c/p\u003e\n\u003cp\u003eDas bedeutet nicht, dass ein eigenes AS automatisch vollständige Unabhängigkeit schafft. Routing bleibt von Peering, Transit, technischen Konfigurationen und operativen Prozessen abhängig. Es verschiebt jedoch die Verantwortung an einen klar definierten Kontrollpunkt. Unternehmen können dadurch besser festlegen, welche Edge-Infrastruktur öffentliche Erreichbarkeit übernimmt und wie diese von den Backends getrennt wird.\u003c/p\u003e\n\u003cp\u003eIm Kontext der ayedo Edge Cloud bildet das eigene \u003ca href=\"/kubernetes/\"\u003eAutonomous System\u003c/a\u003e\n zusammen mit eigener Netzwerkinfrastruktur die Grundlage für eine providerunabhängige öffentliche Eingangsschicht. Die Compute-Umgebung kann dabei bei ayedo, im eigenen Rechenzentrum oder bei einem anderen Cloud-Provider betrieben werden. Die Edge wird nicht aus der Herkunft des Backends abgeleitet, sondern als eigenständige Netzwerkfunktion organisiert.\u003c/p\u003e\n\u003ch2 id=\"2-eigene-netzwerkinfrastruktur-verändert-die-betriebsverantwortung\"\u003e2. Eigene Netzwerkinfrastruktur verändert die Betriebsverantwortung\u003c/h2\u003e\n\u003cp\u003eEigene Netzwerkinfrastruktur bedeutet vor allem: Netzwerkpfade, Edge-Knoten und deren Zusammenspiel sind kein vollständig ausgelagertes Detail mehr. Architekturentscheidungen zu Anycast, Multi-PoP-Verteilung, Aktiv-Aktiv-Betrieb und Failover wirken unmittelbar auf Verfügbarkeit und Fehlerbilder. Ein Ausfall ist dann nicht nur eine Frage einzelner virtueller Maschinen, sondern kann Routing, Traffic-Verteilung und Schutzfunktionen gleichzeitig betreffen.\u003c/p\u003e\n\u003cp\u003eDiese Kontrolle erzeugt zusätzliche Verantwortung. Netzwerkänderungen benötigen nachvollziehbare Freigaben, Monitoring, Health Checks und etablierte Verfahren für Störungen. Auch die Trennung zwischen Edge und Compute muss im Betrieb klar bleiben: Die Edge nimmt öffentlichen Traffic entgegen, terminiert TLS, verteilt Anfragen und kann Backends abschirmen. Die Anwendungen selbst werden weiterhin in der Compute-Infrastruktur betrieben.\u003c/p\u003e\n\u003cp\u003eDie ayedo Edge Cloud verbindet diese Verantwortungsbereiche nicht zu einer gemeinsamen Infrastruktur, sondern koppelt sie über definierte Backend-Verbindungen. Aktiv-Aktiv und verteilte Multi-PoP-Architektur reduzieren dabei die Abhängigkeit von einem einzelnen Edge-Standort. Entscheidend ist jedoch, dass diese Architektur mit entsprechenden Betriebsprozessen und nicht nur mit technischer Redundanz unterlegt wird.\u003c/p\u003e\n\u003ch2 id=\"3-souveränität-zeigt-sich-an-mehreren-technischen-kontrollpunkten\"\u003e3. Souveränität zeigt sich an mehreren technischen Kontrollpunkten\u003c/h2\u003e\n\u003cp\u003eRouting allein beschreibt digitale Souveränität nur unvollständig. Für eine öffentliche Edge-Schicht zählen weitere Kontrollpunkte: die Verwaltung öffentlicher IP-Adressen, die Wahl der DNS-Architektur, die TLS-Terminierung, die Sichtbarkeit der Backends sowie die Steuerung von Failover und Schutzmaßnahmen. Je mehr dieser Funktionen getrennt und nachvollziehbar betrieben werden können, desto präziser lässt sich die tatsächliche Infrastrukturkontrolle bewerten.\u003c/p\u003e\n\u003cp\u003eBring Your Own IP kann beispielsweise die Kontinuität einer bestehenden öffentlichen Adressierung unterstützen. Anycast DNS und Multi-Provider-DNS adressieren die Erreichbarkeit auf DNS-Ebene, während Anycast-Layer-4- und Layer-7-Loadbalancing den eingehenden Traffic verteilen. WAF und DDoS Protection verlagern Schutzfunktionen an den öffentlichen Rand des Netzwerks. Backend Cloaking reduziert dabei die direkte Sichtbarkeit der Ursprungsinfrastruktur.\u003c/p\u003e\n\u003cp\u003eDie ayedo Edge Cloud bündelt diese Funktionen in einer Edge-Plattform. Das ist architektonisch relevant, weil Routing, Schutz, Termination und Lastverteilung nicht als voneinander isolierte Einzelprodukte betrachtet werden müssen. Souveränität entsteht trotzdem nicht durch die Funktionsliste, sondern durch die Frage, wer Konfiguration, Betrieb und Reaktion auf Fehler verantwortet.\u003c/p\u003e\n\u003ch2 id=\"4-providerunabhängigkeit-erfordert-klare-grenzen-und-abhängigkeiten\"\u003e4. Providerunabhängigkeit erfordert klare Grenzen und Abhängigkeiten\u003c/h2\u003e\n\u003cp\u003eEine souveräne Netzwerkarchitektur muss Abhängigkeiten sichtbar machen, statt sie lediglich zu verlagern. Auch bei eigener Infrastruktur bleiben externe Faktoren bestehen: Upstream-Konnektivität, DNS-Delegation, Zertifikatsprozesse, Backend-Provider und organisatorische Zuständigkeiten. Die strategische Entscheidung besteht daher nicht darin, jede Abhängigkeit auszuschließen. Sie besteht darin, kritische Abhängigkeiten zu identifizieren und deren Auswirkungen kontrollieren zu können.\u003c/p\u003e\n\u003cp\u003eFür Unternehmen ist besonders die Trennung von öffentlichem Eingang und Compute relevant. Ein \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n–Cluster bei einem beliebigen Provider muss nicht zwangsläufig die öffentliche Routing- und Schutzschicht bereitstellen. Die Edge kann unabhängig davor betrieben werden und über Health Checks, Failover und definierte Protokolle mit den Backends kommunizieren. Kubernetes-native Integration erleichtert diese Kopplung, ohne die Nutzung auf ayedo Managed Kubernetes zu beschränken.\u003c/p\u003e\n\u003cp\u003eDamit wird digitale Souveränität auch zu einer organisatorischen Frage. Netzwerk-, Plattform- und Anwendungsteams müssen Zuständigkeiten für IPs, DNS, TLS, Security Policies und Backend-Erreichbarkeit festlegen. Erst diese Zuordnung macht Infrastrukturkontrolle im Alltag belastbar und verhindert, dass ein vermeintlich unabhängiges Design an unklaren Betriebsgrenzen scheitert.\u003c/p\u003e\n\u003ch2 id=\"praxisszenario-öffentliche-edge-vor-mehreren-compute-umgebungen\"\u003ePraxisszenario: Öffentliche Edge vor mehreren Compute-Umgebungen\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt seine produktiven \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n–Workloads bei zwei unterschiedlichen Providern. Die öffentliche IP-Adressierung, DNS-Steuerung und der Schutz vor volumetrischen Angriffen sollen jedoch nicht an einen dieser Compute-Provider gebunden sein. Eine eigene Edge-Schicht übernimmt deshalb Anycast-Routing, TLS-Terminierung, WAF und Traffic-Verteilung. Health Checks erkennen, wenn ein Backend nicht verfügbar ist; Failover lenkt Anfragen auf die verbleibende Umgebung.\u003c/p\u003e\n\u003cp\u003eDer Architekturvergleich ist eindeutig: Ohne eigenständige Edge werden Routing und Schutz eng an die jeweilige Compute-Plattform gekoppelt. Mit einer Plattform wie der ayedo Edge Cloud bleiben die Backends austauschbar, während öffentliche Erreichbarkeit und Schutz zentral organisiert werden. Die Verantwortung für die Edge bleibt dabei eine bewusste Betriebsentscheidung.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"ist-ein-eigenes-autonomous-system-gleichbedeutend-mit-digitaler-souveränität\"\u003eIst ein eigenes Autonomous System gleichbedeutend mit digitaler Souveränität?\u003c/h3\u003e\n\u003cp\u003eNein. Es schafft einen wichtigen Kontrollpunkt für Routing, genügt allein aber nicht. DNS, IP-Adressierung, Schutzfunktionen, Betriebsprozesse und externe Abhängigkeiten müssen ebenfalls bewertet werden.\u003c/p\u003e\n\u003ch3 id=\"muss-die-compute-infrastruktur-beim-gleichen-anbieter-liegen\"\u003eMuss die Compute-Infrastruktur beim gleichen Anbieter liegen?\u003c/h3\u003e\n\u003cp\u003eNein. Eine eigenständige Edge-Schicht kann eigene oder bei anderen Providern betriebene \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n–Cluster und weitere Backends anbinden.\u003c/p\u003e\n\u003ch3 id=\"welche-rolle-spielt-backend-cloaking\"\u003eWelche Rolle spielt Backend Cloaking?\u003c/h3\u003e\n\u003cp\u003eBackend Cloaking reduziert die direkte öffentliche Sichtbarkeit der Ursprungsinfrastruktur. Dadurch bleibt der öffentliche Zugang an der Edge konzentriert, während Backends kontrollierter erreichbar sind.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eDigitale Souveränität in der Netzwerkarchitektur ist eine Frage überprüfbarer Kontrolle: über Routing, Adressierung, Edge-Schutz, Traffic-Verteilung und Betriebsprozesse. Ein eigenes \u003ca href=\"/kubernetes/\"\u003eAutonomous System\u003c/a\u003e\n und eigene Netzwerkinfrastruktur schaffen dafür eine belastbare Grundlage, sind aber kein Ersatz für klare Verantwortlichkeiten. Die ayedo Edge Cloud ist in diesem Modell eine eigenständige öffentliche Edge-Schicht zwischen Internet und Compute – unabhängig davon, wo die eigentlichen Workloads betrieben werden.\u003c/p\u003e\n", "summary": "\nTL;DR Digitale Souveränität in der öffentlichen Edge-Schicht zeigt sich nicht durch Herkunftsversprechen, sondern durch technische Kontrollpunkte: Wer steuert Routing, IP-Adressierung, Traffic-Verteilung, Schutzfunktionen und den Betrieb? Ein eigenes Autonomous System und eigene Netzwerkinfrastruktur schaffen dafür die architektonische Grundlage – ersetzen aber keine belastbaren Betriebsprozesse.\nEinleitung Eine öffentliche Edge-Schicht ist nur dann strategisch kontrollierbar, wenn Unternehmen nicht ausschließlich von den Routing- und Betriebsentscheidungen eines vorgelagerten Providers abhängen. Die zentrale Architekturfrage lautet deshalb nicht, ob Infrastruktur „aus einer Hand“ stammt, sondern welche technischen Kontrollpunkte tatsächlich selbst beherrscht werden. Ein eigenes Autonomous System und eigene Netzwerkinfrastruktur beeinflussen, wie Traffic angekündigt, verteilt, geschützt und bei Ausfällen umgeleitet wird. Digitale Souveränität wird damit zu einer konkreten Frage der Netzwerkarchitektur und Betriebsverantwortung. Sie entsteht dort, wo Routing, Adressierung und Edge-Funktionen nachvollziehbar zugeordnet und unabhängig von einzelnen Compute-Umgebungen betrieben werden können.\n", "image": "https://ayedo.de/eigene-netzwerkarchitektur-und-digitale-souveranitat.png", "date_published": "2026-09-04T22:12:59Z", "date_modified": "2026-09-04T22:12:59Z", "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}], "tags": ["digital-sovereignty","kubernetes","politics","operations","hosting"], "language": "de" },{ "id": "https://ayedo.de/posts/kubernetes-hinter-der-edge-integration-ohne-providerbindung/", "url": "https://ayedo.de/posts/kubernetes-hinter-der-edge-integration-ohne-providerbindung/", "title": "Kubernetes hinter der Edge: Integration ohne Providerbindung", "content_html": "\u003cp\u003e\u003cimg src=\"/posts/kubernetes-hinter-der-edge-integration-ohne-providerbindung/kubernetes-hinter-der-edge-integration-ohne-providerbindung.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eKubernetes-Cluster müssen nicht selbst den öffentlichen Traffic-Eingang, DDoS-Schutz oder TLS-Termination betreiben. Eine providerunabhängige Edge-Schicht trennt diese Aufgaben vom Clusterbetrieb. Dadurch lassen sich Cluster bei ayedo, im eigenen Rechenzentrum oder bei anderen Providern über zentrale Routing-, Security- und Failover-Funktionen anbinden.\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 die richtige Stelle, um den gesamten öffentlichen Traffic-Eingang zu organisieren. Werden Ingress, DNS, TLS, DDoS-Schutz und Failover eng an den jeweiligen Cluster oder Cloud-Provider gekoppelt, wird jeder Wechsel des Betriebsmodells aufwendig. Gleichzeitig entstehen unterschiedliche Sicherheits- und Betriebsstandards für einzelne Umgebungen.\u003c/p\u003e\n\u003cp\u003eDie zentrale Architekturentscheidung lautet deshalb: Wo endet die Verantwortung der Edge, und wo beginnt die Verantwortung des Clusters? Eine separate Edge-Schicht beantwortet diese Frage eindeutig. Sie nimmt öffentlichen Traffic an, schützt und verteilt ihn. Kubernetes bleibt für Anwendungen, Services und Workloads zuständig. Diese Trennung ermöglicht Kubernetes Edge Integration über mehrere Betriebsmodelle hinweg, ohne den Traffic-Eingang an einen einzelnen Provider zu binden.\u003c/p\u003e\n\u003ch2 id=\"1-öffentlichen-traffic-und-clusterbetrieb-sauber-trennen\"\u003e1. Öffentlichen Traffic und Clusterbetrieb sauber trennen\u003c/h2\u003e\n\u003cp\u003eKubernetes verwaltet Workloads, Services und deren interne Erreichbarkeit. Der öffentliche Zugang zu diesen Workloads ist dagegen eine vorgelagerte Netzwerk- und Sicherheitsaufgabe. Dazu gehören unter anderem DNS-Auflösung, IP-Ankündigung, Lastverteilung, TLS-Termination, Web Application Firewall und DDoS-Schutz.\u003c/p\u003e\n\u003cp\u003eWerden diese Funktionen ausschließlich innerhalb eines Clusters umgesetzt, hängt der externe Zugriff oft an dessen Ingress-Controller, Loadbalancer-Integration und Netzwerkumgebung. Das kann für einen einzelnen Cluster funktionieren, erschwert aber Multi-Cloud-Szenarien und Migrationen. Ein Wechsel des Clusters wird dann zugleich zu einem Wechsel des öffentlichen Eintrittspunkts.\u003c/p\u003e\n\u003cp\u003eEine Edge-Plattform entkoppelt beide Ebenen. Sie nimmt Verbindungen an und leitet sie an definierte Backends weiter. Das Backend kann ein Service in einem ayedo Managed \u003ca href=\"/kubernetes/\"\u003eKubernetes Cluster\u003c/a\u003e\n, ein eigener Kubernetes-Cluster oder ein Cluster bei einem anderen Provider sein. Der Cluster muss dabei nicht selbst die globale Eingangsschicht bereitstellen.\u003c/p\u003e\n\u003ch2 id=\"2-kubernetes-networking-endet-nicht-an-der-clustergrenze\"\u003e2. Kubernetes Networking endet nicht an der Clustergrenze\u003c/h2\u003e\n\u003cp\u003e\u003ca href=\"/kubernetes/\"\u003eKubernetes Networking\u003c/a\u003e\n wird häufig aus Sicht des Pod- und Service-Netzwerks betrachtet. Für eine belastbare Architektur reicht diese Perspektive nicht aus. Zwischen dem öffentlichen Client und dem Backend liegen weitere Übergänge: DNS, Anycast-Routing, Transport- oder HTTP-Proxying, TLS, Firewall-Regeln und die Erreichbarkeit des Zielsystems.\u003c/p\u003e\n\u003cp\u003eDie Edge Cloud bildet diese vorgelagerte Ebene. Anycast-basiertes Layer-4- und Layer-7-Loadbalancing kann eingehende Verbindungen an geeignete Backends verteilen. Backend Health Checks zeigen, ob ein Ziel erreichbar und betriebsbereit ist. Bei Ausfällen kann Traffic auf alternative Backends oder Cluster gelenkt werden, sofern diese als Ziel vorgesehen sind.\u003c/p\u003e\n\u003cp\u003eFür Kubernetes-Teams bedeutet das: Der öffentliche Service muss nicht an einen einzelnen Provider-Loadbalancer gebunden sein. Die Kubernetes-Integration kann mit unterschiedlichen Clustern und Betriebsmodellen genutzt werden. Internes Service Discovery und die Zuständigkeit des Clusters bleiben davon getrennt.\u003c/p\u003e\n\u003ch2 id=\"3-zentrale-edge-funktionen-über-mehrere-cluster\"\u003e3. Zentrale Edge-Funktionen über mehrere Cluster\u003c/h2\u003e\n\u003cp\u003eMehrere Cluster sind nicht automatisch eine Multi-Cluster-Architektur. Entscheidend ist, ob der öffentliche Zugriff konsistent geregelt wird. Wenn jeder Cluster eigene DNS-Zonen, TLS-Konfigurationen, WAF-Regeln und DDoS-Schutzmechanismen verwendet, entstehen unterschiedliche Betriebsprozesse und schwer vergleichbare Sicherheitsniveaus.\u003c/p\u003e\n\u003cp\u003eEine zentrale Eingangsschicht vereinheitlicht diese Funktionen vor mehreren Clustern. Anycast DNS oder Multi-Provider-DNS können die Namensauflösung und die Verfügbarkeit des Einstiegs unterstützen. TLS kann an der Edge terminiert werden, während Backends gegenüber dem öffentlichen Netz verborgen bleiben. Backend Cloaking reduziert dabei die direkte Sichtbarkeit der Cluster-Endpunkte.\u003c/p\u003e\n\u003cp\u003eDiese Zentralisierung ist nicht nur eine Security-Frage. Sie vereinfacht auch Releases, Migrationen und Failover. Ein Service kann schrittweise auf einen anderen Cluster verschoben werden, während DNS, öffentliche IPs und Edge-Richtlinien stabil bleiben. Mit Bring Your Own IP lässt sich diese Trennung in Umgebungen einordnen, in denen bestehende Adressräume erhalten bleiben sollen.\u003c/p\u003e\n\u003ch2 id=\"4-providerunabhängigkeit-als-betriebsmodell\"\u003e4. Providerunabhängigkeit als Betriebsmodell\u003c/h2\u003e\n\u003cp\u003eProviderunabhängigkeit bedeutet nicht, dass jeder Cluster technisch identisch betrieben werden muss. Ein Cluster im eigenen Rechenzentrum hat andere Netzwerk- und Sicherheitsanforderungen als ein Cluster bei einem Public-Cloud-Provider. Die gemeinsame Ebene liegt am öffentlichen Eingang: Routing, Schutz, Termination, Health Checks und die Auswahl erreichbarer Backends.\u003c/p\u003e\n\u003cp\u003eDie ayedo Edge Cloud bringt dafür eigene Netzwerk-Infrastruktur und ein eigenes Autonomous System in eine verteilte Multi-PoP-Architektur mit Aktiv-Aktiv-Prinzip ein. Diese Eigenschaften sind relevant, weil der öffentliche Traffic-Eingang nicht an die Netzwerkgrenzen eines einzelnen Kubernetes-Providers gekoppelt wird. Der Compute-Standort und die Edge-Verantwortung bleiben getrennte Architekturentscheidungen.\u003c/p\u003e\n\u003cp\u003eFür Organisationen reduziert das die Abhängigkeit von providerbezogenen Ingress- und Loadbalancer-Mechanismen. Gleichzeitig bleibt die Verantwortung klar: Die Edge schützt und verteilt den Traffic; das jeweilige Plattformteam betreibt Cluster, Nodes, Workloads und interne Services. Diese Aufteilung erleichtert Governance und macht Kosten sowie Betriebsaufwand den richtigen Verantwortungsbereichen zuordenbar.\u003c/p\u003e\n\u003ch2 id=\"praxis--und-betriebsszenario\"\u003ePraxis- und Betriebsszenario\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt einen Kubernetes-Cluster im eigenen Rechenzentrum und nutzt zusätzlich einen Cluster bei einem Cloud-Provider. Beide stellen dieselbe API bereit. Statt zwei öffentliche Eingangsschichten mit unterschiedlichen Zertifikaten, WAF-Regeln und DNS-Prozessen zu betreiben, werden beide Cluster als Backends an eine gemeinsame Edge angebunden.\u003c/p\u003e\n\u003cp\u003eDie Edge übernimmt TLS-Termination, WAF und DDoS-Schutz. Health Checks erkennen, ob die API in einem Cluster verfügbar ist. Für eine Migration kann der Traffic zunächst teilweise auf den neuen Cluster verteilt werden. Fällt ein Ziel aus, wird der verbleibende Traffic zum gesunden Backend geleitet. Der Clusterbetrieb bleibt dabei unabhängig vom Anbieter der jeweils anderen Umgebung.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"ist-kubernetes-edge-integration-nur-mit-ayedo-managed-kubernetes-möglich\"\u003eIst Kubernetes Edge Integration nur mit ayedo Managed Kubernetes möglich?\u003c/h3\u003e\n\u003cp\u003eNein. Die Edge Cloud kann auch mit eigenen Kubernetes-Clustern oder Clustern bei anderen Providern genutzt werden. Entscheidend ist die Erreichbarkeit und Definition der Backends, nicht deren Betreiber.\u003c/p\u003e\n\u003ch3 id=\"ersetzt-die-edge-den-kubernetes-ingress\"\u003eErsetzt die Edge den Kubernetes Ingress?\u003c/h3\u003e\n\u003cp\u003eNicht grundsätzlich. Die Edge übernimmt den öffentlichen Eingang. Ein Ingress oder Gateway innerhalb des Clusters kann weiterhin für internes Routing und anwendungsspezifische Regeln zuständig sein.\u003c/p\u003e\n\u003ch3 id=\"unterstützt-der-ansatz-multi-cloud\"\u003eUnterstützt der Ansatz Multi-Cloud?\u003c/h3\u003e\n\u003cp\u003eJa, sofern die beteiligten Cluster als erreichbare Backends angebunden werden. Die Edge kann damit einen gemeinsamen öffentlichen Zugang vor Umgebungen unterschiedlicher Provider bilden.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eKubernetes und öffentlicher Traffic-Eingang sollten als getrennte Verantwortungsbereiche modelliert werden. Diese Trennung schafft ein einheitliches Sicherheits- und Routingmodell vor Clustern in unterschiedlichen Betriebsumgebungen. Providerunabhängigkeit entsteht dabei nicht durch identische Cluster, sondern durch eine stabile Eingangsschicht zwischen Internet und Compute. Die ayedo Edge Cloud ist in diesem Modell die zentrale Plattform für Routing, Schutz und Verteilung vor ayedo-, On-Premises- und Drittanbieter-\u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n.\u003c/p\u003e\n", "summary": "\nTL;DR Kubernetes-Cluster müssen nicht selbst den öffentlichen Traffic-Eingang, DDoS-Schutz oder TLS-Termination betreiben. Eine providerunabhängige Edge-Schicht trennt diese Aufgaben vom Clusterbetrieb. Dadurch lassen sich Cluster bei ayedo, im eigenen Rechenzentrum oder bei anderen Providern über zentrale Routing-, Security- und Failover-Funktionen anbinden.\nEinleitung Ein Kubernetes-Cluster ist nicht automatisch die richtige Stelle, um den gesamten öffentlichen Traffic-Eingang zu organisieren. Werden Ingress, DNS, TLS, DDoS-Schutz und Failover eng an den jeweiligen Cluster oder Cloud-Provider gekoppelt, wird jeder Wechsel des Betriebsmodells aufwendig. Gleichzeitig entstehen unterschiedliche Sicherheits- und Betriebsstandards für einzelne Umgebungen.\n", "image": "https://ayedo.de/kubernetes-hinter-der-edge-integration-ohne-providerbindung.png", "date_published": "2026-09-04T22:12:59Z", "date_modified": "2026-09-04T22:12:59Z", "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}], "tags": ["kubernetes","security","cloud-native","hosting","digital-sovereignty"], "language": "de" },{ "id": "https://ayedo.de/posts/anycast-und-loadbalancing-als-fundament-der-edge-architektur/", "url": "https://ayedo.de/posts/anycast-und-loadbalancing-als-fundament-der-edge-architektur/", "title": "Anycast und Loadbalancing als Fundament der Edge-Architektur", "content_html": "\u003cp\u003e\u003cimg src=\"/posts/anycast-und-loadbalancing-als-fundament-der-edge-architektur/anycast-und-loadbalancing-als-fundament-der-edge-architektur.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eAnycast Loadbalancing verbindet globale Erreichbarkeit mit gezielter Verkehrsverteilung. Anycast entscheidet, welcher Edge-PoP eine Anfrage übernimmt, während Layer-4- und Layer-7-Loadbalancing den Traffic dort anhand von Verbindungen, Protokollen und Anwendungsmerkmalen weiterleiten. Erst das Zusammenspiel schafft einen belastbaren öffentlichen Zugang zu Anwendungen und APIs.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eEin global erreichbarer Dienst ist nicht automatisch resilient. Häufig wird Anycast mit Loadbalancing gleichgesetzt, obwohl beide unterschiedliche Aufgaben erfüllen: Anycast beeinflusst den Netzpfad zu einer Edge-Instanz, Loadbalancing verteilt den bereits angenommenen Traffic auf verfügbare Backends. Werden diese Ebenen nicht getrennt betrachtet, entstehen unklare Failover-Mechanismen, unnötige Abhängigkeiten vom Provider-Netzwerk und schwer kontrollierbare Betriebszustände. Eine belastbare Edge-Architektur muss deshalb Routing, Protokollebene und Backend-Zustand gemeinsam modellieren. Anycast Loadbalancing ist dabei kein einzelner Mechanismus, sondern die Verbindung mehrerer Steuerungsebenen.\u003c/p\u003e\n\u003ch2 id=\"1-anycast-bestimmt-den-zugang-zur-edge\"\u003e1. Anycast bestimmt den Zugang zur Edge\u003c/h2\u003e\n\u003cp\u003eBei Anycast verwenden mehrere geografisch verteilte Netzwerkknoten dieselbe IP-Adresse oder dasselbe Präfix. Das Internet-Routing entscheidet, welcher Knoten aus Sicht des Netzes bevorzugt erreicht wird. Diese Entscheidung basiert nicht auf der Auslastung einer einzelnen Anwendung, sondern auf Routinginformationen und der Topologie zwischen Client und Edge.\u003c/p\u003e\n\u003cp\u003eFür den öffentlichen Zugang reduziert das die Notwendigkeit, einzelne Standorte direkt zu adressieren. Fällt ein Edge-PoP aus oder wird aus dem Routing genommen, kann der Traffic zu einer anderen verfügbaren Instanz gelangen. Das setzt voraus, dass die Edge-Infrastruktur an mehreren Punkten präsent ist und den Traffic dort konsistent verarbeitet.\u003c/p\u003e\n\u003cp\u003eAnycast ersetzt jedoch weder Health Checks noch Backend-Failover. Ein erreichbarer Edge-PoP kann weiterhin zu einem nicht verfügbaren Backend weiterleiten. Deshalb müssen Netzverfügbarkeit und Anwendungsverfügbarkeit getrennt überwacht werden. Die ayedo Edge Cloud nutzt dafür eine verteilte Multi-PoP-Architektur, ein eigenes Autonomous System und ein Aktiv-Aktiv-Prinzip. Diese Eigenschaften bilden die infrastrukturelle Grundlage, auf der weitere Traffic-Entscheidungen stattfinden.\u003c/p\u003e\n\u003ch2 id=\"2-layer-4-verteilt-verbindungen-layer-7-anfragen\"\u003e2. Layer 4 verteilt Verbindungen, Layer 7 Anfragen\u003c/h2\u003e\n\u003cp\u003eLayer-4-Loadbalancing arbeitet auf Transportebene, typischerweise anhand von TCP- oder UDP-Verbindungen. Es kann neue Verbindungen auf verfügbare Ziele verteilen, ohne den Inhalt einer Anwendung interpretieren zu müssen. Das ist besonders relevant für Protokolle, bei denen eine tiefere Analyse nicht erforderlich oder nicht möglich ist.\u003c/p\u003e\n\u003cp\u003eLayer-7-Loadbalancing verarbeitet dagegen Anwendungsprotokolle wie HTTP oder HTTPS. Dadurch können Hostnames, Pfade oder weitere Eigenschaften einer Anfrage in die Weiterleitungsentscheidung einfließen. Gleichzeitig entstehen zusätzliche Anforderungen an TLS-Verarbeitung, Protokollverständnis und Zustandsmanagement.\u003c/p\u003e\n\u003cp\u003eDie Ebenen sind nicht austauschbar. Layer 4 bietet eine geringe semantische Tiefe und eignet sich für generische, performante Weiterleitung. Layer 7 ermöglicht präzisere Regeln, koppelt die Edge aber stärker an das Anwendungsprotokoll. Eine Edge-Plattform muss daher beide Modelle unterstützen, statt jedes Problem auf HTTP-Routing zu reduzieren. Die ayedo Edge Cloud verbindet Anycast-basiertes Layer-4- und Layer-7-Loadbalancing mit TLS Termination an der Edge, sofern eine anwendungsbezogene Verarbeitung erforderlich ist.\u003c/p\u003e\n\u003ch2 id=\"3-traffic-routing-endet-nicht-am-edge-pop\"\u003e3. Traffic-Routing endet nicht am Edge-PoP\u003c/h2\u003e\n\u003cp\u003eNachdem Anycast einen Edge-PoP ausgewählt hat, beginnt die eigentliche Verteilung innerhalb der Edge. Dort wird entschieden, welche Backend-Gruppe eine Verbindung oder Anfrage erhält. Dafür sind nicht nur statische Konfigurationen relevant. Health Checks müssen erkennen, ob ein Ziel technisch erreichbar und für den jeweiligen Dienst tatsächlich nutzbar ist.\u003c/p\u003e\n\u003cp\u003eDiese Unterscheidung ist für APIs und zustandsbehaftete Anwendungen wichtig. Ein offener TCP-Port sagt wenig darüber aus, ob ein Dienst korrekte Antworten liefert. Werden fehlerhafte Backends nicht aus dem Pool entfernt, verteilt die Edge zwar technisch korrekt, aber betrieblich falsch. Failover muss deshalb an Backend-Zustände gekoppelt werden, nicht nur an die Erreichbarkeit des Edge-PoPs.\u003c/p\u003e\n\u003cp\u003eZusätzlich kann die Edge die eigentlichen Backend-Adressen verbergen. Backend Cloaking reduziert die direkte Exponierung der Compute-Infrastruktur und trennt den öffentlichen Eingang vom internen Ziel. In der ayedo Edge Cloud lassen sich eigene oder bei anderen Providern betriebene \u003ca href=\"/kubernetes/\"\u003eKubernetes-Cluster\u003c/a\u003e\n ebenso anbinden wie ayedo Managed Kubernetes. Die Edge-Funktionen bleiben damit vom jeweiligen Compute-Standort getrennt.\u003c/p\u003e\n\u003ch2 id=\"4-verteilte-edge-architektur-verändert-den-betrieb\"\u003e4. Verteilte Edge-Architektur verändert den Betrieb\u003c/h2\u003e\n\u003cp\u003eAnycast Loadbalancing verschiebt einen Teil der Betriebsverantwortung aus dem einzelnen Rechenzentrum an die verteilte Edge. Das verbessert die Trennung von öffentlichem Traffic und Compute, erhöht aber die Anforderungen an Beobachtbarkeit und Fehleranalyse. Bei einer Störung müssen Teams unterscheiden können, ob das Problem im globalen Routing, im Edge-PoP, in der Transportverbindung oder im Backend liegt.\u003c/p\u003e\n\u003cp\u003eAuch Sicherheitsfunktionen profitieren von dieser Trennung. DDoS Protection und Scrubbing können Traffic vor dem Backend abfangen. Eine Web Application Firewall kann HTTP- und HTTPS-Anfragen an der Edge prüfen, bevor sie interne Dienste erreichen. Das reduziert die Menge und den Risikoumfang des Traffics, der bis zur Compute-Infrastruktur weitergeleitet wird.\u003c/p\u003e\n\u003cp\u003eArchitektonisch entsteht damit eine klare Verantwortungsteilung: Die Edge übernimmt öffentlichen Eingang, Routing, Schutz, Termination und Lastverteilung. Die Compute-Infrastruktur führt Anwendungen und Workloads aus. Für Plattformteams ist diese Trennung relevant, weil ein \u003ca href=\"/kubernetes/\"\u003eKubernetes-Cluster\u003c/a\u003e\n dadurch nicht zwingend selbst globales Routing, Schutz und öffentliche Exponierung organisieren muss. Gleichzeitig bleibt die Kubernetes-Integration providerunabhängig nutzbar.\u003c/p\u003e\n\u003ch2 id=\"betriebsszenario-ein-api-dienst-mit-zwei-backend-standorten\"\u003eBetriebsszenario: Ein API-Dienst mit zwei Backend-Standorten\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt eine API in zwei \u003ca href=\"/kubernetes/\"\u003eKubernetes-Clustern\u003c/a\u003e\n bei unterschiedlichen Providern. Beide Cluster sind über dieselbe Edge-Adresse erreichbar. Anycast führt Clients zu einem verfügbaren Edge-PoP. Dort übernimmt Layer 7 die HTTPS-Verarbeitung und ordnet die Anfrage dem passenden API-Service zu. Health Checks erkennen, dass ein Cluster zwar Netzwerkverbindungen annimmt, aber keine gültigen Antworten mehr liefert. Dieses Backend wird aus der Weiterleitung genommen; der Traffic geht an den verbleibenden Standort.\u003c/p\u003e\n\u003cp\u003eOhne diese Trennung müsste der Client oder ein vorgelagerter DNS-Mechanismus die Störung erkennen. Das verlängert die Umschaltzeit und verteilt die Verantwortung über mehrere Systeme. Die Edge bündelt dagegen Routing, Termination, Health Checks und Failover an einem öffentlichen Eingang, während die Cluster ihre Rolle als Compute-Ziele behalten.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"ist-anycast-bereits-loadbalancing\"\u003eIst Anycast bereits Loadbalancing?\u003c/h3\u003e\n\u003cp\u003eNein. Anycast beeinflusst, welcher Netzwerkknoten erreicht wird. Loadbalancing verteilt Traffic innerhalb der erreichten Infrastruktur auf Verbindungen, Services oder 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 von HTTP- oder HTTPS-Merkmalen abhängen, etwa Hostnames oder Pfaden. Für generische TCP- oder UDP-Verbindungen reicht häufig Layer 4.\u003c/p\u003e\n\u003ch3 id=\"muss-die-anwendung-in-einem-ayedo-kubernetes-cluster-laufen\"\u003eMuss die Anwendung in einem ayedo Kubernetes-Cluster laufen?\u003c/h3\u003e\n\u003cp\u003eNein. Die ayedo Edge Cloud kann auch mit eigenen oder bei anderen Providern betriebenen \u003ca href=\"/kubernetes/\"\u003eKubernetes-Clustern\u003c/a\u003e\n genutzt werden.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eAnycast Loadbalancing ist ein Architekturmodell für mehrere Ebenen: Globales Routing bringt den Traffic zu einer verfügbaren Edge-Instanz, Layer 4 oder Layer 7 verteilt ihn dort weiter, und Health Checks binden diese Entscheidungen an den Zustand der Backends. Für Unternehmen entsteht dadurch eine klare Trennung zwischen öffentlichem Zugang und Compute. Die ayedo Edge Cloud setzt dieses Prinzip als verteilte, aktiv-aktive Edge-Plattform mit eigener Netzwerkinfrastruktur und providerunabhängiger Backend-Anbindung um.\u003c/p\u003e\n", "summary": "\nTL;DR Anycast Loadbalancing verbindet globale Erreichbarkeit mit gezielter Verkehrsverteilung. Anycast entscheidet, welcher Edge-PoP eine Anfrage übernimmt, während Layer-4- und Layer-7-Loadbalancing den Traffic dort anhand von Verbindungen, Protokollen und Anwendungsmerkmalen weiterleiten. Erst das Zusammenspiel schafft einen belastbaren öffentlichen Zugang zu Anwendungen und APIs.\nEinleitung Ein global erreichbarer Dienst ist nicht automatisch resilient. Häufig wird Anycast mit Loadbalancing gleichgesetzt, obwohl beide unterschiedliche Aufgaben erfüllen: Anycast beeinflusst den Netzpfad zu einer Edge-Instanz, Loadbalancing verteilt den bereits angenommenen Traffic auf verfügbare Backends. Werden diese Ebenen nicht getrennt betrachtet, entstehen unklare Failover-Mechanismen, unnötige Abhängigkeiten vom Provider-Netzwerk und schwer kontrollierbare Betriebszustände. Eine belastbare Edge-Architektur muss deshalb Routing, Protokollebene und Backend-Zustand gemeinsam modellieren. Anycast Loadbalancing ist dabei kein einzelner Mechanismus, sondern die Verbindung mehrerer Steuerungsebenen.\n", "image": "https://ayedo.de/anycast-und-loadbalancing-als-fundament-der-edge-architektur.png", "date_published": "2026-09-04T22:12:58Z", "date_modified": "2026-09-04T22:12:58Z", "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}], "tags": ["cloud-native","development","operations","kubernetes","hosting"], "language": "de" },{ "id": "https://ayedo.de/posts/backend-cloaking-und-proxy-protocol-in-der-edge-architektur/", "url": "https://ayedo.de/posts/backend-cloaking-und-proxy-protocol-in-der-edge-architektur/", "title": "Backend Cloaking und Proxy Protocol in der Edge-Architektur", "content_html": "\u003cp\u003e\u003cimg src=\"/posts/backend-cloaking-und-proxy-protocol-in-der-edge-architektur/backend-cloaking-und-proxy-protocol-in-der-edge-architektur.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eBackend Cloaking trennt die öffentlich erreichbare Eintrittsschicht von den eigentlichen Anwendungs- und API-Backends. Dadurch bleiben interne Zieladressen gegenüber Clients verborgen. Proxy Protocol ergänzt diese Entkopplung, indem Verbindungsinformationen kontrolliert an das Backend weitergegeben werden können. Entscheidend ist die Kombination aus Edge-Proxy, Netzwerkregeln und eindeutig definierten Vertrauensgrenzen.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eEin Backend, dessen öffentliche IP-Adresse direkt aus dem Internet erreichbar ist, bleibt trotz vorgeschalteter Schutzmechanismen ein eigenständiger Angriffspunkt. Ein zentraler Architekturfehler besteht darin, die Edge lediglich als Loadbalancer zu verwenden, während Clients weiterhin die eigentlichen Backends adressieren können. Backend Cloaking verfolgt einen anderen Ansatz: Die öffentliche Eintrittsschicht nimmt Verbindungen entgegen und vermittelt sie an nicht öffentlich exponierte Zielsysteme. Damit entsteht eine klare Trennung zwischen Clientzugang und Backend-Netzwerk. Proxy Protocol kann diese Trennung ergänzen, wenn Backends Informationen über die ursprüngliche Verbindung benötigen, ohne selbst direkt mit dem Client zu kommunizieren.\u003c/p\u003e\n\u003ch2 id=\"1-backend-cloaking-als-entkopplung-der-netzebenen\"\u003e1. Backend Cloaking als Entkopplung der Netzebenen\u003c/h2\u003e\n\u003cp\u003eBeim Backend Cloaking kennen externe Clients nur den öffentlichen Endpoint der Edge. Die Adressen der eigentlichen Backends werden nicht als direkte Zieladressen verwendet und müssen nicht öffentlich beworben werden. Der Edge-Proxy übernimmt die Annahme des Traffics, die Weiterleitung und – abhängig vom Protokoll und der Konfiguration – weitere Funktionen wie TLS Termination oder Loadbalancing.\u003c/p\u003e\n\u003cp\u003eWichtig ist die technische Abgrenzung: Das Verbergen einer Backend-Adresse ersetzt keine Zugriffskontrolle. Ein Backend bleibt nur dann tatsächlich geschützt, wenn eingehende Verbindungen auf definierte Quellen, Ports und Protokolle beschränkt werden. In einer belastbaren Architektur akzeptiert das Backend daher nicht beliebige Internetverbindungen, sondern ausschließlich den vorgesehenen Pfad über die Edge.\u003c/p\u003e\n\u003cp\u003eDie ayedo Edge Cloud bildet für diesen Ansatz eine öffentliche Eintrittsschicht zwischen Clients und Backends. Sie kann mit eigenen oder bei anderen Providern betriebenen \u003ca href=\"/kubernetes/\"\u003eKubernetes-Clustern\u003c/a\u003e\n eingesetzt werden und ist damit nicht auf eine bestimmte Compute-Umgebung begrenzt.\u003c/p\u003e\n\u003ch2 id=\"2-proxy-protocol-verbindungsinformationen-kontrolliert-weitergeben\"\u003e2. Proxy Protocol: Verbindungsinformationen kontrolliert weitergeben\u003c/h2\u003e\n\u003cp\u003eEin Proxy verändert die direkte Netzwerkbeziehung zwischen Client und Backend. Das Backend sieht zunächst die Verbindung des Proxy-Systems, nicht zwingend die ursprüngliche Clientverbindung. Für Logging, Rate-Limiting, Zugriffsentscheidungen oder forensische Analysen kann die ursprüngliche Quelladresse jedoch relevant sein.\u003c/p\u003e\n\u003cp\u003eProxy Protocol löst dieses Problem, indem der Proxy Verbindungsinformationen am Beginn der Backend-Verbindung übermittelt. Das Backend kann daraus beispielsweise die ursprüngliche Client-IP und weitere transportbezogene Angaben auswerten. Die Anwendung muss dadurch nicht zwangsläufig auf Header wie \u003ccode\u003eX-Forwarded-For\u003c/code\u003e vertrauen, insbesondere wenn der Traffic nicht auf HTTP beschränkt ist.\u003c/p\u003e\n\u003cp\u003eDie Funktion setzt voraus, dass das Backend Proxy Protocol erwartet und die Quelle dieser Metadaten vertrauenswürdig ist. Wird das Protokoll an einem nicht dafür vorgesehenen Endpoint aktiviert, kann die Verbindung fehlschlagen. Wird die Information ungeprüft von beliebigen Clients akzeptiert, entstehen Manipulationsrisiken. Proxy Protocol ist deshalb kein allgemeiner Sicherheitsmechanismus, sondern ein Bestandteil einer klar definierten Proxy-zu-Backend-Verbindung.\u003c/p\u003e\n\u003ch2 id=\"3-vertrauensgrenzen-zwischen-edge-und-backend\"\u003e3. Vertrauensgrenzen zwischen Edge und Backend\u003c/h2\u003e\n\u003cp\u003eBackend Cloaking verschiebt die zentrale Vertrauensgrenze: Das Backend vertraut nicht mehr jedem Client, sondern einem kontrollierten vorgelagerten Dienst. Diese Vereinfachung funktioniert nur, wenn die Edge selbst korrekt als einziger öffentlicher Einstiegspunkt behandelt wird. Dazu gehören geeignete Netzwerkfilter, konsistente Routingregeln und eine eindeutige Konfiguration der Backend-Listener.\u003c/p\u003e\n\u003cp\u003eBesondere Aufmerksamkeit erfordert die Kombination mit TLS Termination. Wird TLS an der Edge beendet, erhält das Backend typischerweise eine neue Verbindung. Für die Anwendung muss geklärt sein, ob sie den ursprünglichen Verschlüsselungszustand, den Hostnamen oder die Clientidentität benötigt. Proxy Protocol übergibt Transportinformationen, ersetzt aber keine anwendungsspezifische Authentisierung und beweist nicht automatisch die Identität des Clients.\u003c/p\u003e\n\u003cp\u003eDie ayedo Edge Cloud kann diese vermittelnde Rolle für HTTP-/HTTPS-Services sowie Layer-4-Verbindungen einnehmen. Backend Cloaking, Health Checks und Failover müssen dabei als zusammenhängende Betriebslogik betrachtet werden: Ein verborgenes Backend ist nur nützlich, wenn erreichbare und gesunde Zielsysteme zuverlässig erkannt und angesprochen werden.\u003c/p\u003e\n\u003ch2 id=\"4-betriebsfolgen-für-plattform--und-sicherheitsteams\"\u003e4. Betriebsfolgen für Plattform- und Sicherheitsteams\u003c/h2\u003e\n\u003cp\u003eDie Entkopplung reduziert nicht nur die öffentliche Angriffsfläche, sondern verändert auch den Betrieb. Deployments können Backend-Adressen, Cluster oder Provider wechseln, ohne dass Clients ihre Zieladresse ändern müssen. Für Plattformteams entsteht damit eine stabile öffentliche Schicht vor variablen Compute-Ressourcen. Das ist besonders relevant bei \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n, wo Services, Nodes und Ingress-Pfade dynamisch sein können.\u003c/p\u003e\n\u003cp\u003eGleichzeitig steigt die Verantwortung an der Edge. Eine fehlerhafte ACL, ein falsch konfigurierter Listener oder ein nicht kompatibler Proxy-Protocol-Modus kann mehrere Anwendungen gleichzeitig beeinträchtigen. Monitoring muss deshalb beide Seiten abdecken: die Erreichbarkeit des öffentlichen Endpoints und die tatsächliche Kommunikation zwischen Edge und Backend. Traffic- und Usage-Statistiken helfen bei der Einordnung, ersetzen aber keine anwendungsbezogene Protokollierung.\u003c/p\u003e\n\u003cp\u003eEine verteilte, aktiv-aktive Edge-Architektur kann die Eintrittsschicht über mehrere PoPs betreiben. Dadurch wird der öffentliche Zugang nicht an einen einzelnen Proxy-Standort gebunden. Für Unternehmen ist diese Trennung auch organisatorisch relevant: Netzwerk- und Security-Teams kontrollieren die Edge, während Anwendungsteams ihre Backends betreiben, ohne sie direkt öffentlich exponieren zu müssen.\u003c/p\u003e\n\u003ch2 id=\"betriebsszenario-öffentliches-api-privates-kubernetes-backend\"\u003eBetriebsszenario: Öffentliches API, privates Kubernetes-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. Ohne Cloaking zeigt der öffentliche DNS-Eintrag direkt auf einen Ingress oder Loadbalancer im Cluster. Ein Angreifer kann dadurch den vorgesehenen Zugangsweg umgehen, sobald die Backend-Adresse bekannt ist.\u003c/p\u003e\n\u003cp\u003eMit einer Edge-Schicht zeigt der DNS-Eintrag ausschließlich auf den öffentlichen Edge-Endpoint. Die Edge beendet optional TLS und leitet die Verbindung an einen privaten Backend-Pfad weiter. Netzwerkregeln erlauben dort nur Verbindungen aus dem definierten Edge-Netz. Aktiviert das Backend Proxy Protocol, kann es die ursprüngliche Client-IP für Logs und Richtlinien verwenden. Wechselt der Cluster später den Provider, bleibt der öffentliche Endpoint unverändert; angepasst werden nur die internen Zielparameter und die Zugriffskontrollen.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"verhindert-backend-cloaking-jeden-direkten-zugriff-auf-das-backend\"\u003eVerhindert Backend Cloaking jeden direkten Zugriff auf das Backend?\u003c/h3\u003e\n\u003cp\u003eNein. Es verbirgt den vorgesehenen Backend-Pfad. Effektiver Schutz entsteht erst durch Netzwerkregeln, die direkte Internetverbindungen unterbinden und ausschließlich den kontrollierten Edge-Zugang erlauben.\u003c/p\u003e\n\u003ch3 id=\"ist-proxy-protocol-nur-für-http-geeignet\"\u003eIst Proxy Protocol nur für HTTP geeignet?\u003c/h3\u003e\n\u003cp\u003eNein. Proxy Protocol arbeitet auf der Verbindungsebene und kann auch bei Layer-4-Szenarien relevant sein. Voraussetzung ist, dass der jeweilige Backend-Dienst das Protokoll korrekt unterstützt und erwartet.\u003c/p\u003e\n\u003ch3 id=\"kann-die-edge-vor-jedem-kubernetes-cluster-eingesetzt-werden\"\u003eKann die Edge vor jedem Kubernetes-Cluster eingesetzt werden?\u003c/h3\u003e\n\u003cp\u003eJa, die Integration ist nicht auf ayedo Managed Kubernetes beschränkt. Die Edge Cloud kann auch vor eigenen oder bei anderen Providern betriebenen \u003ca href=\"/kubernetes/\"\u003eKubernetes-Clustern\u003c/a\u003e\n eingesetzt werden.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eBackend Cloaking ist ein Architekturprinzip zur konsequenten Trennung von öffentlichem Zugang und interner Ausführung. Es reduziert die direkte Exponierung der Backends, ersetzt aber keine Netzwerksegmentierung oder Zugriffskontrolle. Proxy Protocol ergänzt diesen Ansatz, wenn ursprüngliche Verbindungsinformationen am Backend benötigt werden. Eine Edge-Plattform wie die ayedo Edge Cloud bündelt diese Vermittlungsfunktion providerunabhängig vor Anwendungen und APIs und schafft damit eine kontrollierbare Eintrittsschicht zwischen Internet und Compute-Infrastruktur.\u003c/p\u003e\n", "summary": "\nTL;DR Backend Cloaking trennt die öffentlich erreichbare Eintrittsschicht von den eigentlichen Anwendungs- und API-Backends. Dadurch bleiben interne Zieladressen gegenüber Clients verborgen. Proxy Protocol ergänzt diese Entkopplung, indem Verbindungsinformationen kontrolliert an das Backend weitergegeben werden können. Entscheidend ist die Kombination aus Edge-Proxy, Netzwerkregeln und eindeutig definierten Vertrauensgrenzen.\nEinleitung Ein Backend, dessen öffentliche IP-Adresse direkt aus dem Internet erreichbar ist, bleibt trotz vorgeschalteter Schutzmechanismen ein eigenständiger Angriffspunkt. Ein zentraler Architekturfehler besteht darin, die Edge lediglich als Loadbalancer zu verwenden, während Clients weiterhin die eigentlichen Backends adressieren können. Backend Cloaking verfolgt einen anderen Ansatz: Die öffentliche Eintrittsschicht nimmt Verbindungen entgegen und vermittelt sie an nicht öffentlich exponierte Zielsysteme. Damit entsteht eine klare Trennung zwischen Clientzugang und Backend-Netzwerk. Proxy Protocol kann diese Trennung ergänzen, wenn Backends Informationen über die ursprüngliche Verbindung benötigen, ohne selbst direkt mit dem Client zu kommunizieren.\n", "image": "https://ayedo.de/backend-cloaking-und-proxy-protocol-in-der-edge-architektur.png", "date_published": "2026-09-04T22:12:58Z", "date_modified": "2026-09-04T22:12:58Z", "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}], "tags": ["cloud-native","development","kubernetes","digital-sovereignty","software-delivery"], "language": "de" },{ "id": "https://ayedo.de/posts/dns-tls-und-waf-zusammenspiel-am-offentlichen-eingang/", "url": "https://ayedo.de/posts/dns-tls-und-waf-zusammenspiel-am-offentlichen-eingang/", "title": "DNS, TLS und WAF: Zusammenspiel am öffentlichen Eingang", "content_html": "\u003cp\u003e\u003cimg src=\"/posts/dns-tls-und-waf-zusammenspiel-am-offentlichen-eingang/dns-tls-und-waf-zusammenspiel-am-offentlichen-eingang.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eDNS, TLS und WAF erfüllen am öffentlichen Eingang unterschiedliche Aufgaben, wirken aber als gemeinsame Verarbeitungskette. Anycast DNS und Multi-Provider-DNS führen Anfragen zur Edge, TLS-Termination macht verschlüsselten Traffic prüfbar, und die Web Application Firewall bewertet HTTP-/HTTPS-Anfragen. Entscheidend ist nicht die Einzelfunktion, sondern ihr Zusammenspiel.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eEin häufiger Architekturfehler besteht darin, DNS, TLS und WAF als separat buchbare Dienste zu betrachten. Dann wird DNS lediglich als Verweis auf einen Endpoint konfiguriert, TLS an irgendeiner Stelle beendet und die WAF nachträglich vor ein Backend gesetzt. Das erschwert Fehleranalyse, Failover und Sicherheitsbewertung. Technisch handelt es sich um eine Verarbeitungskette: DNS bestimmt den Einstiegspunkt, TLS authentifiziert und verschlüsselt die Verbindung, und die WAF analysiert den entschlüsselten HTTP-/HTTPS-Verkehr. Eine Edge-Plattform muss diese Übergänge kontrolliert abbilden, bevor Anfragen die eigentlichen Backends erreichen.\u003c/p\u003e\n\u003ch2 id=\"1-dns-bestimmt-wo-die-verarbeitung-beginnt\"\u003e1. DNS bestimmt, wo die Verarbeitung beginnt\u003c/h2\u003e\n\u003cp\u003eDNS entscheidet nicht über die fachliche Zulässigkeit einer Anfrage, sondern darüber, welcher öffentliche Eingang erreicht wird. Bei Anycast DNS kann derselbe Dienst über mehrere Netzwerkstandorte angekündigt werden. Routing auf Netzwerkebene führt die Anfrage typischerweise zu einer geeigneten erreichbaren Instanz. Dadurch wird DNS Teil der Erreichbarkeitsarchitektur und nicht nur ein Verzeichnisdienst.\u003c/p\u003e\n\u003cp\u003eMulti-Provider-DNS ergänzt diesen Ansatz um eine organisatorische und technische Entkopplung von einem einzelnen DNS-Anbieter. Unterschiedliche autoritative Provider können die Namensauflösung redundant bereitstellen. Das reduziert die Abhängigkeit von einer einzelnen DNS-Infrastruktur, ersetzt aber keine saubere Zustands- und Änderungsstrategie: TTLs, Health Checks, Delegation und Failover müssen zusammenpassen.\u003c/p\u003e\n\u003cp\u003eIm Kontext der ayedo Edge Cloud bildet Anycast DNS den Namenseinstieg in eine verteilte Edge-Infrastruktur. Multi-Provider-DNS kann dabei die DNS-Ebene zusätzlich providerübergreifend absichern. Die Edge selbst basiert auf eigener Netzwerk-Infrastruktur, eigenem Autonomous System und einem Aktiv-Aktiv-Prinzip. DNS ist damit der erste Teil einer Kette, deren nachgelagerte Schutz- und Routingfunktionen an der Edge ausgeführt werden.\u003c/p\u003e\n\u003ch2 id=\"2-tls-termination-schafft-den-prüfbaren-verkehrskontext\"\u003e2. TLS-Termination schafft den prüfbaren Verkehrskontext\u003c/h2\u003e\n\u003cp\u003eHTTPS schützt die Verbindung zwischen Client und dem Punkt, an dem TLS beendet wird. Solange der Datenstrom verschlüsselt ist, kann eine nachgelagerte HTTP-Sicherheitskomponente Inhalte, Header und Request-Struktur nicht bewerten. TLS-Termination an der Edge schafft deshalb den technischen Übergang von verschlüsseltem Transport zu prüfbarem Anwendungstraffic.\u003c/p\u003e\n\u003cp\u003eDieser Übergang ist sicherheitsrelevant. Zertifikate, unterstützte Protokolle und die Zuordnung von Hostnamen müssen an der öffentlichen Eingangsschicht konsistent verwaltet werden. Ebenso muss klar sein, welche Verbindung geschützt wird: zwischen Client und Edge, zwischen Edge und Backend oder in beiden Abschnitten. Eine TLS-Terminierung an der Edge bedeutet nicht automatisch, dass der gesamte interne Transport unverschlüsselt erfolgt.\u003c/p\u003e\n\u003cp\u003eFür die WAF ist die TLS-Terminierung eine Voraussetzung, um HTTPS-Anfragen auf Anwendungsebene zu analysieren. Die ayedo Edge Cloud kann TLS an der Edge terminieren und den anschließend verarbeitbaren Traffic an die vorgesehenen Backends weiterleiten. Backend Cloaking unterstützt dabei die Trennung zwischen öffentlichem Einstiegspunkt und tatsächlich betriebenen Ursprungsdiensten: Clients adressieren die Edge, nicht unmittelbar die Backend-Infrastruktur.\u003c/p\u003e\n\u003ch2 id=\"3-die-waf-arbeitet-nach-der-entschlüsselung\"\u003e3. Die WAF arbeitet nach der Entschlüsselung\u003c/h2\u003e\n\u003cp\u003eEine Web Application Firewall schützt HTTP-/HTTPS-Services auf Anwendungsebene. Sie bewertet beispielsweise Request-Strukturen, Pfade, Parameter und Header gegen definierte Sicherheitsregeln. Damit unterscheidet sie sich von DDoS-Schutz oder reinem Layer-4-Loadbalancing: Die WAF benötigt einen interpretierbaren HTTP-Kontext und kann nicht allein anhand von IP-Adresse und Port entscheiden.\u003c/p\u003e\n\u003cp\u003eDie Verarbeitungskette ist deshalb entscheidend. DNS führt zur Edge, TLS authentifiziert den vorgesehenen Dienst und entschlüsselt die Verbindung, danach kann die WAF die Anfrage prüfen. Erst wenn diese Prüfung erfolgreich ist, wird der Traffic per Routing und Loadbalancing an ein Backend übergeben. Wird eine Anfrage abgewiesen, erreicht sie die Anwendung nicht.\u003c/p\u003e\n\u003cp\u003eDiese Reihenfolge beeinflusst auch den Betrieb. Eine fehlerhafte DNS-Konfiguration erzeugt Erreichbarkeitsprobleme, ein Zertifikatsfehler verhindert den TLS-Aufbau, und eine zu restriktive WAF-Regel kann gültige Requests blockieren. Die Fehlerbilder liegen an unterschiedlichen Stellen, obwohl Nutzer jeweils nur einen nicht erreichbaren Dienst wahrnehmen. Traffic- und Usage-Statistiken sowie Backend Health Checks helfen, diese Ebenen voneinander zu trennen. Die WAF ist damit kein isoliertes Add-on, sondern ein Bestandteil des öffentlichen Datenpfads.\u003c/p\u003e\n\u003ch2 id=\"4-gemeinsame-steuerung-reduziert-betriebliche-brüche\"\u003e4. Gemeinsame Steuerung reduziert betriebliche Brüche\u003c/h2\u003e\n\u003cp\u003eDie größte Wirkung entsteht, wenn DNS, TLS, WAF und Backend-Routing als ein gemeinsamer Service-Einstieg betrieben werden. Ein neuer Hostname benötigt dann nicht nur einen DNS-Eintrag, sondern auch eine passende TLS-Zuordnung, WAF-Regeln und ein gesundes Backend. Änderungen an einer Ebene müssen auf die anderen Ebenen abgestimmt werden.\u003c/p\u003e\n\u003cp\u003eDas betrifft insbesondere Failover. DNS kann nur den Einstieg beeinflussen; ob ein Ziel tatsächlich Anfragen verarbeitet, hängt zusätzlich von Edge-Verfügbarkeit, WAF-Zustand und Backend Health Checks ab. Ein DNS-Failover ohne korrespondierende Anwendungs- und Sicherheitskonfiguration kann zwar die Auflösung ändern, aber keinen funktionsfähigen Service herstellen. Umgekehrt ist ein gesundes Backend wertlos, wenn TLS oder DNS den Zugriff verhindern.\u003c/p\u003e\n\u003cp\u003eBei der ayedo Edge Cloud werden diese Funktionen innerhalb einer verteilten Edge-Plattform verbunden: Anycast DNS, Multi-Provider-DNS, TLS-Termination, WAF, DDoS Protection, Routing und Health-basierte Weiterleitung bilden eine zusammenhängende Eingangsschicht. Das ist auch unabhängig vom verwendeten Compute-Provider relevant. Kubernetes-Workloads können über die Edge angebunden werden, egal ob sie in ayedo Managed Kubernetes, einem eigenen Cluster oder bei einem anderen Provider laufen.\u003c/p\u003e\n\u003ch2 id=\"betriebsszenario-ein-https-service-mit-failover\"\u003eBetriebsszenario: Ein HTTPS-Service mit Failover\u003c/h2\u003e\n\u003cp\u003eEin Unternehmen betreibt eine API unter \u003ccode\u003eapi.example.de\u003c/code\u003e in zwei \u003ca href=\"/kubernetes/\"\u003eKubernetes-Clustern\u003c/a\u003e\n bei unterschiedlichen Providern. Der DNS-Name verweist über Anycast DNS auf die Edge. Zusätzlich ist die Zone bei mehreren DNS-Providern delegiert. Die TLS-Verbindung wird an der Edge terminiert, bevor die WAF Requests anhand von Host, Pfad und Parametern prüft. Nur zulässiger Traffic wird an ein Backend weitergeleitet.\u003c/p\u003e\n\u003cp\u003eFällt ein Cluster aus, erkennen Health Checks das fehlerhafte Ziel und die Edge leitet Anfragen an das verbleibende Backend. DNS muss dafür nicht bei jeder Störung geändert werden. Die öffentliche Adresse, das Zertifikatsmodell und die WAF-Regeln bleiben an der Eingangsschicht stabil. Das reduziert die Zahl synchron zu ändernder Komponenten und hält die Backend-Adressen verborgen.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"ist-eine-waf-ohne-tls-termination-nutzlos\"\u003eIst eine WAF ohne TLS-Termination nutzlos?\u003c/h3\u003e\n\u003cp\u003eNicht grundsätzlich. Sie kann unverschlüsselten HTTP-Traffic prüfen. Für HTTPS muss der Datenstrom jedoch an einem vertrauenswürdigen Punkt terminiert oder anderweitig entschlüsselt werden, damit Anwendungsebene und Request-Inhalt analysierbar sind.\u003c/p\u003e\n\u003ch3 id=\"ersetzt-multi-provider-dns-die-edge-redundanz\"\u003eErsetzt Multi-Provider-DNS die Edge-Redundanz?\u003c/h3\u003e\n\u003cp\u003eNein. Multi-Provider-DNS reduziert die Abhängigkeit von einzelnen DNS-Anbietern. Die Verfügbarkeit der Edge, TLS-Verarbeitung, WAF und Backends müssen zusätzlich redundant und unabhängig betrachtet werden.\u003c/p\u003e\n\u003ch3 id=\"funktioniert-die-kette-nur-mit-ayedo-managed-kubernetes\"\u003eFunktioniert die Kette nur mit ayedo Managed Kubernetes?\u003c/h3\u003e\n\u003cp\u003eNein. Die Edge Cloud kann auch eigene oder bei anderen Providern betriebene \u003ca href=\"/kubernetes/\"\u003eKubernetes-Cluster\u003c/a\u003e\n anbinden. DNS, TLS und WAF bleiben dabei Funktionen des öffentlichen Eingangs, nicht des verwendeten Compute-Clusters.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eDNS, TLS und WAF sollten nicht als drei unabhängige Sicherheits- oder Netzwerkdienste modelliert werden. Sie bilden eine Verarbeitungskette mit klaren Übergängen: Namensauflösung führt zur Edge, TLS macht den Dienstkontext vertrauenswürdig und prüfbar, die WAF bewertet den HTTP-/HTTPS-Traffic, bevor Backends erreicht werden. Die ayedo Edge Cloud ordnet diese Funktionen in einer providerunabhängigen, verteilten Eingangsschicht ein. Entscheidend ist damit weniger die einzelne Funktion als die Konsistenz des gesamten öffentlichen Datenpfads.\u003c/p\u003e\n", "summary": "\nTL;DR DNS, TLS und WAF erfüllen am öffentlichen Eingang unterschiedliche Aufgaben, wirken aber als gemeinsame Verarbeitungskette. Anycast DNS und Multi-Provider-DNS führen Anfragen zur Edge, TLS-Termination macht verschlüsselten Traffic prüfbar, und die Web Application Firewall bewertet HTTP-/HTTPS-Anfragen. Entscheidend ist nicht die Einzelfunktion, sondern ihr Zusammenspiel.\nEinleitung Ein häufiger Architekturfehler besteht darin, DNS, TLS und WAF als separat buchbare Dienste zu betrachten. Dann wird DNS lediglich als Verweis auf einen Endpoint konfiguriert, TLS an irgendeiner Stelle beendet und die WAF nachträglich vor ein Backend gesetzt. Das erschwert Fehleranalyse, Failover und Sicherheitsbewertung. Technisch handelt es sich um eine Verarbeitungskette: DNS bestimmt den Einstiegspunkt, TLS authentifiziert und verschlüsselt die Verbindung, und die WAF analysiert den entschlüsselten HTTP-/HTTPS-Verkehr. Eine Edge-Plattform muss diese Übergänge kontrolliert abbilden, bevor Anfragen die eigentlichen Backends erreichen.\n", "image": "https://ayedo.de/dns-tls-und-waf-zusammenspiel-am-offentlichen-eingang.png", "date_published": "2026-09-04T22:12:58Z", "date_modified": "2026-09-04T22:12:58Z", "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}], "tags": ["security","operations","hosting","kubernetes","cloud-native"], "language": "de" },{ "id": "https://ayedo.de/posts/vom-dns-zum-backend-der-request-pfad-an-der-edge/", "url": "https://ayedo.de/posts/vom-dns-zum-backend-der-request-pfad-an-der-edge/", "title": "Vom DNS zum Backend: Der Request-Pfad an der Edge", "content_html": "\u003cp\u003e\u003cimg src=\"/posts/vom-dns-zum-backend-der-request-pfad-an-der-edge/vom-dns-zum-backend-der-request-pfad-an-der-edge.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eEin Request zur Anwendung durchläuft mehrere technische Ebenen: Anycast DNS liefert einen erreichbaren Einstiegspunkt, das Internet routet den Traffic zur Edge, dort erfolgen Loadbalancing, TLS-Termination und Sicherheitsprüfungen. Erst danach wird der Request über Backend-Routing an einen gesunden Service weitergeleitet. Diese Kette muss als zusammenhängender Betriebsprozess geplant werden.\u003c/p\u003e\n\u003cp\u003eEin Request-Pfad ist keine lineare Verbindung zwischen Client und Server. Zwischen DNS-Auflösung und Backend liegen Routingentscheidungen, Transport- und Anwendungsebene, Sicherheitsfunktionen sowie Zustands- und Health-Check-Informationen. Werden diese Komponenten isoliert betrachtet, entstehen häufig Fehlannahmen über Ausfälle, Zertifikate, Quell-IP-Adressen oder die tatsächliche Erreichbarkeit eines Backends.\u003c/p\u003e\n\u003cp\u003eFür Platform Engineers und Architekt:innen ist deshalb entscheidend, den vollständigen Ablauf zu verstehen. Nur so lassen sich Fehlerbilder korrekt eingrenzen, Failover-Szenarien bewerten und die Verantwortungsgrenzen zwischen Edge und Compute sauber definieren.\u003c/p\u003e\n\u003ch2 id=\"1-anycast-dns-schafft-den-öffentlichen-einstiegspunkt\"\u003e1. Anycast DNS schafft den öffentlichen Einstiegspunkt\u003c/h2\u003e\n\u003cp\u003eAm Anfang steht die DNS-Auflösung des Hostnamens. Anycast DNS beantwortet die Anfrage über verteilte Netzwerkinfrastruktur und liefert die für den Service vorgesehenen Adressen. Der Client erhält damit keinen direkten Hinweis auf ein konkretes Backend, sondern einen öffentlichen Einstiegspunkt der Edge.\u003c/p\u003e\n\u003cp\u003eDiese Trennung ist architektonisch relevant: DNS entscheidet, unter welcher Adresse ein Service erreichbar ist. Es verteilt jedoch nicht automatisch jede einzelne HTTP-Anfrage auf einen bestimmten Pod oder Server. Die anschließende Auswahl erfolgt innerhalb der Edge- und Backend-Routing-Logik. Änderungen an DNS-TTLs, Caches und Resolvern beeinflussen daher, wie schnell neue Erreichbarkeitsinformationen bei Clients wirksam werden.\u003c/p\u003e\n\u003cp\u003eBei einer Edge-Plattform wie der ayedo Edge Cloud kann Anycast DNS mit dem Anycast-Netzwerk und Multi-Provider-DNS zusammenspielen. Der DNS-Schritt ist damit Teil einer durchgängigen Erreichbarkeitsarchitektur, aber nicht deren einziger Failover-Mechanismus. Für die Betriebsplanung müssen DNS-Verhalten und aktive Traffic-Verteilung getrennt betrachtet werden.\u003c/p\u003e\n\u003ch2 id=\"2-anycast-routing-führt-den-traffic-zur-edge\"\u003e2. Anycast Routing führt den Traffic zur Edge\u003c/h2\u003e\n\u003cp\u003eNach der DNS-Auflösung baut der Client eine Verbindung zur gelieferten IP-Adresse auf. Anycast-Routing sorgt dafür, dass der Traffic über das Internet zu einem geeigneten Edge-Punkt gelangt. Maßgeblich ist dabei nicht die geografische Entfernung allein, sondern die Routingentscheidung des Netzes. Der Client kennt die interne Topologie und die späteren Backends nicht.\u003c/p\u003e\n\u003cp\u003eHier liegt ein wesentlicher Unterschied zu einem klassischen, zentral betriebenen Loadbalancer. Die Edge ist nicht nur ein einzelner Netzwerkendpunkt, sondern eine verteilte Eingangsschicht. Die ayedo Edge Cloud nutzt dafür ein eigenes Autonomous System und eigene Netzwerk-Infrastruktur in einer verteilten Multi-PoP-Architektur. Das Aktiv-Aktiv-Prinzip ermöglicht, Traffic grundsätzlich über mehrere verfügbare Edge-Instanzen zu verarbeiten.\u003c/p\u003e\n\u003cp\u003eFür den Betrieb bedeutet das: Ein Fehler an einem Backend muss nicht zwangsläufig die öffentliche IP-Adresse unbrauchbar machen. Die Edge kann den Request weiterhin annehmen, den Zustand der Backends bewerten und nur gesunde Ziele verwenden. Das reduziert die Kopplung zwischen öffentlicher Erreichbarkeit und dem Zustand einzelner Compute-Ressourcen.\u003c/p\u003e\n\u003ch2 id=\"3-tls-termination-und-loadbalancing-verarbeiten-den-request\"\u003e3. TLS-Termination und Loadbalancing verarbeiten den Request\u003c/h2\u003e\n\u003cp\u003eErreicht der Traffic die Edge, wird zunächst die Verbindung auf Transport- und gegebenenfalls Anwendungsebene verarbeitet. Bei HTTPS kann die TLS-Termination an der Edge erfolgen. Die Edge nimmt dabei die verschlüsselte Verbindung an, prüft das konfigurierte Zertifikat und verarbeitet anschließend den HTTP-Request. Das Backend muss die öffentliche TLS-Verbindung nicht selbst terminieren.\u003c/p\u003e\n\u003cp\u003eDiese Entscheidung verändert Verantwortlichkeiten. Zertifikate, unterstützte TLS-Konfigurationen und öffentliche Sicherheitsrichtlinien liegen an einem zentralen Punkt. Gleichzeitig muss klar definiert sein, wie der Traffic zur Anwendung weitergeschützt wird und welche Informationen aus der ursprünglichen Verbindung an das Backend übergeben werden. Für HTTP-/HTTPS-Services können zusätzlich Web Application Firewall und DDoS Protection an der Edge greifen, bevor der Request Compute-Ressourcen erreicht.\u003c/p\u003e\n\u003cp\u003eAnschließend übernimmt das Loadbalancing die Auswahl eines geeigneten Ziels. Layer-4- und Layer-7-Loadbalancing adressieren dabei unterschiedliche Anforderungen: Auf Layer 4 steht die Transportverbindung im Mittelpunkt, auf Layer 7 können Protokoll- und Requestinformationen für das Routing berücksichtigt werden. Proxy Protocol kann erforderlich sein, wenn nachgelagerte Systeme die ursprünglichen Verbindungsinformationen benötigen.\u003c/p\u003e\n\u003ch2 id=\"4-backend-routing-bestimmt-den-letzten-abschnitt\"\u003e4. Backend-Routing bestimmt den letzten Abschnitt\u003c/h2\u003e\n\u003cp\u003eErst nach der Verarbeitung an der Edge wird der Request an ein Backend weitergeleitet. Dieses Backend kann in einem ayedo Managed \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n Cluster, in einem eigenen Kubernetes-Cluster oder bei einem anderen Provider betrieben werden. Die Edge ist damit nicht an eine bestimmte Compute-Plattform gebunden. Entscheidend sind Erreichbarkeit, Routingkonfiguration und der von der Anwendung erwartete Protokollpfad.\u003c/p\u003e\n\u003cp\u003eBackend Health Checks liefern die Grundlage für diese Auswahl. Sie prüfen, ob ein Ziel nicht nur technisch erreichbar, sondern gemäß der definierten Prüfung verwendbar ist. Bei einem Ausfall kann die Edge den Traffic auf andere gesunde Ziele umleiten. Backend Cloaking verhindert dabei, dass die internen Zieladressen zum öffentlichen Bestandteil der Anwendungstopologie werden.\u003c/p\u003e\n\u003cp\u003eFür \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n Umgebungen ist die Trennung besonders wichtig. Kubernetes steuert die Ausführung und interne Verteilung von Workloads; die Edge Cloud übernimmt den öffentlichen Traffic-Eingang, Schutz, Termination und die externe Lastverteilung. Diese Verantwortungsgrenze gilt unabhängig davon, ob Compute und Edge beim selben Anbieter betrieben werden. Sie erleichtert Providerwechsel und reduziert die Abhängigkeit vom öffentlichen Netzwerkpfad einzelner Cluster.\u003c/p\u003e\n\u003ch2 id=\"praxisszenario-fehleranalyse-entlang-der-kette\"\u003ePraxisszenario: Fehleranalyse entlang der Kette\u003c/h2\u003e\n\u003cp\u003eEin HTTPS-Service ist unter \u003ccode\u003eapi.example.de\u003c/code\u003e erreichbar, aber einzelne Requests schlagen fehl. Eine Prüfung beginnt nicht beim Pod, sondern am Anfang des Pfads: Liefert Anycast DNS die erwartete Adresse? Wird der Traffic zur Edge geroutet? Wird die TLS-Verbindung korrekt terminiert? Akzeptiert das Layer-7-Routing den Hostnamen und den Pfad? Sind die Health Checks erfolgreich, und erreicht die Weiterleitung das Backend?\u003c/p\u003e\n\u003cp\u003eEin DNS-Fehler, ein abgelaufenes Zertifikat, ein falsches Routingkriterium und ein nicht erreichbarer Service erzeugen unterschiedliche Symptome. Die End-to-End-Sicht verhindert, dass das Betriebsteam vorschnell nur die Compute-Schicht untersucht. Gleichzeitig lässt sich erkennen, an welcher Verantwortungsgrenze die Störung tatsächlich liegt.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"ist-dns-bereits-loadbalancing\"\u003eIst DNS bereits Loadbalancing?\u003c/h3\u003e\n\u003cp\u003eNein. DNS liefert Erreichbarkeitsinformationen. Die Auswahl konkreter Backend-Ziele erfolgt typischerweise durch Routing- und Loadbalancing-Logik nach dem Verbindungsaufbau.\u003c/p\u003e\n\u003ch3 id=\"warum-tls-an-der-edge-terminieren\"\u003eWarum TLS an der Edge terminieren?\u003c/h3\u003e\n\u003cp\u003eTLS-Termination zentralisiert die öffentliche Verschlüsselungsschicht. Dadurch können Zertifikate und Sicherheitsrichtlinien an der Edge verarbeitet werden, während Backends von dieser Aufgabe entkoppelt bleiben.\u003c/p\u003e\n\u003ch3 id=\"muss-das-backend-direkt-aus-dem-internet-erreichbar-sein\"\u003eMuss das Backend direkt aus dem Internet erreichbar sein?\u003c/h3\u003e\n\u003cp\u003eNein. Eine Edge kann als öffentlicher Eingang dienen und Backends abschirmen. Backend Cloaking reduziert dabei die Sichtbarkeit interner Zieladressen; die konkrete private Erreichbarkeit muss zur Netzwerkarchitektur passen.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eDer Request-Pfad Edge Cloud beginnt mit DNS, endet aber erst nach der erfolgreichen Weiterleitung an ein gesundes Backend. Anycast, Routing, TLS-Termination und Loadbalancing sind keine isolierten Funktionen, sondern aufeinanderfolgende Verarbeitungsschritte mit gemeinsamen Betriebsfolgen. Die ayedo Edge Cloud ordnet diese Aufgaben als öffentliche Eingangsschicht vor unterschiedlichen Compute-Umgebungen ein. Genau diese Trennung schafft eine belastbare Grundlage für Failover, Sicherheitskontrolle und providerunabhängiges \u003ca href=\"/compliance/\"\u003eBackend-Routing\u003c/a\u003e\n.\u003c/p\u003e\n", "summary": "\nTL;DR Ein Request zur Anwendung durchläuft mehrere technische Ebenen: Anycast DNS liefert einen erreichbaren Einstiegspunkt, das Internet routet den Traffic zur Edge, dort erfolgen Loadbalancing, TLS-Termination und Sicherheitsprüfungen. Erst danach wird der Request über Backend-Routing an einen gesunden Service weitergeleitet. Diese Kette muss als zusammenhängender Betriebsprozess geplant werden.\nEin Request-Pfad ist keine lineare Verbindung zwischen Client und Server. Zwischen DNS-Auflösung und Backend liegen Routingentscheidungen, Transport- und Anwendungsebene, Sicherheitsfunktionen sowie Zustands- und Health-Check-Informationen. Werden diese Komponenten isoliert betrachtet, entstehen häufig Fehlannahmen über Ausfälle, Zertifikate, Quell-IP-Adressen oder die tatsächliche Erreichbarkeit eines Backends.\n", "image": "https://ayedo.de/vom-dns-zum-backend-der-request-pfad-an-der-edge.png", "date_published": "2026-09-04T22:12:58Z", "date_modified": "2026-09-04T22:12:58Z", "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}], "tags": ["security","platform","cloud-native","kubernetes","operations"], "language": "de" },{ "id": "https://ayedo.de/posts/edge-und-compute-zwei-schichten-moderner-anwendungsarchitektur/", "url": "https://ayedo.de/posts/edge-und-compute-zwei-schichten-moderner-anwendungsarchitektur/", "title": "Edge und Compute: Zwei Schichten moderner Anwendungsarchitektur", "content_html": "\u003cp\u003e\u003cimg src=\"/posts/edge-und-compute-zwei-schichten-moderner-anwendungsarchitektur/edge-und-compute-zwei-schichten-moderner-anwendungsarchitektur.png\" alt=\"Beitragsbild\"\u003e\u003c/p\u003e\n\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eEine belastbare \u003cstrong\u003eEdge-Compute-Architektur\u003c/strong\u003e trennt den öffentlichen Eingang von der eigentlichen Anwendungsausführung. Die Edge Cloud übernimmt Routing, Schutz, TLS-Terminierung und Lastverteilung. Compute-Plattformen führen Workloads aus. Diese Trennung reduziert Kopplungen, verbessert Failover-Optionen und erlaubt, Anwendungen unabhängig vom zugrunde liegenden Cluster oder Provider zu betreiben.\u003c/p\u003e\n\u003ch2 id=\"einleitung\"\u003eEinleitung\u003c/h2\u003e\n\u003cp\u003eViele Plattformarchitekturen behandeln den Loadbalancer vor dem Cluster als Teil der Compute-Infrastruktur. Das wirkt zunächst effizient, erzeugt aber eine enge Kopplung zwischen öffentlicher Erreichbarkeit und Anwendungsausführung. Fällt der Cluster aus, werden dadurch oft auch Routing, Schutzmechanismen und der Zugang zu alternativen Backends mitgerissen. Eine \u003cstrong\u003eEdge-Compute-Architektur\u003c/strong\u003e trennt deshalb zwei Verantwortungsbereiche: Die Edge stellt den kontrollierten öffentlichen Eingang für Anwendungen und APIs bereit. Die Compute-Infrastruktur führt die Workloads aus. Diese Unterscheidung ist keine rein organisatorische Frage, sondern beeinflusst Verfügbarkeit, Security, Migrationen und den laufenden Betriebsaufwand.\u003c/p\u003e\n\u003ch2 id=\"1-unterschiedliche-aufgaben-erfordern-unterschiedliche-schichten\"\u003e1. Unterschiedliche Aufgaben erfordern unterschiedliche Schichten\u003c/h2\u003e\n\u003cp\u003eDie Edge verarbeitet eingehenden Traffic, bevor er ein Backend erreicht. Dazu gehören Anycast-basiertes Layer-4- und Layer-7-Loadbalancing, DNS-Auflösung, TLS Termination, Web Application Firewall und DDoS Protection. Backend Health Checks entscheiden, ob ein Ziel erreichbar ist; Failover-Mechanismen können Traffic zu einem anderen verfügbaren Backend lenken. Die Compute-Schicht hat eine andere Aufgabe: Sie stellt Runtime, Netzwerk innerhalb der Plattform, Speicher und Ressourcen für Anwendungen bereit.\u003c/p\u003e\n\u003cp\u003eDiese Trennung schafft klare Verantwortlichkeiten. Das Edge-Team kontrolliert öffentliche Endpunkte, Routing und Schutz. Das Plattform- oder Anwendungsteam verantwortet Workloads, Deployments und deren interne Abhängigkeiten. Fehler lassen sich dadurch besser eingrenzen. Ein fehlerhaftes Deployment muss nicht automatisch die gesamte öffentliche Zugangsschicht verändern. Umgekehrt kann die Edge weiterarbeiten, auch wenn ein einzelner Cluster gewartet wird oder nicht verfügbar ist.\u003c/p\u003e\n\u003ch2 id=\"2-entkopplung-reduziert-abhängigkeiten-im-betrieb\"\u003e2. Entkopplung reduziert Abhängigkeiten im Betrieb\u003c/h2\u003e\n\u003cp\u003eWird der öffentliche Zugang direkt an einen einzelnen Cluster oder Cloud-Provider gebunden, entstehen technische und organisatorische Lock-ins. Ein Wechsel der Compute-Plattform kann dann Änderungen an DNS, IP-Adressen, Zertifikaten, Firewall-Regeln und Traffic-Verteilung auslösen. Zusätzlich müssen Anwendungen während Migrationen häufig parallel erreichbar bleiben. Das erhöht die Komplexität gerade dann, wenn Stabilität besonders wichtig ist.\u003c/p\u003e\n\u003cp\u003eEine eigenständige Edge Cloud bildet dagegen eine stabile Eingangsschicht vor unterschiedlichen Backends. Die ayedo Edge Cloud kann mit ayedo Managed \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n, eigenen [Kubernetes]-Clustern oder Clustern bei anderen Providern eingesetzt werden. Backend Cloaking verhindert dabei, dass interne Zielstrukturen zum öffentlichen Bestandteil der Anwendung werden. Bring Your Own IP kann die Trennung zusätzlich unterstützen, wenn bestehende Adressräume als Teil der externen Erreichbarkeit erhalten bleiben sollen. Die Compute-Infrastruktur bleibt austauschbarer, ohne dass der öffentliche Zugang neu entworfen werden muss.\u003c/p\u003e\n\u003ch2 id=\"3-hochverfügbarkeit-beginnt-vor-dem-cluster\"\u003e3. Hochverfügbarkeit beginnt vor dem Cluster\u003c/h2\u003e\n\u003cp\u003eHochverfügbarkeit wird häufig ausschließlich innerhalb der Compute-Plattform betrachtet: mehrere Instanzen, verteilte Nodes und automatisierte Restarts. Diese Maßnahmen lösen jedoch nicht jedes Problem. Wenn DNS, öffentlicher Loadbalancer oder Schutzschicht an derselben Plattform hängen wie die Anwendung, bleibt ein gemeinsamer Ausfallpfad bestehen. Ein redundanter Cluster ist dann nur so erreichbar wie die davorliegende Infrastruktur.\u003c/p\u003e\n\u003cp\u003eEine Edge-Schicht mit eigener Netzwerk-Infrastruktur, eigenem Autonomous System, verteilter Multi-PoP-Architektur und Aktiv-Aktiv-Prinzip adressiert diesen Bereich separat. Anycast kann Anfragen an verfügbare Edge-Standorte führen. Health Checks liefern die Grundlage, um nicht erreichbare Backends aus der Verteilung zu nehmen. Dabei ersetzt die Edge keine redundante Anwendungsausführung: Sie kann keinen fehlerhaften Datenbankzustand reparieren und keine fehlenden Workload-Replikate bereitstellen. Sie sorgt jedoch dafür, dass Routing, Schutz und Failover nicht unnötig an einen einzelnen Compute-Ausfall gekoppelt sind.\u003c/p\u003e\n\u003ch2 id=\"4-ein-schichtenmodell-verbessert-security-und-veränderbarkeit\"\u003e4. Ein Schichtenmodell verbessert Security und Veränderbarkeit\u003c/h2\u003e\n\u003cp\u003eSecurity-Funktionen sollten möglichst vor der Anwendung greifen. Die Edge kann TLS-Verbindungen terminieren, HTTP- und HTTPS-Traffic durch eine Web Application Firewall prüfen und DDoS-Angriffe an der Edge abwehren. Durch Backend Cloaking bleiben interne Endpunkte verborgen. Proxy Protocol kann zusätzliche Verbindungsinformationen an Backends weitergeben, wenn Anwendungen oder nachgelagerte Systeme die ursprüngliche Client-Verbindung auswerten müssen.\u003c/p\u003e\n\u003cp\u003eFür die Compute-Schicht bedeutet das eine klar definierte Eingangsgrenze. Anwendungen müssen nicht selbst jede öffentliche Schutzfunktion implementieren, behalten aber die Verantwortung für Authentisierung, Autorisierung und anwendungsbezogene Validierung. Gleichzeitig lassen sich Routingregeln, Zertifikatswechsel oder Backend-Failover unabhängig von einem Workload-Release betreiben. Das verkürzt nicht automatisch jede Änderung, reduziert aber den Umfang notwendiger Abstimmungen zwischen Netzwerk-, Security- und Anwendungsteams.\u003c/p\u003e\n\u003ch2 id=\"architektur--und-betriebsszenario\"\u003eArchitektur- 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 Umgebung bei einem anderen Provider für Wartung und Failover vor. Ohne separate Edge-Schicht müssten DNS, externe Adressen und Schutzregeln eng an die jeweiligen Ingress-Komponenten der Cluster gekoppelt werden. Ein Wechsel der aktiven Umgebung wird dadurch zu einer Infrastrukturänderung mit mehreren Fehlerquellen.\u003c/p\u003e\n\u003cp\u003eMit einer Edge Cloud bleibt der öffentliche Endpunkt unverändert. Die Edge terminiert TLS, prüft den Traffic, führt Health Checks aus und verteilt Anfragen auf die verfügbaren Backends. \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n bleibt für Deployment und Skalierung der API zuständig. Die Edge muss dabei nicht wissen, wie die Anwendung intern betrieben wird. Genau diese Entkopplung reduziert den Koordinationsaufwand bei Wartung, Migration und Providerwechsel.\u003c/p\u003e\n\u003ch2 id=\"faq\"\u003eFAQ\u003c/h2\u003e\n\u003ch3 id=\"ist-die-edge-cloud-ein-ersatz-für-kubernetes\"\u003eIst die Edge Cloud ein Ersatz für Kubernetes?\u003c/h3\u003e\n\u003cp\u003eNein. \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n führt Workloads aus und verwaltet deren Ressourcen. Die Edge Cloud stellt den öffentlichen Zugang, Schutz, Routing und Lastverteilung vor diesen Workloads bereit.\u003c/p\u003e\n\u003ch3 id=\"muss-compute-bei-ayedo-betrieben-werden\"\u003eMuss Compute bei ayedo betrieben werden?\u003c/h3\u003e\n\u003cp\u003eNein. Die ayedo Edge Cloud kann auch mit eigenen [Kubernetes]-Clustern oder mit Clustern anderer Provider eingesetzt werden.\u003c/p\u003e\n\u003ch3 id=\"verhindert-die-trennung-jede-auswirkung-eines-backend-ausfalls\"\u003eVerhindert die Trennung jede Auswirkung eines Backend-Ausfalls?\u003c/h3\u003e\n\u003cp\u003eNein. Die Edge kann Traffic umleiten oder nicht erreichbare Backends aus der Verteilung nehmen. Anwendung, Datenhaltung und fachliche Ausfallsicherheit bleiben Aufgaben der Compute-Architektur.\u003c/p\u003e\n\u003ch2 id=\"fazit\"\u003eFazit\u003c/h2\u003e\n\u003cp\u003eEdge und Compute sollten als eigenständige Schichten geplant werden, weil sie unterschiedliche technische Ziele verfolgen. Die Edge kontrolliert den öffentlichen Eingang und schützt ihn; Compute stellt die Anwendungsausführung bereit. Diese Trennung verbessert die Austauschbarkeit von Clustern und Providern, schafft klarere Betriebsgrenzen und reduziert gemeinsame Ausfallpfade. Die ayedo Edge Cloud ist in diesem Modell keine vorgelagerte Funktion eines bestimmten [Kubernetes]-Angebots, sondern eine eigenständige Plattform für Routing, Schutz und Zugang vor unterschiedlichen Compute-Umgebungen.\u003c/p\u003e\n", "summary": "\nTL;DR Eine belastbare Edge-Compute-Architektur trennt den öffentlichen Eingang von der eigentlichen Anwendungsausführung. Die Edge Cloud übernimmt Routing, Schutz, TLS-Terminierung und Lastverteilung. Compute-Plattformen führen Workloads aus. Diese Trennung reduziert Kopplungen, verbessert Failover-Optionen und erlaubt, Anwendungen unabhängig vom zugrunde liegenden Cluster oder Provider zu betreiben.\nEinleitung Viele Plattformarchitekturen behandeln den Loadbalancer vor dem Cluster als Teil der Compute-Infrastruktur. Das wirkt zunächst effizient, erzeugt aber eine enge Kopplung zwischen öffentlicher Erreichbarkeit und Anwendungsausführung. Fällt der Cluster aus, werden dadurch oft auch Routing, Schutzmechanismen und der Zugang zu alternativen Backends mitgerissen. Eine Edge-Compute-Architektur trennt deshalb zwei Verantwortungsbereiche: Die Edge stellt den kontrollierten öffentlichen Eingang für Anwendungen und APIs bereit. Die Compute-Infrastruktur führt die Workloads aus. Diese Unterscheidung ist keine rein organisatorische Frage, sondern beeinflusst Verfügbarkeit, Security, Migrationen und den laufenden Betriebsaufwand.\n", "image": "https://ayedo.de/edge-und-compute-zwei-schichten-moderner-anwendungsarchitektur.png", "date_published": "2026-09-04T22:12:57Z", "date_modified": "2026-09-04T22:12:57Z", "authors": [{"name":"Fabian Peter","url":"https://www.linkedin.com/in/derfabianpeter/"}], "tags": ["security","cloud-native","development","operations","kubernetes"], "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" }, ] }