Sidecar-Injection bei Istio: Wie sie funktioniert – und was Ambient Mode anders macht

Ganz ehrlich: “Ist Istio ein Sidecar?” ist eine Frage, die mir öfter begegnet, als mir lieb ist. Kurze Antwort: Nein. Sidecar ist ein Modus, in dem Istio läuft – kein Gegenstück dazu. Istio kommt genauso gut komplett ohne Sidecars aus, im sogenannten Ambient Mode. Verwechslung geklärt. Weiter geht’s mit der eigentlich interessanten Frage.

Sidecar-Injection in einem Satz

Startest du einen Pod im klassischen Sidecar-Modus, klinkt sich Istio automatisch mit ein: Neben deinem App-Container landet ein zweiter Container im Pod, ein vollständiger Envoy-Proxy. Der macht mTLS, Routing, Retries – den kompletten Istio-Job. Eleganter Trick. Hat nur einen Haken: Jeder einzelne Pod schleppt seinen eigenen kompletten Proxy mit sich rum.

Meine klare Ansage: Fresh-Start heißt Ambient Mode

Startest du heute frisch, würde ich dir immer zu Ambient Mode raten. Punkt. Es nutzt die Gateway API statt proprietärer CRDs. Und es ist schneller – nicht gefühlt, gemessen.

Guck dir das mal an – nicht geraten, nachgerechnet. 100 Services, rund 300 Pods, 20 Nodes. Sidecar-Modus: 18.000 MB. 18 GB, nur für die Proxys. Ambient Mode für dieselbe Last, inklusive L7 über Waypoints: 1.400 bis 6.200 MB. Im besten Fall 12-mal weniger. Im schlechtesten Fall immer noch 3-mal weniger.

Warum das so auseinanderklafft? Bei Sidecar trägt jeder einzelne Pod seinen eigenen vollen Proxy mit sich rum (rund 60 MB pro Pod). Bei Ambient übernimmt ein einziger, schlanker Ztunnel-Prozess pro Node (12 MB) die Grundabsicherung für alle Pods, die dort laufen – erst dort, wo wirklich L7-Verarbeitung gebraucht wird, kommt ein Waypoint-Proxy dazu. Diese Zahlen stammen direkt aus Istios eigener Performance-Doku, nicht aus der Luft gegriffen.

Trotzdem: Viele laufen noch auf Sidecar

Und trotzdem sehe ich in Trainings ständig Teams, die immer noch auf Sidecar unterwegs sind – Jahre nachdem Ambient Mode seit Istio 1.24 GA ist. Kein Beinbruch. Ein laufendes Sidecar-Setup ist nicht automatisch falsch, nur weil’s die ältere Variante ist. Migration ist eine Kosten-Nutzen-Rechnung, kein Muss – meine Ansage von oben gilt für den Neustart, nicht als Aufforderung, produktive Meshes über Nacht umzukrempeln.

Die drei echten Ausnahmen

Bei drei Szenarien würde ich auch bei einem Fresh-Start noch zu Sidecar raten. Nicht mehr, nicht weniger.

Custom-EnvoyFilter-Patches? Dann Sidecar. Waypoints können das aktuell nicht – der Issue dazu steht seit 2023 offen. WASM-Plugins übrigens schon: Die laufen über die neue TrafficExtension-API ganz normal auch auf Waypoints. Nur EnvoyFilter selbst bleibt außen vor.

Kritisches Multi-Cluster-Mesh, und zwar ab Tag 1? Auch Sidecar. Sidecar-Multi-Cluster läuft seit Jahren stabil in Produktion. Ambient-Multi-Cluster ist gerade erst mit Istio 1.27 (August 2026) in Alpha gestartet – zu früh, um da produktiv draufzusetzen, wenn’s wirklich kritisch ist.

Strikte Pod-Isolation, harte Compliance-Vorgaben pro Workload? Wieder Sidecar. Der gibt jedem Pod seinen eigenen dedizierten Proxy. Ambient teilt sich Node-Ztunnel und Waypoint-Proxys über mehrere Workloads – bei manchen Compliance-Vorgaben ein Ausschlusskriterium.

Sonst: Ambient. Ohne Wenn und Aber.

Fazit

Für den Fresh-Start bleibt’s dabei: Ambient Mode. Nicht weil’s neu und schick ist, sondern weil die Zahlen dafür sprechen. Die drei Ausnahmen oben sind genau das – Ausnahmen, keine Gegenargumente.

Und falls du gerade nicht sicher bist, ob euer Setup in eine der drei Kategorien fällt, oder ob sich bei euch eine Migration überhaupt lohnt: Genau solche Fragen klären wir im Istio Training direkt an eurem eigenen Cluster. Nicht am Whiteboard.