Notiz

Istio Ambient Mesh: sidecarless und das Ende des doppelten Hops

Ambient hat Envoy aus jedem Pod genommen. Wo das den doppelten Hop und den Overhead beseitigt — und wo der Sidecar noch gerechtfertigt ist.

Service Mesh wird als Weg verkauft, mTLS, Ausfallsicherheit und Observability zu bekommen, ohne den Anwendungscode anzufassen. Der Preis dafür war ein Jahrzehnt lang der Sidecar: ein Envoy-Proxy neben jedem Pod, durch den der gesamte Verkehr läuft. Bequem — solange Pods in Dutzenden zählen. Im Maßstab wird der Sidecar zu einer Steuer, die alle zahlen, auch Dienste, die vom Mesh nichts außer mTLS brauchen. Ambient Mode, in Istio 1.24 im November 2024 stable geworden, nimmt Envoy aus dem Pod und schreibt diese Ökonomie neu.

Woran das Sidecar-Modell an eine Grenze stößt

Das zentrale Problem des Sidecars ist der doppelte Hop. Eine Anfrage von Pod A zu Pod B läuft durch zwei vollwertige Envoys: den ausgehenden Proxy von A und den eingehenden Proxy von B. Selbst wenn man nur mTLS auf L4 braucht, wird der Verkehr trotzdem durch zwei L7-Proxyings mit HTTP-Parsing geschleppt. Das ist Latenz und CPU bei jedem Aufruf.

Dann kommen die Betriebskosten. Ein Envoy in jedem Pod sind Hunderte Megabyte Speicher, multipliziert mit der Zahl der Replicas. Der Sidecar ist an den Lebenszyklus der Anwendung gebunden: Er muss vor dem Container starten (daher der Behelf holdApplicationUntilProxyStarts, sonst gehen die ersten Anfragen verloren), er verlangsamt das Herunterfahren und lässt sich nicht sinnvoll in Batch-Jobs einbauen. Das Aktivieren der Injection erfordert einen Neustart der Pods, und ein Upgrade der Data Plane bedeutet, die gesamte Flotte durchzurollen. Und manche Workloads vertragen einen Sidecar schlicht nicht.

Ambient: zwei Schichten statt eines Proxys

Ambient trennt das, was der Sidecar in einem einzigen Envoy hielt, in zwei unabhängige Schichten. ztunnel ist eine Per-Node-Komponente (ein DaemonSet, in Rust geschrieben), die L4 und mTLS übernimmt. Sie baut das Mesh über HBONE-Tunnel auf (mTLS innerhalb von HTTP/2 CONNECT) und verschlüsselt den Verkehr zwischen Knoten ohne einen einzigen Proxy im Pod. waypoint ist ein Envoy, der an einen Namespace oder Service Account gehängt wird und sich nur einschaltet, wenn L7 gebraucht wird: Routing nach Headern, Traffic Splitting, Retries, L7-Autorisierung.

Die Kernidee ist, eine Schicht nach tatsächlicher Nutzung zu bezahlen. Brauchen Sie billiges Zero-Trust-mTLS über den ganzen Cluster? Ein ztunnel reicht, und Envoy taucht nirgends auf. Brauchen Sie intelligentes L7 auf einem bestimmten Dienst? Sie fügen einen waypoint gezielt hinzu, nur für diesen einen.

Wo der doppelte Hop verschwindet

L4-Verkehr nimmt in Ambient den Pfad „Pod → ztunnel des Knotens → ztunnel des entfernten Knotens → Pod". Ein vollwertiger Envoy ist nicht beteiligt — ztunnel ist eine Größenordnung leichter (über vier Releases stieg seine Leistung um rund 75%). Das doppelte Proxying des Sidecars fehlt hier schlicht.

Wenn L7 wirklich gebraucht wird, wird ein waypoint in den Pfad eingefügt, nicht zwei Sidecars an beiden Enden. Statt „immer zwei schwere Envoys pro Aufruf" bekommt man „ztunnel für alle, plus einen waypoint dort, wo es etwas zu bezahlen gibt". Das ist das Ende des doppelten Hops als Pflichtabgabe.

Ein ehrlicher Gegenpunkt

Ein kostenloses Mesh gibt es nicht; nur die Form der Rechnung ändert sich. ztunnel ist pro Knoten geteilt, daher verschiebt sich der Blast Radius vom Pod zum Knoten: Sein Ausfall oder seine Überlast trifft jeden Pod auf dem Knoten, während ein abgestürzter Sidecar einen einzelnen Pod mitnahm. Das Ambient-Ökosystem ist jünger als das des Sidecars: weniger praxiserprobte Produktionsgeschichten, einige fortgeschrittene Szenarien holen noch auf, das Debugging wandert vom Per-Pod-Proxy zu den Logs von ztunnel und waypoint. Ambient setzt CNI-Kompatibilität und einen frischeren Kernel voraus. Das ist eine bewusste Architekturentscheidung, kein „einschalten und vergessen".

Wo es sich lohnt und wo nicht

Die Entscheidungsregel ist einfach. Ambient ist gerechtfertigt, wenn Sie Zero-Trust-mTLS günstig und clusterweit wollen; wenn Pods groß und dicht sind — GPU-Knoten und LLM-Inferenz, wo ein Sidecar pro Replica einen spürbaren Speicheranteil frisst (weshalb Ambient 2026 zum heißen Thema für AI-Workloads wurde); wenn der Cluster Workloads beherbergt, die keinen Sidecar annehmen. Der klassische Sidecar passt weiterhin dort, wo Sie strikte Per-Pod-Isolation oder ein Feature brauchen, das Ambient noch nicht hat. Und wenn Sie keinerlei L7-Policy, mTLS oder Mesh brauchen — reicht ein einfaches CNI; zahlen Sie nicht für Fähigkeiten, die Sie nie nutzen.

Womit anfangen

Die Stärke von Ambient ist die Inkrementalität. Es schaltet sich pro Namespace ein, ohne Neu-Injection und ohne Pod-Neustarts. Beginnen Sie mit L4: Bringen Sie ztunnel hoch und bekommen Sie mTLS über den Cluster nahezu kostenlos. Fügen Sie waypoints gezielt hinzu — nur den Diensten, die wirklich L7-Routing oder Autorisierung brauchen. Migrieren Sie nicht das ganze Mesh auf einmal: Ambient und Sidecar koexistieren, und die richtige Strategie ist, den Verkehr in Schichten zu verschieben, nicht in einem einzigen Sprung.

© 2026 axyi.ru · CC BY 4.0