TL;DR
Kubernetes Ingress und Edge Cloud lösen unterschiedliche Aufgaben. Die Edge Cloud kontrolliert den öffentlichen Eingang, schützt Anwendungen und terminiert TLS. Kubernetes Ingress beschreibt dagegen die Weiterleitung innerhalb des Clusters. Eine klare Trennung verhindert doppelte Regeln, widersprüchliche Sicherheitskonfigurationen und schwer nachvollziehbare Betriebszustände.
Einleitung
Viele Kubernetes-Architekturen behandeln Ingress als vollständige Eintrittsschicht für Anwendungen. Das funktioniert technisch, vermischt aber zwei Verantwortungsbereiche: den öffentlichen Netzwerkzugang und das Routing innerhalb des Clusters. Sobald TLS, WAF, DDoS-Schutz und Backend-Erreichbarkeit zusätzlich an einer externen Edge-Plattform geregelt werden, entstehen schnell doppelte oder widersprüchliche Konfigurationen. Ein Hostname kann dann an mehreren Stellen terminiert, geprüft und weitergeleitet werden. Die entscheidende Architekturfrage lautet deshalb nicht, ob Kubernetes Ingress oder eine Edge Cloud verwendet wird. Entscheidend ist, welche Ebene welche Verantwortung übernimmt und wo die jeweilige Konfiguration verbindlich ist.
1. Kubernetes Ingress beschreibt den Zugang zu Cluster-Services
Eine Kubernetes-Ingress-Ressource ist zunächst eine deklarative Beschreibung für HTTP- und HTTPS-Routing. Sie ordnet beispielsweise Hostnamen und Pfade bestimmten Services im Cluster zu. Die Ressource selbst verarbeitet keinen Traffic. Diese Aufgabe übernimmt ein Ingress Controller, der die Konfiguration in eine konkrete Proxy- oder Loadbalancer-Konfiguration übersetzt.
Damit liegt die Kernverantwortung des Ingress im Cluster: Ein eingehender Request wird nach der Übergabe an den Kubernetes-Service weitergeleitet. Dazu gehören etwa Regeln wie api.example.de zu einem API-Service oder /checkout zu einem bestimmten Backend. Auch die Aufteilung zwischen Services, Namespaces oder Versionen kann dort modelliert werden.
Diese Ebene ist eng mit dem Deployment-Modell verbunden. Änderungen an Services, Pods und Ingress-Ressourcen lassen sich gemeinsam über Kubernetes-Workflows verwalten. Das ist sinnvoll, solange die Aufgabe auf die interne Erreichbarkeit und das Routing zu Workloads begrenzt bleibt. Der Ingress sollte jedoch nicht automatisch als vollständige Sicherheits- und Internetzugangsschicht verstanden werden.
2. Die Edge Cloud übernimmt den öffentlichen Eingang
Die Edge Cloud liegt architektonisch vor dem Cluster. Sie nimmt öffentlichen Traffic an, verteilt ihn über eine verteilte Multi-PoP-Infrastruktur und leitet zulässige Verbindungen an definierte Backends weiter. Bei ayedo geschieht dies über Anycast-basiertes Layer-4- und Layer-7-Loadbalancing. Die Edge Cloud ist damit nicht lediglich ein vorgeschalteter Loadbalancer für ayedo Managed Kubernetes, sondern kann auch vor eigenen oder bei anderen Providern betriebenen Kubernetes-Clustern eingesetzt werden.
Auf dieser Ebene liegen Aufgaben, die unabhängig von einzelnen Kubernetes-Services gelten. Dazu gehören TLS-Termination, WAF-Regeln, DDoS Protection und Scrubbing an der Edge sowie Backend-Cloaking. Beim Backend-Cloaking bleiben interne Zieladressen gegenüber dem öffentlichen Client verborgen. Backend Health Checks und Failover entscheiden zusätzlich, ob ein Ziel erreichbar ist und wohin Traffic bei Störungen weitergeleitet wird.
Diese Zentralisierung reduziert den Druck, sicherheitsrelevante Regeln in jedem Cluster separat abzubilden. Gleichzeitig bleibt das Cluster für die eigentliche Anwendungs- und Servicekonfiguration verantwortlich.
3. Routing und TLS brauchen eine eindeutige Besitzerschaft
Routing wird problematisch, wenn dieselbe Entscheidung an mehreren Stellen getroffen wird. Ein Beispiel: Die Edge Cloud leitet /api an einen Cluster-Endpunkt weiter, während der Ingress denselben Pfad nochmals aufteilt. Das ist nicht grundsätzlich falsch, erhöht aber die Zahl der Regeln, die bei Änderungen synchron bleiben müssen. Unterschiedliche Prioritäten, Rewrite-Regeln oder Statuscodes erschweren die Fehlersuche.
Eine belastbare Struktur trennt deshalb grob zwischen äußerem und innerem Routing. Die Edge Cloud entscheidet, welcher öffentliche Hostname oder Service welchen geschützten Backend-Endpunkt erreicht. Der Kubernetes Ingress entscheidet anschließend, welcher Service innerhalb des Clusters den Request verarbeitet. Diese Aufteilung sollte dokumentiert und anhand von Request-Fluss, Zuständigkeit und Änderungsprozess überprüfbar sein.
Dasselbe gilt für TLS-Termination. Wird TLS an der Edge beendet, erhält der Ingress typischerweise bereits eine weitergeleitete Verbindung. Dann müssen Protokoll, ursprüngliches Schema und gegebenenfalls Client-Informationen konsistent übertragen werden. Wird TLS zusätzlich im Cluster terminiert, handelt es sich um eine bewusste Ende-zu-Ende-Entscheidung mit eigenem Zertifikats- und Betriebsaufwand, nicht um eine zufällige Doppelkonfiguration.
4. Sicherheitslogik gehört an die passende Grenze
WAF und DDoS-Schutz wirken am sinnvollsten, bevor schädlicher oder übermäßiger Traffic das Cluster erreicht. Eine Edge-Plattform kann diese Prüfungen am öffentlichen Eingang durchführen und nur den zugelassenen Traffic an die Kubernetes-Umgebung weitergeben. Das schützt nicht nur einzelne Ingress-Regeln, sondern die Erreichbarkeit der vorgelagerten Anwendungsschicht insgesamt.
Der Ingress bleibt trotzdem sicherheitsrelevant. Er begrenzt, welche Services intern über HTTP erreichbar sind, und kann Routing- oder Authentifizierungsanforderungen der Anwendung unterstützen. Er ersetzt aber keine Edge-Schutzfunktionen, wenn Angriffe oder große Traffic-Spitzen bereits Netzwerk- und Clusterressourcen beanspruchen.
Organisatorisch ist entscheidend, wer Regeln ändern darf und wie Änderungen getestet werden. Edge-Regeln sollten nicht unkontrolliert aus einzelnen Deployment-Repositories entstehen, während Ingress-Konfigurationen gleichzeitig globale öffentliche Erreichbarkeit verändern. Ein gemeinsames Modell aus Verantwortlichkeiten, Versionsverwaltung und Beobachtung der Traffic- und Usage-Statistiken verhindert, dass Sicherheits- und Routinglogik zwischen Plattform- und Anwendungsteams auseinanderläuft.
Praxis- und Architekturszenario
Ein Unternehmen betreibt ein Kubernetes-Cluster bei einem externen Provider. Die öffentliche API soll unter api.example.de erreichbar sein. Die ayedo Edge Cloud übernimmt Anycast-DNS, TLS-Termination, WAF, DDoS-Schutz und das Backend-Cloaking. Als Backend ist ein öffentlich erreichbarer Cluster-Endpunkt hinterlegt; Health Checks erkennen, ob dieser verfügbar ist.
Im Cluster beschreibt eine Kubernetes-Ingress-Ressource nur noch die Weiterleitung von api.example.de zu den Services api-v1 und api-v2. Die Edge Cloud entscheidet nicht über interne Pod- oder Service-Namen, der Ingress kennt keine globalen DDoS- oder WAF-Regeln. Fällt der Cluster-Endpunkt aus, greift das Edge-seitige Failover. Ändert das Team die Versionierung der API, bleibt die Änderung auf die Cluster-Konfiguration begrenzt.
FAQ
Ersetzt die ayedo Edge Cloud den Kubernetes Ingress?
Nein. Die Edge Cloud übernimmt den öffentlichen Eingang und Schutzfunktionen. Kubernetes Ingress routet innerhalb des Clusters zu Services und bleibt Teil der anwendungsnahen Konfiguration.
Muss TLS immer an der Edge terminiert werden?
Nein. TLS-Termination an der Edge ist eine Architekturentscheidung. Eine zusätzliche Verschlüsselung bis zum Backend kann erforderlich sein, muss aber hinsichtlich Zertifikaten und Betriebsaufwand bewusst geplant werden.
Kann die Edge Cloud vor jedem Kubernetes-Cluster eingesetzt werden?
Sie kann mit ayedo Managed Kubernetes sowie mit eigenen oder bei anderen Providern betriebenen Kubernetes-Clustern genutzt werden. Maßgeblich sind definierte, erreichbare Backends und ein konsistenter Request-Fluss.
Fazit
Kubernetes Ingress und Edge Cloud sind keine konkurrierenden Implementierungen derselben Schicht. Der Ingress organisiert die Weiterleitung zu Services im Cluster; die Edge Cloud kontrolliert den öffentlichen Zugang, Schutz, TLS-Termination und die Erreichbarkeit der Backends. Diese Trennung reduziert Konfigurationskonflikte und macht Verantwortlichkeiten prüfbar. Für Unternehmen mit mehreren Clustern oder Providern schafft eine providerunabhängige Edge-Plattform zudem eine konsistente äußere Architektur, während Teams ihre interne Kubernetes-Konfiguration eigenständig weiterentwickeln können.