Sidecar vs. Ambient: Istios internes Duell.

Zwei Datenebenen, ein Mesh

Im Sidecar-Modus injiziert Istio einen Envoy-Proxy in jeden Pod. Jede Workload bekommt ihre eigene, vollständige L4/L7-Datenebene: maximale Isolation und maximale Funktionstiefe, bezahlt mit Ressourcen und Lifecycle-Aufwand je Pod.

Der Ambient-Modus zerlegt diese Datenebene in zwei Schichten: Ein ztunnel je Node übernimmt mTLS, Identitäten und L4-Telemetrie für alle Pods des Nodes. L7-Funktionen (Routing, feingranulare Autorisierung, L7-Telemetrie) liefert ein Waypoint-Proxy, der nur dort deployt wird, wo ein Namespace oder Service ihn tatsächlich braucht. Man zahlt für L7 also nur noch dort, wo L7 gefordert ist.

GA-Status und die ehrlichen Grenzen

Ambient ist seit Istio 1.24 (Nov. 2024) GA und inzwischen die Empfehlung des Projekts für Neu-Deployments. Wichtig ist die Sprachregelung des Projekts selbst: Der Sidecar-Modus ist nicht abgekündigt, sondern bleibt unbefristet supported. Wer heute Sidecars produktiv betreibt, hat keinen Handlungsdruck.

Die relevanteste Grenze liegt bei Multi-Cluster: Ambient unterstützt Multi-Network-Multicluster erst seit März 2026 im Beta-Status. Wer heute produktive Multi-Cluster-Topologien mit Mesh-Semantik braucht, fährt im Sidecar-Modus auf dem bewährten Pfad (Multi-Primary, Primary-Remote) und beobachtet die Ambient-Beta, statt sie zu erzwingen.

Am Rand des Duells, aber erwähnenswert: Istio 1.30 bringt mit der TrafficExtension API den designierten Nachfolger der WasmPlugin-API für Erweiterungen der Datenebene, und auf der KubeCon EU 2026 wurde neben der Ambient-Multicluster-Beta auch die Gateway API Inference Extension (Beta) sowie das experimentelle agentgateway für AI- und MCP-Traffic vorgestellt. Die Plattform entwickelt sich sichtbar in Richtung Ambient und Gateway API.

Ressourcen und Betrieb

Der Sidecar-Modus skaliert Kosten linear mit der Pod-Zahl: jeder Pod trägt einen Envoy mit eigenem Speicher- und CPU-Bedarf, und jedes Proxy-Upgrade berührt die Workload (Rolling Restart). Ambient entkoppelt das: ztunnel läuft als schlankes DaemonSet, und Upgrades der Datenebene fassen die Anwendungs-Pods nicht mehr an. Auf konkrete ztunnel-Verbrauchszahlen verzichten wir hier bewusst; belastbare, allgemeingültige Messwerte liegen uns nicht vor, und der Effekt hängt stark vom Workload-Profil ab.

Operativ verschiebt Ambient den Aufwand: weniger Moving Parts je Pod, dafür ein neues Betriebsmodell mit ztunnel und Waypoints, das das Team lernen muss. Debugging-Pfade, Kapazitätsplanung für Waypoints und das Zusammenspiel mit NetworkPolicies sind anders als in der Sidecar-Welt.

Der Migrationspfad: offiziell und reversibel

Istio dokumentiert die Migration von Sidecar nach Ambient als offiziellen, schrittweisen Prozess: Namespace für Namespace, mit Koexistenz beider Modi im selben Mesh während der Umstellung. Und, oft übersehen: Der Pfad ist reversibel. Ein Namespace, der im Ambient-Modus Probleme macht, kann zurück auf Sidecars, ohne das Mesh zu verlassen. Das nimmt der Entscheidung die Endgültigkeit und erlaubt echte Pilot-Migrationen statt Big-Bang-Umstellungen.

Entscheidungsleitfaden

Neu-Deployment

• Standardfall: mit Ambient starten. GA, geringerer Overhead, einfacherer Pod-Lifecycle, und L7 per Waypoint genau dort, wo es gebraucht wird.
• Ausnahme: produktives Multi-Network-Multicluster ist ab Tag eins Pflicht. Dann heute noch Sidecar wählen oder den Beta-Reifegrad der Ambient-Multicluster-Unterstützung explizit bewerten.

Bestands-Deployment mit Sidecars

• Kein Handlungsdruck: Der Sidecar-Modus bleibt unbefristet supported. „Sidecar ist tot" ist eine Schlagzeile, keine Projektaussage.
• Migrieren lohnt, wenn Sidecar-Overhead oder Upgrade-Aufwand real schmerzen: dann namespace-weise, beginnend mit unkritischen Workloads, mit Rückweg-Option.
• Nicht migrieren, nur um migriert zu sein: Wer stark auf EnvoyFilter oder Wasm-Erweiterungen je Workload baut, prüft zuerst, wie diese Anforderungen im Ambient-Modell (und künftig mit der TrafficExtension API) abgebildet werden.