Killing the Sidecar: Migration zu sidecarlosen Service Meshes via Ambient Networking

Das Betreiben eines Envoy Sidecars in jedem einzelnen Kubernetes-Pod ist eine enorme Verschwendung von Cloud-Ressourcen. Ambient Networking trennt Layer 4 und Layer 7 Verarbeitung auf Knotenebene, eliminiert Sidecar-Overhead und bewahrt gleichzeitig die Zero-Trust-Verschlüsselung. Hier ist das vollständige Architekturmodell, basierend auf aktuellen Benchmarks und der Istio-Release-Historie bis Version 1.30.

---

Die Sidecar-Steuer: Warum das klassische Modell Cloud-Budgets sprengt

Die Entwicklung der cloud-nativen Architektur ist geprägt von Entkopplung: Anwendungen von physischen Servern via virtuelle Maschinen, Laufzeitabhängigkeiten via Container und Netzwerklogik vom Anwendungscode via Service Mesh. Seit Jahren ist das Sidecar-Proxy-Modell der Branchenstandard – bekannt gemacht durch Istio.

Dieses Modell funktioniert, indem in jeden Anwendungspod ein Envoy-Proxy-Container injiziert wird. Der Proxy überwacht den gesamten eingehenden und ausgehenden Traffic, übernimmt Mutual TLS (mTLS)-Verschlüsselung, Telemetrie, Traffic-Routing und Autorisierungsrichtlinien. Die Abstraktion ist klar. Die Kosten nicht.

Mit der Skalierung von Kubernetes-Deployments von Dutzenden auf Tausende Microservices wird ein wachsender Nachteil des Sidecar-Modells sichtbar: Für jeden Pod läuft ein vollständiger Envoy-Prozess. Dieser Steueraufwand wirkt sich auf drei Ebenen aus.

1. Ressourcenverschwendung und Cloud-Ausgaben

Envoy ist ein leistungsfähiger Proxy, benötigt aber dedizierte CPU- und Arbeitsspeicherressourcen. In Kubernetes müssen Ressourcenanfragen und -limits für jeden Container im Pod deklariert werden. Bei 1.000 Pods verwalten Sie 1.000 Envoy-Lebenszyklen.

Da Traffic-Spitzen unvorhersehbar sind, müssen Plattformteams Sidecars für Worst-Case-Lasten vorhalten. Reicht ein Sidecar 0.2 vCPU und 64 MB RAM für Spitzenverkehr, reserviert ein Cluster mit 2.500 Pods 500 vCPU und 160 GB RAM nur für Netzwerk-Handling. In vielen Unternehmen verbraucht die Service Mesh-Datenebene mehr Rechenleistung als die eigentliche Geschäftslogik.

2. Der operative Albtraum des Lifecycle-Managements

Da der Sidecar im selben Pod wie die Anwendung liegt, sind ihre Lebenszyklen gekoppelt. Das Patchen eines CVE in Envoy oder das Upgrade der Mesh-Version erfordert einen Rolling-Update aller Anwendungspods. Das verstößt gegen ein Grundprinzip: Netzwerkänderungen sollten keine Neustarts der Anwendungen verursachen.

Diese Kopplung führt auch zu Race Conditions beim Starten der Pods. Wenn der Anwendungskontainer vor dem Sidecar-Proxy initialisiert, scheitern Anfragen, es kommt zu Crash-Loops, und CI/CD-Pipelines stocken. Besonders problematisch sind Kubernetes-Jobs: Ein injizierter Sidecar, der nie endet, kann das Job-Pod dauerhaft blockieren.

3. Die “Alles-oder-Nichts”-Rechenkosten

Traditionelle Sidecars vermengen Layer 4 (L4) Sicherheit mit Layer 7 (L7) Routing. Selbst wenn ein Microservice nur mTLS braucht und keine HTTP-Wiederholungen, Header-Manipulation oder Traffic-Splitting, zahlt jeder Paketdurchlauf im Sidecar die volle L7-HTTP-Parsing-Kosten. Ein Opt-out gibt es nicht.

---

Das Ambient Networking Data Plane

Die architektonische Lösung ist Istio Ambient Mode, angekündigt im September 2022 und ab Istio 1.24 am 7. November 2024 in der General Availability. Mit GA wurden das ztunnel, Waypoints und alle APIs als stabil markiert, was volle Produktionsreife signalisiert. Das ztunnel-Image auf Docker Hub erreichte bis dahin 1 Million Downloads, mit etwa 63.000 Downloads in der letzten Woche vor Release.

Das Kernprinzip des ambient networking data plane ist eine klare Trennung: Grundsicherung (L4) ist eine allgegenwärtige, unsichtbare Eigenschaft der Infrastruktur, während erweiterte Anwendungssicherheit (L7) nur auf expliziten Wunsch angewandt wird. Dafür wird der Proxy vollständig aus dem Anwendungspod entfernt und durch zwei Komponenten ersetzt: den Ztunnel (für L4) und den Waypoint Proxy (für L7).

---

Ztunnel: Layer-4-Kernel-Transport-Sicherheit meistern

Der Ztunnel (Zero Trust Tunnel) ist die Basis des sidecarlosen Service Mesh. Es ist ein speziell entwickelter, auf Knotenebene laufender Proxy, geschrieben in Rust, gewählt wegen Speichersicherheit, Geschwindigkeit und minimalem Ressourcenverbrauch.

Ztunnel wird als Kubernetes DaemonSet deployed. Eine Instanz läuft auf jedem Knoten, unabhängig von der Anzahl der Pods. Laut offizieller Istio-Performance-Dokumentation verbraucht ein einzelner ztunnel bei 1.000 Anfragen pro Sekunde etwa 0.06 vCPU und 12 MB RAM im Dauerbetrieb. Dieses Idle- oder Low-Load-Profil ist eine bedeutende Einschränkung: bei hoher Pod-Dichte profitiert ztunnel von statistischem Multiplexing, und der tatsächliche Speicherverbrauch liegt bei 30–50 MB, abhängig von der Konfiguration.

Ztunnel arbeitet strikt auf OSI Layer 3 und 4. Es parst keine HTTP-Anfragen, liest keine JSON-Payloads und führt kein Traffic-Splitting durch. Seine Aufgaben sind:

• Aufbau und Beendigung von mTLS-Verbindungen im Namen der Pods.
• Durchsetzung von L4-Netzwerk-Policies (z.B. “Service A darf Service B auf Port 8080 erreichen”).
• Baseline-TCP-Telemetrie.

Wie Traffic Ztunnel ohne Sidecar erreicht

Der Mechanismus für transparente Interception hat sich im Verlauf der 1.x-Releases entwickelt. Der Standardmodus in aktuellen Istio-Versionen nutzt In-Pod-Weiterleitung: Der Istio CNI-Node-Agent liefert den Netzwerk-Namespace des Pods an den co-lokalen ztunnel, der dann die Weiterleitungssockets innerhalb dieses Namespace startet, während er außerhalb des Pods läuft. Der Traffic-Redirect zwischen ztunnel und Anwendungspod ist somit für alle Kubernetes-Primär-CNI unbemerkt – Cilium, Calico, Flannel und die firmeneigenen CNIs in OpenShift und EKS funktionieren konfliktfrei.

Frühere Mechanismen nutzten iptables-Regeln in Kombination mit GENEVE-Overlay-Tunneln. Diese erforderten Markierungen und Weiterleitungen im Netzwerk-Namespace, was mit vielen Drittanbieter-CNIs kollidierte. Das aktuelle In-Pod-Verfahren, eingeführt zur universellen CNI-Kompatibilität vor dem Beta-Release, hat diese Portabilitätsbarriere beseitigt.

Ein optionaler eBPF-basierter Redirection-Modus ist via redirectMode: "ebpf" Helm-Flag verfügbar. Aktivierung erfordert Kernel ≥4.20 und eliminiert GENEVE-Encapsulation, was messbare Latenz- und Durchsatzverbesserungen bringt. eBPF ist eine optionale Erweiterung; standardmäßig bleibt es bei iptables + In-Pod-Namespaces. Plattformteams mit CNI-Anforderungen oder älteren Kernel-Versionen sollten bei der Standardeinstellung bleiben.

Unabhängig vom Redirection-Mechanismus ist der Traffic-Pfad nach Ztunnel identisch:

1. Quell-Pod sendet ein TCP-Paket.
2. Der Istio CNI-Redirect leitet das Paket in den lokalen ztunnel.
3. Ztunnel erkennt den Quell-Pod, holt sein SPIFFE X.509 SVID und kapselt den Traffic mit HBONE (HTTP-Based Overlay Network Environment) – HTTP/2 CONNECT über mTLS auf Port 15008.
4. Das Paket wird zum ztunnel auf dem Zielknoten getunnelt.
5. Das Ziel-ztunnel entschlüsselt, prüft Policies und liefert das Paket an den Ziel-Pod.

Für die Anwendung erscheint das Netzwerk als eine einfache lokale Verbindung. Tatsächlich ist der Traffic vollständig verschlüsselt und mutual authentifiziert auf Knotenebene.

Betriebshinweis: Bestehende NetworkPolicy-Objekte in ambient-registrierten Namespaces müssen eingehenden Port 15008 für HBONE-Traffic erlauben, damit der Ziel-ztunnel erreicht werden kann. Das ist eine häufige Stolperfalle bei Migration.

SPIFFE-Kryptographisches Identitätsmanagement

Ztunnel verwaltet SPIFFE-Identitäten für alle Pods auf seinem Knoten. Wenn ein Pod in den ambient-Mesh aufgenommen wird, fordert ztunnel ein X.509 SVID bei Istiod im Namen des Service-Accounts an. Damit hält ztunnel mehrere unterschiedliche Identitäten gleichzeitig – eine pro Service-Account auf dem Knoten.

Die Identitäten folgen dem standardisierten Istio SPIFFE-Format:

spiffe://<trust-domain>/ns/<namespace>/sa/<service-account>

Die SPIFFE-ID ist im Subject Alternative Name des X.509-Zertifikats eingebettet und integriert direkt in die TLS-Mutual-Authentifizierung. Istiod stellt diese Zertifikate automatisch aus und rotiert sie. Für Unternehmen mit zentraler PKI-Governance unterstützt Istiod die Delegation an externe SPIRE-Deployments.

Beim Verbindungsaufbau eines Pods garantiert die Netzwerk-Namespace-Tracking-Funktion des CNI, dass ztunnel die genaue Pod-Identität kennt – sie kann nicht gefälscht werden. Das gewählte SVID für den Pod startet den mTLS-Handshake, und der Ziel-ztunnel prüft die Identität, bevor er den Traffic weiterleitet. Das ist kryptografische Per-Workload-Authentifizierung auf Knotenebene; lateral bewegte Angreifer-Pods bleiben kryptografisch blockiert, selbst wenn sie auf demselben physischen Host laufen.

---

Waypoint Proxies: Layer-7-Verarbeitung entkoppeln

Für den Großteil des internen East-West-Traffics im Cluster reicht die L4-mTLS-Abdeckung von ztunnel aus. Manche Dienste benötigen jedoch Layer-7-Logik: HTTP-Header-basiertes Routing, Canary-Deployments, Circuit Breaking, Rate Limiting oder WebAssembly-Extensions. In einem klassischen Mesh trägt jeder Pod diese L7-Kosten – in Ambient Mesh wird L7 ausschließlich von Waypoint Proxies übernommen.

Waypoints sind standardmäßige Envoy-Proxies, die außerhalb der Anwendungspods laufen, meist einer pro Namespace oder Service-Account. Sie skalieren unabhängig von der Anwendung und sind nur für die Dienste notwendig, die wirklich L7-Funktionen benötigen.

Wenn ein Service einen Waypoint nutzt, ist der vollständige Traffic-Pfad:

1. Quell-Pod sendet ein Paket.
2. Der Quell-Knoten-ztunnel fängt es ab, hängt die SPIFFE-Identität an und kapselt es mit HBONE.
3. Der Traffic wird zum Waypoint Proxy des Ziel-Services geroutet.
4. Der Waypoint beendet den HBONE-Tunnel, inspiziert HTTP-Header, wendet L7-Policies an (z.B. 10% Traffic zu einem v2-Canary), verschlüsselt neu und leitet weiter.
5. Der Ziel-Knoten-ztunnel liefert das Paket an den Ziel-Pod.
6. Der Ziel-ztunnel liefert das Paket an den Ziel-Pod.

Indem L7 explizit als Option angeboten wird, können Plattformteams Waypoints nur für Dienste einsetzen, die wirklich HTTP-Logik benötigen, und den Rest auf reines L4 beschränken.

Erweiterungsmodell: WasmPlugin und TrafficExtension API

Ein wichtiger Punkt vor der Migration: Das EnvoyFilter API ist nicht für Waypoint-Proxies unterstützt. EnvoyFilter ist seit Jahren in der Beta, wird aber wegen seiner engen Kopplung an die interne Envoy-xDS-Struktur als fragil bei Upgrades angesehen. Die Maintainer haben es bewusst nicht in den Ambient Mode portiert.

Extensions für Waypoints müssen WebAssembly (Wasm) Plugins verwenden. Damit können benutzerdefinierte Authentifizierungslogik, spezielle Telemetrie oder Request/Response-Transformationen dynamisch in den Waypoint geladen werden, ohne den Proxy neu zu bauen. Das WasmPlugin API ist das aktuelle Mittel; TrafficExtension – eine einheitliche API für Wasm und Lua für Sidecars, Gateways und Waypoints – ist in Istio 1.30 (Mai 2026) in Alpha und die zukünftige Richtung.

Teams mit umfangreichen EnvoyFilter-Implementierungen sollten die Migration zu Wasm als Priorität behandeln.

---

Proxy-Optimierung auf Knotenebene: Wirtschaftliche Auswirkungen

Die Berechnung der Migration von Pod-basierten Sidecars zu Knoten-basierten Ztunnels ist einfach, und die Zahlen bestätigen dies. Die Istio-Dokumentation und frühe Anwender berichten durchweg von Einsparungen von 70% bis 90% oder mehr bei der Rechenleistung der Mesh-Datenebene.

Stellen Sie sich ein Cluster mit 50 Knoten und 2.500 Pods vor.

Sidecar-Modell:

• 2.500 Envoy-Proxies, jeweils für Spitzenlast dimensioniert.
• Bei 0.2 vCPU pro Sidecar: 500 vCPU insgesamt.

Ambient-Modell:

• 50 Ztunnel-Instanzen (je eine pro Knoten) mit ca. 0.06–1 vCPU, abhängig von Traffic-Dichte, profitieren von statistischem Multiplexing.
• Waypoints für 10–20% der Dienste, bei 10 Instanzen ca. 1 vCPU pro Instanz.
• Gesamte Mesh-Overhead: ca. 60–100 vCPU.

Das entspricht einer 80–88%igen Reduktion bei der Rechenleistung für Netzwerk-Handling. In Cloud-Umgebungen, wo vCPU-Stunden direkt Kosten verursachen, sind die Einsparungen auf Unternehmensebene erheblich.

Die Latenz ist ebenso beeindruckend. Offizielle Istio-Performance-Benchmarks (gemessen bei 1.000 RPS, 1 KB Payload, HTTP/1.1, mutual TLS aktiviert) zeigen, dass die zwei Ztunnel-Hops eines ambient L4-Pfads nur 0.17 ms bei P90 und 0.20 ms bei P99 zusätzlich zur Baseline-Latenz benötigen. Eine peer-reviewed Studie (arXiv:2411.02267) fand, dass Istio Ambient nur eine 8%ige Latenzsteigerung bei 3.200 RPS aufweist – das beste Ergebnis aller Mesh-Implementierungen, während das klassische Istio Sidecar bei gleicher Last eine Steigerung von 166% zeigt und die 12.800 RPS-Grenze nicht erreicht.

HBONE nutzt HTTP/2 als Tunnel-Frame, was etwa 12% zusätzliche Latenz im Vergleich zu reiner TLS-Verbindung in Single-Connection-Szenarien bedeutet. Das Istio-Projekt verfolgt aktiv die Reduktion dieses Overheads. Bei Multi-Connection-Workloads dominiert das statistische Multiplexing, und das Gesamtlatenzprofil ist für die meisten realen Traffic-Muster besser als bei Sidecar.

---

Sicherheit neu definiert: Die Antwort auf den Shared-Proxy-Einwand

Ein häufiges Argument gegen einen sidecarlosen Mesh ist die Annahme, dass ein Sidecar – isoliert im eigenen Netzwerk-Namespace – sicherer sei als ein gemeinsamer ztunnel für mehrere Pods auf demselben Knoten. In der Praxis erhält das Ambient Mode-Design, und in mehreren Punkten sogar verbessert, die Zero-Trust-Position des Clusters.

Kryptografische Isolierung bleibt erhalten. Ztunnel hält für jeden Service-Account auf dem Knoten eigene X.509 SVIDs. Die In-Pod-Weiterleitung stellt sicher, dass ztunnel die genaue Pod-Identität kennt, bevor es das passende Zertifikat für den mTLS-Handshake auswählt. Es ist unmöglich, dass Pod A Pod B’s Identität fälscht, selbst auf demselben physischen Host.

Der Angriffsfläche der Envoy-Admin-API wird entzogen. In Sidecar-Mode hat ein kompromittierter Anwendungskontainer Zugriff auf die Envoy-Admin-API via localhost – ein bekannter Exploit-Vektor. Im Ambient Mode ist der Proxy nicht mehr im Pod co-located. Ein kompromittierter Anwendungskontainer hat keinen lokalen Proxy mehr, den er angreifen könnte.

Rusts Speichersicherheit eliminiert eine ganze Vulnerability-Klasse. Ztunnel ist in Rust geschrieben, was Buffer Overflows und Use-After-Free-Bugs auf Sprachebene ausschließt. Das Istio-Projekt hat Rust explizit dafür gewählt: Der Proxy, der alle kryptografischen Materialien auf Knotenebene hält, muss speichersicher sein.

Bestehende NetworkPolicy-Integration bleibt unverändert. Ztunnel verschlüsselt und authentifiziert Traffic auf Mesh-Ebene. Standardmäßige Kubernetes NetworkPolicy-Regeln funktionieren weiterhin auf CNI-Ebene, ohne Konflikte. Calico, Cilium und andere CNIs mit Deep Packet Inspection arbeiten weiterhin mit ztunnel zusammen.

---

Migration: Wie der operative Wechsel wirklich aussieht

Der Migrationspfad im Istio Ambient Mode ist bewusst so gestaltet, dass er nicht störend wirkt. Das Einbinden eines Namespaces in den Ambient-Mesh erfordert nur ein Label:

kubectl label namespace enterprise-apps istio.io/dataplane-mode=ambient

Das Istio CNI erkennt das Label, konfiguriert die In-Pod-Weiterleitung für alle neuen Pods im Namespace und beginnt, den Traffic durch den Node ztunnel zu leiten. Pods werden nicht neu gestartet. TCP-Verbindungen bleiben bestehen. Das Upgrade auf striktes mTLS erfolgt sofort und transparent.

Das Upgrade des Meshs selbst ist vollständig vom Anwendungslifecycle entkoppelt. Um eine neue ztunnel-Version zu deployen, aktualisieren Operatoren das DaemonSet – Knoten für Knoten, mit standardmäßigem Rolling-Update – während die Anwendungspods unberührt bleiben. Waypoints sind normale Kubernetes Deployments und werden wie jede andere Deployment aktualisiert. Die Netzwerk-Infrastruktur liegt nicht mehr in der Verantwortung der Entwickler.

Migration von Sidecar-Modus

Die Roadmap des Istio-Projekts für 2025–2026 priorisiert die Migration von Sidecar zu Ambient: Tools zur Migrationsbewertung, rollback-sichere Interoperabilität zwischen Sidecar- und Ambient-Namespaces im selben Cluster und umfassende Dokumentation. Sidecar ist nicht deprecated – die Maintainer haben die Unterstützung explizit zugesichert – aber die operative Investition konzentriert sich klar auf den Ambient-Pfad.

Die wichtigsten Vorbereitungsmaßnahmen für Teams mit bestehenden Sidecar-Deployments:

• EnvoyFilter-Usage prüfen. Alle Filter müssen vor der Deaktivierung der Sidecar-Injektion in Wasm-Plugins umgeschrieben werden. Das TrafficExtension API (Istio 1.30 Alpha) ist das Ziel.
• CNI-Kompatibilität validieren. Das aktuelle In-Pod-Redirection funktioniert mit allen großen CNIs, inklusive Cilium und Calico. Spezifische Versionen sollten geprüft werden.
• VirtualService-Usage prüfen. VirtualService in Ambient ist Alpha und kann nicht mit Gateway API kombiniert werden. Dienste, die VirtualService nutzen, sollten vor oder während der Migration auf HTTPRoute (Gateway API) umstellen.
• NetworkPolicy für Port 15008 anpassen. HBONE-Traffic muss eingehend auf Port 15008 erlaubt sein.

---

Die Istio Ambient Roadmap: 2025 und darüber hinaus

Seit der GA-Version 1.24 hat sich die Ambient-Mode-Funktionalität deutlich erweitert:

Istio 1.27 (August 2025): Multicluster in Ambient wurde in Alpha freigegeben. Sichere Cross-Cluster-Konnektivität, Service Discovery und Load Balancing sind mit ztunnel + Waypoints verfügbar, für aktive-aktive Konfigurationen über Cluster und Cloud-Regionen.

Istio 1.28 (November 2025): Waypoints können Traffic zu entfernten Netzwerken in Multicluster-Konfigurationen routen. L7-Policies inklusive Outlier Detection gelten auch für Cross-Network-Requests. Native nftables-Unterstützung wurde für das Ambient-Netzwerk-Management eingeführt.

Istio 1.29 (Februar 2026): Multinetzwerk-Multicluster in Beta, mit verbesserten Telemetrie-Fähigkeiten. HBONE wurde mit Baggage-Headern erweitert, um Peer-Metadaten durch East-West-Gateways zu transportieren, für präzise L7-Metriken in Multi-Cluster-Topologien. Das HBONE-HTTP/2-Window-Size-Problem wurde behoben.

Istio 1.30 (Mai 2026): Vier CVEs wurden behoben, inklusive eines RSA-Private-Key-Leaks (CVE-2026-31837) und unautorisierter XDS-Debug-Endpunkt. Das TrafficExtension API wurde in Alpha veröffentlicht, um Wasm- und Lua-Extensions zu vereinheitlichen. Das Agentgateway-Feature für AI-Inference-Workloads wurde als Experiment eingeführt. Die XDS-Authentifizierung ist Pflicht, und CNI-Konfigurationsrechte wurden auf 0600 verschärft.

KubeCon EU 2026 (Amsterdam, März 2026): CNCF kündigte die Beta-Version des Istio Ambient Multicluster, Gateway API Inference Extension Beta und experimentelle Integration von agentgateway an. Ziel ist es, Istio als Infrastruktur für KI-Workloads auf Kubernetes zu positionieren, mit 66% der Organisationen, die laut CNCF bereits generative KI auf Kubernetes betreiben.

---

Fazit: Die Zukunft ist Ambient

Der Sidecar-Proxy war ein notwendiger Meilenstein in der Entwicklung cloud-nativer Netzwerke. Er bewies, dass Zero-Trust-Architekturen in großem Maßstab machbar sind, und lehrte die Branche, Netzwerkintelligenz vom Anwendungscode zu entkoppeln. Doch die Rechenkosten, der operative Aufwand und die Lifecycle-Kopplung sind strukturelle Probleme, die im Sidecar-Modell nicht wegzudenken sind.

Der Übergang zu einem sidecarlosen Service Mesh via Ambient Networking Data Plane ist die Reifeprüfung des Service Mesh-Konzepts. Durch den Einsatz von in Rust geschriebenen, speichersicheren ztunnels als geteilte L4-Proxies auf Knotenebene und isolierte Envoy-Waypoints für on-demand L7-Logik erhalten Organisationen drei Vorteile: eine kleinere, sicherere Angriffsfläche, einen Mesh-Lifecycle, der für Anwendungsteams unsichtbar ist, und eine konkrete Reduktion der Rechenkosten um 70–90%.

Mit der GA-Veröffentlichung von Istio im November 2024, der Multicluster-Beta Anfang 2026 und der aktiven Roadmap bis Version 1.30 ist klar: Das ist keine experimentelle Infrastruktur mehr. Für neue Deployments ist Ambient Mode die Standardwahl. Für Teams mit großem Sidecar-Portfolio sind die Migrationstools und Interoperabilitätsgarantien ausgereift genug, um jetzt mit der Planung zu beginnen.

Es ist Zeit, das Sidecar zu killen und das Netzwerk ambient werden zu lassen.

---

Changelog

#	Abschnitt	Änderung
1	Gesamtes Dokument	Entfernt Metadaten-Header (Untertitel/Beschreibung).
2	Einführung	Korrektur des GA-Frames: Ambient Mode erreichte GA in Istio 1.24 am 7. November 2024 mit ztunnel, Waypoints und allen APIs als stabil markiert durch den Istio TOC – nicht “bis 2026” wie frühere Entwürfe andeuteten. Download-Milestone auf Docker Hub (über 1 Mio. Downloads, ca. 63k/Woche bei GA).
3	Sidecar-Steuer §2	Hinzugefügt: Kubernetes-Jobs / orphaned Pods als konkreter Lifecycle-Fehler, basierend auf CNCF-Ankündigung zum Ambient Mode.
4	Ztunnel §Resource	Korrektur der Speicher-Benchmarks: Offizielle Istio-Performance-Dokumente berichten 12 MB bei 1.000 RPS und typischer Idle-/Mischverbrauch von 30–50 MB. Entfernt die unzugeordnete Angabe “weniger als 15 MB”. Präziser vCPU-Wert von 0.06 pro Ztunnel-Instanz aus offiziellen Performance-Dokumenten.
5	Traffic-Interception	Korrektur und Erweiterung des Abschnitts zur Weiterleitung. Ersetzt vage Beschreibung “CNI-Plugin oder eBPF” durch genaue Darstellung: Standardmodus ist In-Pod-Namespace-Delivery (iptables); eBPF ist eine optionale Alternative ab Kernel ≥4.20; ältere GENEVE-Overlay-Mode war eine frühere Implementierung, nicht der aktuelle Standard. Quellen: Istio Blog Januar 2024, vorläufige 1.29-Dokumente.
6	HBONE	Ergänzt Portnummer (15008) und praktische Implikation für NetworkPolicy: Ambient-registrierte Pods müssen eingehenden Traffic auf Port 15008 erlauben.
7	SPIFFE	Explizites SPIFFE-ID-Format spiffe://<trust-domain>/ns/<namespace>/sa/<service-account>, X.509 SVID-Mechanismus, und Istiod-Zertifikatsmodell. Quellen: Istio SPIRE-Integration, SPIFFE-Dokumentation.
8	Waypoints §Limitations	Hinzugefügt: EnvoyFilter-API wird für Waypoints nicht unterstützt, ist in Alpha, wegen enger Kopplung fragil. Extensions müssen WebAssembly (Wasm) Plugins verwenden, z.B. für Authentifizierung, Telemetrie, Transformationen. WasmPlugin API ist aktuell, TrafficExtension in Istio 1.30 (Mai 2026) in Alpha. Teams mit EnvoyFilter-Investitionen sollten die Migration zu Wasm priorisieren.
9	Benchmarks	Offizielle Istio 1.22⁄1.23-Benchmarks: P90 = 0.17 ms, P99 = 0.20 ms für zwei Ztunnel-Hops bei 1.000 RPS mit mTLS. Peer-reviewed Vergleich (arXiv:2411.02267): Istio Ambient nur 8% Latenzsteigerung bei 3.200 RPS, klassische Sidecars 166%. HBONE HTTP/2 Overhead (~12%) in Single-Connection-Szenarien.
10	Rechenkosten	Anpassung des vCPU-Beispiels auf 0.2 vCPU pro Sidecar, was den offiziellen Istio-Richtlinien entspricht. Einsparungen von 80–88%, im Einklang mit offiziellen Aussagen (>90%) und Solo.io-Behauptungen (90%+).
11	Roadmap 2025–2026	Neue Sektion: 1.27 (Multicluster Alpha, August 2025), 1.28 (L7-Policies, nftables, November 2025), 1.29 (Multicluster Beta, Februar 2026), 1.30 (CVEs, TrafficExtension Alpha, agentgateway, Mai 2026), KubeCon EU 2026. Quellen: Offizielle Istio-Blogs, CNCF-Presse.
12	Migrations-Checkliste	Konkrete Schritte: EnvoyFilter prüfen, CNI-Kompatibilität, VirtualService-Migration, Port 15008 in NetworkPolicy.