Der Tod des Sidecars: Implementierung von Ztunnels in Istio Ambient Mesh

Sind Proxy-Sidecars Ihre Kubernetes-Compute-Ressourcen am Limit? Gehen Sie in die ztunnel-freie Zukunft mit Ambient Mesh Ztunnels, die das HBONE-Protokoll für node-level, hochleistungsfähiges Zero-Trust-Routing verwenden.

Im sich schnell entwickelnden Ökosystem der cloud-nativen Infrastruktur hat kaum eine Technologie einen so dramatischen Wandel in der Betriebsphilosophie erlebt wie das Service Mesh. Seit Jahren setzt die Branche stark auf das “Sidecar”-Modell—einen dedizierten Proxy, der in jeden Kubernetes-Pod injiziert wird. Dieses Paradigma bot essentielle Funktionen wie mutual TLS (mTLS), Observability und granulare Traffic-Kontrolle. Mit wachsender Clustergröße und zunehmender Enterprise-Adoption wurden die architektonischen Schwächen des Sidecar-Modells jedoch unübersehbar: Es verbrauchte enorme CPU- und Speicherressourcen, erschwerte den Anwendungslebenszyklus und zwang Infrastruktur- sowie Anwendungs-Teams in eine enge, unflexible Verbindung.

Die Lösung ist da. Istio Ambient Mesh, das im November 2024 mit Istio 1.24 in die Allgemeinverfügbarkeit ging, inklusive ztunnel, Waypoints und aller APIs, die vom Istio Technical Oversight Committee als stabil markiert wurden, ist jetzt die Standard-Implementierung für neue Kubernetes-Service-Mesh-Deployments. Im Zentrum dieser Transformation steht der Ztunnel (Zero Trust Tunnel)—ein node-level Proxy, der die Sicherung und Weiterleitung von Kubernetes-Traffic grundlegend verändert.

In diesem Leitfaden erklären wir die Mechanik von Istio Ambient Mesh und Ztunnel, das HBONE-Protokoll, wie der Istio CNI den Traffic umleitet, und wohin das Projekt bis 2026 steuert.

---

Das Zeitalter des Sidecars: Warum es sterben musste

Um das Design von Ambient Mesh zu verstehen, müssen wir zunächst die Probleme des ersetzten Modells nachvollziehen. Die traditionelle Service Mesh Data Plane basierte auf einem Proxy—typischerweise Envoy—der als sekundärer Container in jedem Anwendungspod lief.

Während dies exzellente Isolation und Pod-Kontext bot, war der Overhead erheblich:

Ressourcenverschwendung durch Compute. Jeder Sidecar benötigt eigene CPU- und Speicherzuweisungen. In einer Microservices-Umgebung mit Hunderten oder Tausenden von Pods summieren sich diese Leerlauf-Ressourcen schnell. Organisationen stellten fest, dass ihre Service Mesh Infrastruktur so viel Rechenbudget verbrauchte wie die eigentliche Geschäftslogik.

Lebenszyklusbindung und betriebliche Friktionen. Da der Sidecar physisch in den Pod injiziert wird, ist der Mesh-Lebenszyklus an den Anwendungslebenszyklus gebunden. Upgrades des Proxys oder das Rotieren von Zertifikaten erforderten meist einen Rolling-Update des gesamten Anwendungs-Deployments, was Koordination zwischen Plattform- und Anwendungsentwicklern erforderte.

Das “First Packet”-Problem. Während der Pod-Initialisierung kam es zu Race Conditions, bei denen der Anwendungskontext vor dem Sidecar-Proxys startete, was zu abgebrochenen Verbindungen führte und komplexe Workarounds bei Init-Containern erforderte.

Der Layer-7-Overhead. Traditionelle Sidecars verarbeiten sowohl Layer 4 (TCP/mTLS) als auch Layer 7 (HTTP/gRPC Routing). Viele Anwendungen benötigen nur die Basissicherheit von mTLS, mussten aber den Rechenaufwand für vollständige L7-Parsing bei jeder Verbindung tragen.

Das Fazit war eindeutig: Das Sidecar-Modell war in großem Maßstab nicht nachhaltig. Die Lösung lag darin, die grundlegende Infrastruktur (Sicherheit und Identität) vom anwendungsspezifischen Traffic-Management (fortgeschrittenes L7) zu trennen.

---

Istio Ambient Mesh: Architekturübersicht

Istio Ambient Mesh adressiert diese Schwachstellen durch eine Philosophie der Transparenz und Nicht-Intrusivität. Es entfernt Sidecars vollständig und teilt die Data Plane des Service Mesh in zwei separate, unabhängig skalierbare Schichten:

• Die sichere Transport-Schicht (Layer 4): Wird durch Ztunnel realisiert, das mTLS, SPIFFE-basierte Workload-Identität, L4-Autorisierung und Netzwerk-Observability bietet.
• Die L7-Traffic-Management-Schicht: Wird durch optionale Waypoint-Proxies gehandhabt, die nur bei komplexem HTTP-Routing, Retry-Logik, per-Route RBAC, JWT-Validierung oder Rate-Limiting eingesetzt werden.

Durch die Verschiebung von mTLS in eine gemeinsame Infrastrukturkomponente ermöglicht Ambient Mesh Plattform-Teams, clusterweite Zero-Trust-Sicherheit zu aktivieren, ohne Pods zu modifizieren, Sidecars zu injizieren oder Anwendungen neu zu starten. Das Enrollen eines Workloads erfolgt mit einem einzigen Befehl:

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

Dieses Label löst die Konfiguration des Istio CNI Node Agents aus, um die Weiterleitung für alle Pods in diesem Namespace zu konfigurieren—ohne Pod-Neustart, ohne Mutations-Webhooks, ohne Init-Container.

---

Ztunnel im Detail: Der node-level Zero Trust Proxy

Das Herzstück von Ambient Mesh ist der Ztunnel (Zero Trust Tunnel). Anders als die funktionsreichen Envoy-Sidecars der Vergangenheit ist Ztunnel ein speziell entwickelter, hochoptimierter Layer-4-Proxy, geschrieben in Rust. Die initiale Ambient Mesh-Implementierung nutzte Envoy für Ztunnel, doch das Istio-Team stellte fest, dass Envoys umfangreiches L7-Feature-Set—ideal für Gateways und Waypoints—im Ztunnel nur verschwendet war, und dass die Anpassung von Envoy an die spezifischen Anforderungen von Ztunnel unpraktisch ist. Die eigens entwickelte Rust-Implementierung, angekündigt im Februar 2023, löste dieses Problem.

Architektur und Deployment

Ztunnel läuft als Kubernetes DaemonSet, also genau eine Instanz pro Node, die von allen Workloads auf diesem Node gemeinsam genutzt wird. Seine Aufgaben beschränken sich auf die Grundpfeiler des Zero Trust:

• Mutual TLS (mTLS): Verschlüsselt den Traffic zwischen Workloads mit AES-GCM, einem Cipher, der für moderne Hardware optimiert ist.
• SPIFFE-Identitätsmanagement: Ztunnel agiert als CA-Client, fordert und verwaltet kurzlebige X.509-Zertifikate mit SPIFFE-Identitäten von Istiod im Auftrag der auf dem Node befindlichen Workloads. Die Identität folgt dem Format spiffe://<trust-domain>/ns/<namespace>/sa/<service-account>.
• L4-Autorisierungsrichtlinien: Erzwingt “Wer darf mit wem sprechen”-Regeln basierend auf Workload-Identität.
• L4-Observability: Exportiert TCP-Metriken und Zugriffslogs, inklusive Quell- und Ziel-SPIFFE-Identitäten pro Verbindung.

Ztunnel kommuniziert auch mit Istiod als xDS-Client, erhält speziell auf seine L4-Rolle zugeschnittene xDS-Konfiguration—unterschiedlich von der vollen xDS-Konfiguration, die an Envoy-Sidecars oder Waypoints verteilt wird.

Leistung und Effizienz

Da Ztunnel strikt auf Layer 4 arbeitet und in Rust geschrieben ist, ist sein Ressourcenprofil bemerkenswert schlank. Laut offiziellen Istio-Performance-Benchmarks verbraucht ein einzelner Ztunnel bei 1.000 Anfragen pro Sekunde ca. 0,06 vCPU und 12 MB RAM. Eine typische Ztunnel-Instanz nutzt im Leerlauf 30–50 MB RAM, mit minimaler CPU-Auslastung.

Das Ztunnel-Team hat kontinuierliche Performance-Verbesserungen in jedem Quartalsrelease implementiert, inklusive Migration zu rustls (einer Hochleistungs-TLS-Bibliothek), Reduktion der Datenkopien bei ausgehendem Traffic, dynamischer Anpassung der Puffergrößen und Migration zu AWS-LC—einer kryptografischen Bibliothek, optimiert für moderne Hardware.

Diese Verbesserungen summieren sich erheblich. Im Vergleich zum Sidecar-Modell nutzt der ztunnel-only Ambient-Modus in Benchmarks etwa 1% der CPU und 1% des Speichers eines vergleichbaren Sidecar-Deployments. Selbst bei Waypoint-Proxies für L7-Services sinkt die CPU-Last auf rund 15%, der Speicherverbrauch auf ca. 10%.

In einem Cluster mit 1.000 Pods auf 100 Nodes:

Modell	Proxy-Anzahl	CPU-Overhead	Speicher-Overhead
Sidecar (Envoy pro Pod)	1.000	~100 vCPU	~128 GB
Ambient L4 nur (Ztunnel DaemonSet)	100	~6–7 vCPU	~1,2–5 GB
Ambient mit Waypoints (20% der Services)	100 + ~wenige Waypoints	~15–20 vCPU	~13–15 GB

Die Reduktion der zugewiesenen Ressourcenanfragen allein—ohne tatsächliche Nutzung zu messen—beträgt etwa 90% für L4-only Ambient und ca. 80%, wenn Waypoints für eine Service-Teilmenge eingesetzt werden.

In Bezug auf Latenz zeigen offizielle Istio 1.23 Benchmarks, dass zwei Ztunnel-Hops (Client- und Server-Seite) etwa 0,17 ms bei P90 und 0,20 ms bei P99 im Vergleich zum Baseline bei HTTP/1.1-Traffic mit 1.000 Anfragen pro Sekunde und aktivierter mTLS hinzufügen.

Wahrung der Per-Workload-Identität

Ein häufig geäußerter Kritikpunkt an node-level Proxies ist, dass sie die Pod-Identität auf eine “Node-Identität” zusammenfassen. Ztunnel vermeidet dies explizit. Obwohl es über alle Pods auf einem Node geteilt wird, verwaltet es Zertifikate im Auftrag jedes einzelnen Workloads.

Wenn Pod A auf Node 1 mit Pod B auf Node 2 kommuniziert:

1. Der Ztunnel auf Node 1 fordert ein einzigartiges X.509-Zertifikat für Pod A’s Service Account bei Istiod an, mit Pod A’s SPIFFE-Identität.
2. Istiod prüft, ob der Ztunnel berechtigt ist, im Namen von Pod A zu handeln (über Kubernetes RBAC auf den Service Account).
3. Der mTLS-Handshake nutzt das spezifische SPIFFE-Zertifikat von Pod A. Der Ziel-Ztunnel auf Node 2 validiert diese Identität gegen die L4-AuthorizationPolicy von Pod B.

Das Ergebnis ist eine strenge, kryptografische Zero-Trust-Identität auf Workload-Ebene—ohne den Overhead eines Pod-Proxys.

---

Das HBONE-Protokoll: Standardsbasierte sichere Tunnel

Um Roh-TCP-Traffic zwischen Nodes sicher zu transportieren, ohne Anwendungen zu belasten, nutzt Istio Ambient Mesh HBONE (HTTP-Based Overlay Network Environment)—ein Istio-spezifisches Tunneling-Protokoll, das aus drei offenen Standards besteht:

• HTTP CONNECT (RFC 7540) zum Aufbau der Tunnel-Verbindung
• HTTP/2 zur Multiplexung mehrerer Anwendungskontexte über einen einzigen, gesicherten Tunnel und zum Transport von Stream-Metadaten
• mTLS zur Verschlüsselung und gegenseitigen Authentifizierung des Tunnels

Standardmäßig hören Ztunnel und andere HBONE-fähige Proxies auf TCP-Port 15008. Das hat praktische Auswirkungen: Falls bestehende NetworkPolicy-Objekte eingehende Ports auf ambient-registrierten Pods einschränken, muss eine explizite Ausnahme für Port 15008 oder HBONE-Traffic hinzugefügt werden, sonst wird der Traffic blockiert.

Warum kein Raw mTLS?

Die Verwendung von HTTP/2 CONNECT als Träger anstelle einer reinen mTLS-Verbindung bietet technische Vorteile. HTTP/2-Multiplexing erlaubt eine einzelne mTLS-Verbindung zwischen zwei Ztunnel-Instanzen, die Traffic für viele Pod-zu-Pod-Verbindungen transportiert, was die Verbindungs-Overhead bei großem Scale erheblich reduziert. Die HTTP CONNECT-Anfrage trägt außerdem die Ziel-IP und den Port im :authority-Header, und die Quell-Workload-Identität wird im TLS-Client-Zertifikat während des Handshakes übertragen.

HBONE ist interoperabel: Sidecar-Envoy-Proxies können HBONE sprechen, was eine Koexistenz von Ambient- und Sidecar-Workloads im selben Cluster während einer schrittweisen Migration ermöglicht.

Der HBONE-Paketfluss

Wenn Pod A eine unverschlüsselte TCP-Verbindung zu einem Service sendet:

1. Interception: Die Istio CNI leitet ausgehenden Traffic von Pod A’s Netzwerk-Namespace an den lokalen Ztunnel um, bevor er die Standard-Routing-Tabellen erreicht.
2. Encapsulation: Der lokale Ztunnel kapselt den TCP-Stream in eine HTTP/2 CONNECT-Anfrage, die die Ziel-IP:Port in :authority trägt.
3. mTLS-Handshake: Der lokale Ztunnel initiiert eine mTLS-Verbindung zum Ziel-Ztunnel auf Port 15008, mit Pod A’s SPIFFE-Zertifikat.
4. Decapsulation: Der Ziel-Ztunnel prüft die Identität von Pod A gegen die L4-AuthorizationPolicy von Pod B, entpackt die HTTP/2-Hülle und liefert den ursprünglichen TCP-Stream an Pod B.

Aus Sicht von Pod A: Es hat eine normale TCP-Verbindung aufgebaut. Aus Sicht des Netzwerks: Der Traffic durchläuft einen multiplexierten, mTLS-verschlüsselten, identitätsauthentifizierten HBONE-Tunnel.

---

Traffic-Weiterleitung: Istio CNI, iptables, GENEVE und eBPF

Die Übertragung von Traffic aus einem Anwendungspod in den node-level Ztunnel ohne Modifikation der Anwendung ist eine bedeutende technische Herausforderung. Istio löst dies durch den Istio CNI node agent, der Pod-Lifecycle-Events überwacht und Weiterleitungsregeln dynamisch konfiguriert.

Das Standardverfahren: iptables + GENEVE

In der Standardkonfiguration nutzt das Istio CNI eine Kombination aus iptables-Regeln und GENEVE (Generic Network Virtualization Encapsulation) Overlay-Tunneln, um Pod-Netzwerk-Namespace mit dem Ztunnel zu verbinden. Der Ztunnel-Pod stellt die Schnittstellen pistioin und pistioout bereit, die über diese Tunnel mit den istioin- und istioout-Schnittstellen des Nodes verbunden sind. Eingehender Traffic auf dem Inbound-Tunnel wird an den Ztunnel-Port 15008 (HBONE) oder 15006 (plaintext) weitergeleitet; ausgehender Traffic von Pods geht an Port 15001.

TPROXY (Linux-Transparenter Proxy) markiert eingehende Pakete aus den Tunneln und leitet sie an die Ztunnel-Ports weiter, wobei die ursprüngliche Quell-IP und der Port erhalten bleiben, damit Upstream-Policy-Checks die echten Workload-Adressen sehen.

Die eBPF-Alternative

Istio hat eine optionale eBPF-basierte Traffic-Redirection-Mode hinzugefügt. Bei Aktivierung wird ein eBPF-Programm in die Istio CNI-Komponente kompiliert und an Traffic Control (TC) ingress und egress hooks der relevanten Netzwerkschnittstellen angehängt. Das CNI überwacht Pod-Events und hängt das eBPF-Programm bei Verschiebung in den Ambient-Modus an oder entfernt es.

Das eBPF-Programm arbeitet im Kernel-Space und kann Pakete direkt an den Ztunnel umleiten, wodurch die Overhead durch iptables-Chain-Durchlauf und GENEVE-Encapsulation entfällt. Der Ztunnel führt eine Verbindungs-Lookup in der eBPF-Map durch, um die richtige Weiterleitung für jedes Paket zu bestimmen.

Vorteile des eBPF-Pfades:

• Kernel-Effizienz: Vermeidet Kontextwechsel zwischen Kernel und User Space.
• Kein GENEVE-Overhead: Pakete werden kernel-intern umgeleitet, ohne Encapsulation.
• Flexible Programmierbarkeit: eBPF-Programme können ohne Kernelmodul-Reloads aktualisiert werden und zusätzliche Paketkontextinformationen für individuelle Routing-Logik nutzen.
• Transparent für die Anwendung: Der Pod sieht nicht, wie der Traffic umgeleitet wird.

Der eBPF-Modus ist derzeit optional und nur innerhalb des Ambient-Modus aktivierbar, da CNI-Kompatibilität erforderlich ist. Der Standardpfad iptables + GENEVE wird von allen Kubernetes-CNI-Plugins unterstützt, inklusive Cilium, Calico, OpenShift SDN und Amazon VPC CNI.

---

Entkopplung von Layer 7: Waypoint-Proxies

Wenn Ztunnel die Sicherheit auf Layer 4 übernimmt, was passiert mit erweiterten Layer-7-Funktionen wie HTTP-Header-basiertes Routing, Traffic-Splitting, Circuit Breaking, per-Route RBAC, JWT-Validierung und detailliertem Distributed Tracing?

Ambient Mesh führt Waypoint-Proxies ein, um diese Anforderungen zu erfüllen. Ein Waypoint ist eine standardisierte Envoy-Instanz, die unabhängig deployed wird—pro Namespace, pro Service oder pro Service-Account—nicht als Sidecar. Waypoints besitzen ihre eigene SPIFFE-Identität (waypoint-sa) und werden mittels Kubernetes Gateway API-Ressourcen bereitgestellt, was sie zu einer ersten Klasse der Netzwerkinfrastruktur macht, anstatt nur eine Ergänzung zu Anwendungen.

Die Architektur ist strikt Opt-in. Ztunnel erkennt automatisch, wenn ein Ziel eine Waypoint-Proxy konfiguriert hat, und leitet den Traffic vor der Zustellung durch einen HBONE-Tunnel. L4-AuthorizationPolicy bleibt auf Ztunnel-Ebene bestehen; L7-AuthorizationPolicy wird beim Waypoint durchgesetzt.

Ein praktisches Deployment-Muster: 80 % der Services werden nur durch Ztunnel (mTLS, SPIFFE, L4-Policy) geleitet, nur die verbleibenden 20 % mit echten HTTP-Header-Routing, Canary-Traffic-Splitting oder feinkörniger L7-RBAC werden durch Waypoints abgedeckt. Diese selektive Nutzung vermeidet den “Layer 7-Overhead” bei Traffic, der ihn nicht benötigt.

Ein aktuelles Limit: Waypoints erzwingen Policies anhand der ursprünglichen Workload-Identität (nicht der Waypoint-Identität), aber die EnvoyFilter API—häufig bei Sidecars für Low-Level-Envoy-Anpassungen genutzt—wird im Ambient-Modus nicht unterstützt. Erweiterungen müssen WebAssembly-Plugins verwenden.

---

Zukunft von Ambient Mesh: Roadmap 2025–2026

Das Istio-Projekt veröffentlichte eine klare Roadmap für 2025–2026 mit drei Hauptthemen:

Migrationsparität vom Sidecar zum Ambient. Das Projekt investiert in Tools zur Bewertung der Migrationsbereitschaft, in rollierend-sichere Interoperabilität zwischen Sidecar- und Ambient-Namespace im selben Cluster sowie in umfassende Dokumentation. Die Schließung der wichtigsten Funktionslücken—insbesondere Multi-Cluster-Traffic-Management und Erweiterbarkeit—steht im Fokus.

Multi-Cluster Ambient Mesh. Multi-Cluster-Unterstützung wurde als Alpha in Istio 1.27 (August 2025) veröffentlicht, initiiert von Microsoft. Es erweitert die modulare Architektur von Ambient, um sichere Konnektivität, Service-Discovery und Load-Balancing über Cluster hinweg zu ermöglichen—eine der meistgefragten Funktionen bei Enterprise-Usern. Damit wird die Basis für aktive, regionenübergreifende oder Cloud-Provider-übergreifende Konfigurationen geschaffen.

Gateway API und Erweiterbarkeit. Auf der KubeCon Europe 2026 kündigte das Istio-Projekt Ambient Multicluster Beta, Gateway API Inference Extension Beta und experimentelle Agentgateway-Unterstützung an—ein Zeichen für die Weiterentwicklung des Service Mesh vom Microservice-Netzwerk hin zu einer Traffic-Management-Plattform für KI-Inferenz-Workloads. Der Sail Operator (2025 veröffentlicht) bietet eine vereinfachte Verwaltung von Istio-Deployments via Kubernetes Operator Pattern.

---

Praktische Implementierung: Ambient Mesh aktivieren

Für Teams, die Ambient Mesh evaluieren oder migrieren, empfiehlt sich eine schrittweise, namespace-weise Einführung.

Ambient-Profil installieren:

istioctl install --set profile=ambient

Namespace registrieren:

kubectl label namespace my-app istio.io/dataplane-mode=ambient

Waypoints für L7-Funktionen in einem Namespace deployen:

istioctl waypoint apply -n my-app --enroll-namespace

Ztunnel bei Verbindungen überwachen (Achten Sie auf SPIFFE-Identitäten in den Access-Logs):

kubectl logs -n istio-system daemonset/ztunnel -f

Sie sehen Logzeilen mit den Feldern src.identity und dst.identity, die die SPIFFE-URIs der Quell- und Ziel-Workloads enthalten—Bestätigung, dass die Per-Workload-Identität auf Node-Ebene erhalten bleibt.

Bei Bedarf rückrollen (ohne Pod-Neustarts):

kubectl label namespace my-app istio.io/dataplane-mode- --overwrite

---

Fazit: Der Sidecar ist tot, lang lebe das Mesh

Das Service Mesh ist heute eine Grundvoraussetzung für sicheres Arbeiten in cloud-nativen Umgebungen—doch die architektonische Belastung durch das Sidecar-Modell drohte, viele Organisationen von der Adoption abzuhalten. Der Rechenaufwand war erheblich, die Betriebsaufwände waren hoch, und die Lebenszyklusbindung war problematisch.

Mit Istio Ambient Mesh, das seit Istio 1.24 vollständig produktiv ist, werden diese Probleme auf Architekturebene gelöst. Durch die Trennung von L4-Sicherheit (ztunnel, als DaemonSet in Rust mit ca. 0,06 vCPU und 12 MB pro Node bei 1.000 RPS) und L7-Traffic-Management (Waypoints, optional pro Service) erfüllt das Projekt das ursprüngliche Versprechen des Service Mesh—robuste Zero-Trust-Sicherheit, tiefe Observability und granulare Kontrolle—ohne den belastenden Overhead.

Das HBONE-Protokoll, das HTTP/2, HTTP CONNECT und mTLS über Port 15008 kombiniert, bietet einen standardsbasierten, multiplexenden, identitätsauthentifizierten Tunnel, der für Anwendungen unsichtbar ist. Der Istio CNI sorgt für transparentes Traffic-Interception durch iptables und GENEVE, mit einer eBPF-basierten Schnellpfad-Option für Umgebungen, bei denen Kernel-Effizienz und geringerer Encapsulation-Overhead Priorität haben.

Für Plattform-Teams im Jahr 2026 ist die Entscheidung klar: Ambient Mode ist die Standard-Option für neue Kubernetes-Service-Mesh-Deployments. Sidecars bleiben für spezielle technische Anforderungen verfügbar und werden unterstützt—doch für die überwiegende Mehrheit des Enterprise-Microservice-Traffics ist die Ära, in der man den Sidecar-Overhead bezahlen musste, vorbei.

---

Changelog

Folgende Korrekturen und Ergänzungen wurden am Originalentwurf vorgenommen, basierend auf recherchierten Quellen:

Korrektur — GA-Release: Das ursprüngliche Dokument beschrieb Ambient Mesh als voll produktiv und ausgereift bis 2026. Korrekt: Ambient Mesh GA wurde in Istio 1.24, 7. November 2024, veröffentlicht, inklusive ztunnel, Waypoints und aller APIs, die vom Istio TOC als stabil markiert wurden.

Korrektur — Ztunnel-Speicherbenchmark: Das ursprüngliche Statement “weniger als 15 MB RAM” wurde korrigiert. Offizielle Istio-Performance-Dokumentation berichtet 12 MB bei 1.000 RPS für den ztunnel-Proxy; typischer Idle-Verbrauch liegt bei 30–50 MB. Die 15 MB-Zahl war unbelegt und inkonsistent.

Korrektur — eBPF als Standard: Das ursprüngliche implizierte, dass eBPF-basierte Redirection der “Industrie-Standard” für Ambient Mesh 2026 sei. Korrekt: iptables + GENEVE ist der Standard; eBPF-basierte Redirection ist ein optionaler Modus innerhalb des Istio CNI. Der eBPF-Pfad eliminiert die Notwendigkeit für GENEVE-Encapsulation, erfordert aber CNI-Kompatibilität.

Korrektur — HBONE-Protokoll: Das ursprüngliche beschrieb HBONE als Verwendung von “HTTP/2 CONNECT (oder HTTP/3 in neueren Iterationen).” Es gibt keine öffentlich dokumentierte HTTP/3-Variante von HBONE. Korrekt: HBONE kombiniert HTTP CONNECT, HTTP/2 und mTLS—alle drei offene Standards.

Korrektur — Ursprung von Ztunnel: Das ursprüngliche Dokument erwähnte nicht, dass Ztunnel ursprünglich in Envoy implementiert wurde, bevor es in Rust neu geschrieben wurde. Der Envoy-zu-Rust-Übergang (ankündigt Februar 2023) ist architektonisch relevant und wurde ergänzt.

Hinzugefügt — SPIFFE-Identitätsdetails: Details, wie Ztunnel die Workload-spezifische SPIFFE-Identität (spiffe://<trust-domain>/ns/<namespace>/sa/<service-account>) im mTLS-Client-Zertifikat trägt und wie Istiod die Berechtigung zur Vertretung prüft.

Hinzugefügt — HBONE-Port 15008 und NetworkPolicy: Hinweis, dass bestehende NetworkPolicy-Objekte Port 15008 für ambient-registrierte Pods explizit erlauben müssen, sonst wird HBONE blockiert.

Hinzugefügt — Limitierungen bei Waypoints: Die EnvoyFilter API wird im Ambient-Modus nicht unterstützt; Erweiterungen müssen WebAssembly-Plugins verwenden.

Hinzugefügt — Roadmap 2025–2026: Multi-Cluster Alpha in Istio 1.27 (August 2025), Migrations-Tools in Istio 1.28–1.29, Ankündigungen auf KubeCon Europe 2026.

Hinzugefügt — Latenz-Benchmarks: Offizielle P90/P99-Latenz von Istio 1.23: ca. 0,17 ms / 0,20 ms bei zwei Ztunnel-Hops, 1.000 RPS, mTLS.

Entfernt — Unbelegte “80-80%”-Reduktionsangabe: Die ursprüngliche Aussage zu “über 70-80%” Ressourcenreduktion wurde durch konkrete, belegte Zahlen ersetzt: 99% CPU- und RAM-Reduktion bei L4-only Ambient (Solo.io Benchmark), 85% CPU und 90% RAM bei Waypoints für ca. 20% der Services.