Illustration von evv auf Shutterstock
Istio Ambient Mesh wurde im September 2022 vorgestellt – damals habe ich dem Thema allerdings nicht genug Beachtung geschenkt. Wer Istio bereits als Service Mesh einsetzt oder den Einsatz plant, sollte aber genauer hinschauen: Die Neuerung adressiert einige Schwächen des klassischen Sidecar-Modells, auf die wir in den folgenden Abschnitten eingehen.
Hinweis: Istio Ambient Mesh befindet sich noch im Alpha-Stadium und sollte erst nach dem Upgrade auf General Availability (GA) in Produktivumgebungen eingesetzt werden.
Bevor wir tiefer einsteigen, klären wir ein paar Grundbegriffe – ohne dieses Wissen wäre der Rest des Artikels für die meisten so verständlich wie Hieroglyphen.
Was ist ein Service Mesh?
Viele moderne Anwendungen basieren auf einem Geflecht verteilter Microservices, in dem jeder Microservice eine dedizierte Aufgabe erfüllt und häufig mit anderen kommuniziert. Bildlich gesprochen: ein Bauwerk aus modularen Lego-Bausteinen statt einer monolithischen, aus einem Stein gehauenen Statue.
Ein Service Mesh ist eine Schicht, die über diese Anwendungen (bzw. Microservices) gelegt wird und Funktionen wie Traffic Management, Observability und Sicherheit bereitstellt – ganz ohne Eingriffe in die Anwendungen selbst.
Funktionen des Istio Service Mesh
Istio ist ein Open-Source-Service-Mesh, das sich transparent über bestehende verteilte Anwendungen legt. Standardmäßig kommunizieren Services innerhalb eines Clusters im Klartext – aus Sicherheitssicht alles andere als ideal. Istio sichert diesen Traffic ab, indem es die Kommunikation per mTLS (mutual TLS) verschlüsselt. Darüber hinaus bietet es zahlreiche weitere Funktionen, darunter:
- Load Balancing für HTTP, gRPC, WebSocket und TCP
- Granulare Traffic-Steuerung
- Zugriffskontrollen, Rate Limits und Quotas
- Service Discovery
- Lückenlose Observability (Metriken & Telemetriedaten, Logs und Traces für den gesamten Traffic im Cluster)
Damit ist klar, was ein Service Mesh ist und welche Vorteile es bringt. Vergleichen wir nun das klassische Istio-Sidecar-Modell mit dem neuen Ambient-Mesh-Modell.
Istio-Architektur ohne Ambient Mesh
Istio besteht aus zwei grundlegenden Komponenten: einer Control Plane und einer Data Plane.
Die Data Plane bildet die Kommunikation zwischen den Services im Mesh ab. Dazu setzt das Service Mesh einen Envoy-Proxy ein, der neben jedem Service als Sidecar bereitgestellt wird. Sämtlicher ein- und ausgehender Traffic im Mesh läuft über diese Envoy-Proxies.
Die Control Plane sammelt Daten von diesen Proxies und steuert deren Konfiguration, indem sie den Ist-Zustand der Umgebung mit dem Soll-Zustand abgleicht.
Quelle: https://istio.io/latest/docs/ops/deployment/architecture/
Nachteile dieses Modells:
- Resilienz: Änderungen wie ein Upgrade der Proxies über die Control Plane erfordern den Neustart jedes Sidecar-Containers – das kann zu Unterbrechungen führen.
- Ressourcenhunger: Die Ressourcen der Sidecars müssen für den Worst Case reserviert werden – ineffizient und ein Albtraum für jede Abrechnungsabteilung.
- Traffic-Probleme: insbesondere bei Anwendungen mit nicht konformen HTTP-Implementierungen.
Das Sidecar verarbeitet sowohl Layer-4- als auch Layer-7-Traffic. Ein gravierender Punkt: Die L7-Verarbeitung ist sehr rechenintensiv – und sie wird Services praktisch aufgezwungen, auch wenn diese lediglich eine einfache Transportverschlüsselung benötigen. Hinzu kommt: Die kritischsten Common Vulnerabilities and Exposures (CVEs) im Envoy-Proxy treten auf der L7-Ebene auf. Wer Services mit L7-Filtering belastet, die das gar nicht brauchen, vergrößert also unnötig die Angriffsfläche.
Istio-Architektur mit Ambient Mesh
Istio Ambient Mesh bringt einige radikale Änderungen an der Data-Plane-Architektur mit sich. Das Modell trennt die L4- und L7-Funktionalitäten, die im Sidecar-Modell bisher nur im Paket zu haben waren.
Quelle: https://istio.io/v1.15/blog/2022/introducing-ambient-mesh/#slicing-the-layers
Statt Sidecars gibt es nun ein sicheres Overlay, das von ztunnels (Zero-Trust-Tunnels) erzeugt wird. Diese ztunnels fungieren als gemeinsam genutzte Agents und werden als DaemonSet ausgerollt – also ein Agent pro Node im Kubernetes-Cluster.
Zum Routing nutzt der ztunnel ein eBPF-Programm, das in die istio-cni-Komponente kompiliert wird. Gegenüber dem Routing über iptables bringt das spürbare Vorteile bei Performance und Flexibilität.
Jeder ztunnel ist dafür zuständig, den L4-Traffic der Workloads auf seinem jeweiligen Node abzusichern.
Für L7-Funktionen erlaubt Ambient Mesh den Einsatz Envoy-basierter Waypoint-Proxies auf Namespace-Ebene, sodass die Workloads in diesem Namespace den vollen Funktionsumfang von Istio nutzen können.
Quelle: https://istio.io/v1.15/blog/2022/introducing-ambient-mesh/#slicing-the-layers
Diese Waypoint-Proxies skalieren mit dem tatsächlichen Bedarf der Workloads im jeweiligen Namespace. Das ist deutlich effizienter und kostengünstiger, als Ressourcen für Sidecars am Worst-Case-Verbrauch zu bemessen.
Die Architektur erlaubt von Haus aus eine ergonomischere und kosteneffizientere Nutzung des Istio Service Mesh: L7-Proxies kommen nur dort zum Einsatz, wo sie wirklich gebraucht werden, gehen sparsamer mit Ressourcen um und skalieren dynamischer sowie unabhängiger.
Zudem ist Ambient Mesh interoperabel mit dem klassischen Sidecar-Modell – Sie behalten also die Wahlfreiheit.
Zwei Bedenken zu diesem neuen Data-Plane-Modell will ich hier nicht direkt vertiefen:
- Performance (aufgrund der zusätzlichen Hops):
Istio argumentiert, dass die zu erwartende Performance-Einbuße durch den zusätzlichen Hop mehr als ausgeglichen wird, weil das redundante bidirektionale L7-Filtering des Sidecar-Modells entfällt. Ein eigener Blogbeitrag zur Performance ist angekündigt – vermutlich gemeinsam mit Solo.io und Google, mit denen Istio diese Weiterentwicklung umgesetzt hat. 2. Sicherheit (aufgrund des Shared-Agent-Modells):
Wer sich Gedanken über die Sicherheitsimplikationen einer Data Plane ohne Sidecars macht, dem sei der Blog Ambient Mesh Security Deep Dive empfohlen.
Ich bin gespannt, Ambient Mesh im Produktivbetrieb zu erleben – es verspricht spürbare Kosteneinsparungen und Effizienzgewinne für alle, die es einsetzen.
Am Ende des Tages bleibt allerdings der Elefant im Raum bestehen – und wird weiterhin geflissentlich ignoriert: der Envoy-Proxy.
Ich glaube nicht, dass Sidecars so bald verschwinden. Aber vielleicht gibt es eines Tages eine leichtgewichtige, sichere und gleichzeitig leistungsstarke L7-Processing-Software, die alle Probleme von Service-Mesh-Anwendern aus der Welt schafft. Bis dahin bin ich für jeden Schritt in diese Richtung dankbar – und das sollten Sie auch sein.