Edge ist kein Kubernetes-Feature:

Warum die ayedo Edge Cloud vor jeder Infrastruktur funktionieren kann

Wer Edge-Infrastruktur mit Kubernetes gleichsetzt, vermischt zwei unterschiedliche Ebenen.

Kubernetes orchestriert Workloads. Eine Edge Cloud kontrolliert, wie Traffic diese Workloads erreicht.

Diese Trennung ist entscheidend.

Die 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.

Das 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.

Edge und Compute sind getrennte Ebenen

Technisch betrachtet braucht die Edge Cloud zunächst erreichbare Backends.

Der 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.

Genau diese Entkopplung ermöglicht heterogene Architekturen.

Ein 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.

Die Anwendung muss dafür nicht auf die ayedo Compute Cloud migriert werden.

Anycast macht den Einstieg unabhängig vom Backend

Ein zentraler Bestandteil dieser Architektur ist Anycast.

Dabei 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.

Die öffentliche Erreichbarkeit einer Anwendung wird dadurch von ihrem eigentlichen Compute-Standort entkoppelt.

Hinter diesem Einstieg können wiederum unterschiedliche Backends liegen. Die Edge Cloud übernimmt die Verteilung der Verbindungen und überwacht die konfigurierten Endpunkte.

Damit entsteht eine zusätzliche Verfügbarkeits- und Routing-Schicht, ohne die darunterliegende Infrastruktur ersetzen zu müssen.

Sicherheit gehört vor das Backend

Dasselbe Prinzip gilt für Security.

Eine 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.

Damit wird die WAF nicht zu einer Eigenschaft des Servers oder Kubernetes -Clusters, sondern zu einer vorgelagerten Schutzschicht.

Das ist architektonisch relevant: Zusätzliche Sicherheitsanforderungen erzwingen damit nicht automatisch einen Wechsel der Compute-Infrastruktur.

Bestehende Systeme können bestehen bleiben. Die zusätzliche Funktion wird dort ergänzt, wo sie technisch hingehört: am Ingress.

Kubernetes automatisiert – es ist aber keine Voraussetzung

Mit Kubernetes lässt sich diese Architektur deutlich stärker automatisieren.

Unsere Edge Services sind deshalb eng mit Komponenten wie cert-manager, external-dns und dem Cloud Controller Manager integriert. DNS-Einträge, Zertifikate und Loadbalancer können so direkt aus Kubernetes heraus verwaltet beziehungsweise provisioniert werden.

Das ist allerdings eine Integration und keine technische Voraussetzung für die Edge Cloud.

Ein regulärer Server benötigt keinen Kubernetes-Cluster, damit Traffic über die Edge-Infrastruktur zu ihm geroutet werden kann.

Genau diese Unterscheidung ist wichtig.

Kubernetes automatisiert die Anbindung an die Edge. Es definiert aber nicht, was hinter der Edge laufen darf.

Infrastruktur muss kombinierbar bleiben

Cloud-Plattformen werden häufig vertikal gedacht: Compute, Netzwerk, DNS, Security und Plattformdienste stammen vom selben Anbieter.

Technisch notwendig ist diese Kopplung nicht.

Eine 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.

Das kann die ayedo Compute Cloud sein.

Es muss sie aber nicht sein.

Für uns ist genau diese Entkopplung ein wichtiger Bestandteil souveräner Infrastruktur. Ein zusätzlicher Infrastruktur-Service sollte keinen Providerwechsel voraussetzen.

Die Edge Cloud entscheidet, wie eine Anwendung erreichbar ist. Nicht, wo sie laufen muss.