Einführung von OpenShift Service Mesh 3.2 mit dem Ambient-Modus von Istio

Wir freuen uns, die allgemeine Verfügbarkeit von Red Hat OpenShift Service Mesh 3.2 ankündigen zu können. Mit diesem Release wird auch der Ambient-Modus von Istio allgemein verfügbar – eine neue Art des Service Mesh-Deployments ohne Sidecars, die die Ressourcenkosten beim Einsatz von Service Mesh erheblich senkt. Eine schlanke mTLS-Verschlüsselung zwischen Pods und Autorisierungsrichtlinien, die auf Workload-Identitäten basieren, machen die Version zu einer Lösung mit geringem Aufwand für Zero Trust-Netzwerke – mit der Option, bei Bedarf zusätzliche erweiterte Features hinzuzufügen.

Das Release, das auf den Projekten Istio, Envoy und Kiali basiert, umfasst ein Update auf Istio 1.27 sowie Kiali 2.17 und wird von Red Hat OpenShift 4.18 und höher unterstützt. 

Upgrade auf OpenShift Service Mesh 3.2

Wenn Sie OpenShift Service Mesh 2.6 oder frühere Releases ausführen, müssen Sie ein Upgrade auf OpenShift Service Mesh 3.0, 3.1 und anschließend auf 3.2 durchführen. Wir empfehlen Ihnen, zeitnah zu OpenShift Service Mesh 3.0 zu migrieren, da die Version 2.6 am 30. Juni 2026 ihr End of Life (EOL) erreicht (kürzlich vom 12. März 2026 verlängert). Einen ausführlichen Migrationsguide finden Sie in der Dokumentation zu OpenShift Service Mesh 3.0. Darin enthalten ist auch eine Analyse der Unterschiede zwischen OpenShift Service Mesh 2.6 und 3.0. Dieser Blog-Beitrag beschreibt, wie Sie mit der Kiali-Konsole zwischen OpenShift Service Mesh 2.6 und 3.0 migrieren können.

In diesem Lösungs-Pattern finden Sie ein Beispiel für den Einsatz von OpenShift Service Mesh 3 in der Praxis mit vollständig konfigurierten Metriken sowie der Kiali-Konsole.

Ein Service Mesh ohne Sidecar: Der Ambient-Modus von Istio

Mit diesem Release wird die Unterstützung des Ambient-Modus von Istio für OpenShift Service Mesh allgemein verfügbar. Der Ambient-Modus von Istio ist ein wichtiges neues Feature, das Service Mesh-Funktionen für Workloads ermöglicht, ohne dass Sidecar Proxies erforderlich sind.

Bei der traditionellen Data Plane-Architektur von Istio, auch als „Sidecar-Modus“ bekannt, benötigt jeder Anwendungs-Pod einen Sidecar Proxy-Container, um die Service Mesh-Funktionen zu aktivieren. Dies vereinfacht die Architektur, sorgt jedoch auch für zusätzlichen Aufwand beim Ausführen eines Service Mesh, da für jeden Workload-Container einer Anwendung jeweils ein eigener Proxy-Container erforderlich ist. Auch die Einführung von Service Mesh wird dadurch erschwert, da Sidecar Proxies sowohl als Teil des Anwendungs-Lifecycles als auch als Teil des Service Mesh-Lifecycles hinzugefügt und aktualisiert werden müssen. Das heißt, dass Anwendungen nach dem Einführen sowie nach dem Aktualisieren des Service Mesh jeweils neu gestartet werden müssen.

Mit der Ambient-Modus-Architektur von Istio wird die Data Plane in 2 Proxy-Ebenen aufgeteilt, die unterschiedliche Rollen erfüllen: Ztunnel und Waypoint. 

Ztunnel Proxy

Ztunnel (mit „Z“ für „Zero Trust“) ist ein schlanker Proxy auf Knotenebene, der den Datenverkehr auf Layer 4 abfängt. Er bietet Sicherheit in Form von mTLS-Verschlüsselung (Mutual Transport Layer Security), Authentifizierung, Telemetrie und einfachen L4-Autorisierungsrichtlinien, die auf Anwendungsidentitäten basieren. Darüber hinaus stellt er grundlegende L4-Protokolle und -Metriken (z. B. TCP) bereit, die wie alle Service Mesh-Metriken über die Kiali-Konsole angezeigt werden können.

Da Ztunnel für diesen speziellen Zweck in Rust geschrieben ist, kann eine hohe Proxy-Performance mit minimalem zusätzlichen Aufwand erreicht werden. 

Ztunnel wird zwar als Kubernetes-DaemonSet, also als Proxy auf Knotenebene, ausgeführt, der Datenverkehr wird jedoch im Netzwerk-Namespace der einzelnen Pods umgeleitet. Da die Umleitung und Verschlüsselung des Datenverkehrs innerhalb des Pods erfolgt, wird die Isolation und Verschlüsselung des Datenverkehr zwischen Pods aufrechterhalten. In der Istio-Dokumentation zur Ztunnel-Datenverkehrsumleitung wird dieser Punkt ausführlicher beschrieben und genauer erklärt, wie der Istio CNI-Agent die Datenverkehrsumleitung konfiguriert.

Wenn Sie beim Arbeiten mit dem Ambient-Modus von Istio nur die von Ztunnel bereitgestellten Features benötigen, ist dies der einzige Proxy, den Sie ausführen müssen. Dadurch erhalten Sie ein sehr ressourceneffizientes Service Mesh.

Waypoint Proxy

Wenn Nutzende Service Mesh-Funktionen auf Anwendungsebene (Layer 7) wie HTTP- oder gRPC-bezogene Telemetrie, Datenverkehrsverwaltung und Autorisierungsrichtlinien wünschen, so können sie zusätzliche Proxies einführen, sogenannte „Waypoints“. Diese werden in der Regel pro Namespace mit einer Gruppe eng verwandter Anwendungs-Workloads bereitgestellt. 

Zusätzlich zu den bereits von Ztunnel bereitgestellten Funktionen fügt ein Waypoint Proxy unter anderem folgende Features hinzu:

• HTTP-Routing und Load Balancing, Wiederholungen, Timeouts, Circuit Breaking, Rate Limiting und Fault Injection
• Umfangreiche Autorisierungsrichtlinien basierend auf L7-Primitiven, wie etwa Anforderungstyp oder HTTP-Header
• HTTP-Metriken, Zugriffsprotokollierung und Tracing

Waypoint Proxies werden ähnlich wie Ingress-Gateways als Standalone Envoy-Proxies gemanagt. Daher werden sie wahrscheinlich zusammen mit Ihren Anwendungs-Workloads gehandhabt, anstatt mit der Control Plane des Service Mesh oder dem knotenbasierten Ztunnel.

Ist der Ambient-Modus von Istio die passende Option für Sie? Welche Vorteile und Nachteile bestehen? 

Der Ambient-Modus von Istio befindet sich in der Istio-Community noch in der Entwicklung und ist derzeit ideal für neue Service Mesh-Installationen, da es bei der Migration oder Kombination mit dem Sidecar-Modus einige Einschränkungen gibt (mehr zu diesem Thema unten).  

Für die unterstützten Custom Resource Definitions (CRDs) der Kubernetes-Gateway-API sollte OpenShift 4.19 oder höher verwendet werden. Die CRDs werden für die Konfiguration von Ingress-Gateways empfohlen und sind für die Konfiguration der Waypoint Proxies von Ambient erforderlich. OpenShift Service Mesh 4.18 und frühere Releases enthalten oder unterstützen diese CRDs nicht.

Die Einführung des Ambient-Modus bietet folgende Vor- und Nachteile:

Deutliche Reduzierung der Ressourcenkosten

Da Sidecars nicht mehr erforderlich sind, reduziert der Ambient-Modus von Istio den Ressourcenbedarf erheblich, sowohl in Bezug auf den Speicher als auch auf die CPUs, die für die Einführung von Service Mesh-Funktionen wie der mTLS-Verschlüsselung erforderlich sind. Wir haben im Vergleich zum Sidecar-Modus eine Reduzierung der Speicherauslastung von mehr als 90 % und eine Reduzierung der CPUs von mehr als 50 % festgestellt. Mit Ztunnel kann die Ressourcennutzung noch weiter reduziert werden. 

Schlanke Zero Trust-Netzwerke

Unserer Meinung nach besteht der Hauptvorteil des Ambient-Modus von Istio in der schlanken mTLS-Verschlüsselung zwischen Pods. Zero Trust-Netzwerke werden zunehmend zu einer Priorität. Immer mehr Kunden wollen daher mit Service Mesh arbeiten, um die mTLS-Verschlüsselung in einer Vielzahl von Anwendungen durchzusetzen. Der Ambient-Modus von Istio mit Ztunnel bietet nicht nur mTLS-Verschlüsselung, sondern ermöglicht auch die Verwaltung von Identitäten sowie Zertifikaten und minimiert gleichzeitig den Ressourcenaufwand und die Auswirkungen auf laufende Workloads. Um steigenden Anforderungen gerecht zu werden, können zusätzliche Waypoints zum Einführen von Richtlinien und Telemetrie auf Anwendungsebene hinzugefügt werden, etwa solche, die auf HTTP-Anforderungstypen (z. B. /GET) oder Headern basieren. 

Verbesserte Skalierbarkeit 

Mit weniger zu verwaltenden Proxies und einem deutlich geringeren Footprint lässt sich mit dem Ambient-Modus von Istio deutlich besser skalieren als mit dem traditionellen Sidecar-Modus. Einige Kunden haben mit den Subskriptions- und Skalierungsfunktionen von Istio Meshes für Tausende von Workloads skaliert. Die Architektur des Ambient-Modus bietet jedoch das Potenzial zur Skalierung auf Zehntausende oder sogar Hunderttausende von Workloads mit weniger Optimierungen. 

Mögliche Performance-Merkmale

Es gab bereits vielversprechende erste Performance-Messungen in der Istio-Community. Welche Performance der Ambient-Modus von Istio in einer unternehmensgerechten Umgebung bietet, die mit der unserer Kunden vergleichbar ist, wird hingegen noch weiter untersucht. Nach aktuellen Bewertungen ist die Performance mit der des Sidecar-Modus vergleichbar, und es besteht noch Verbesserungspotenzial für zukünftige Releases. Die Performance-Merkmale von Ztunnel allein unterscheiden sich von denen der Nutzung von Ztunnel mit einem Waypoint, da ein Waypoint je nach Konfiguration zusätzlichen Aufwand verursacht. Wir sind auch auf einen bekannten Performance-Engpass gestoßen, der die vertikale Skalierbarkeit von Ztunnel einschränkte. Es wird einige Zeit dauern, bis dies behoben ist. Wir sind überzeugt, dass die Ambient-Architektur von Istio Potenzial für Performance-Verbesserungen in zukünftigen Releases bietet.

Vereinfachte Einführung

Der Ambient-Modus von Istio erleichtert außerdem die Integration von Service Mesh, da Workloads nicht mehr geändert werden müssen, um Sidecar Container hinzuzufügen. Tatsächlich müssen sie nicht einmal neu gestartet werden, um zum Mesh hinzugefügt zu werden, oder wenn das Mesh aktualisiert wird. Die Architektur mit 2 Ebenen ermöglicht außerdem ein schrittweises Einführen von Istio-Funktionen, ohne dass Ressourcenkosten für einen Layer 7-Proxy anfallen, wenn dieser nicht benötigt wird. 

Support-Levels für Features

Das Support-Level für Istio-Features im Ambient-Modus kann sich vom traditionellen Sidecar-Modus unterscheiden. Die Liste der unterstützten Features finden Sie in der Tabelle zum Support von Service Mesh-Features. Erweiterte Features wie Multi-Cluster und Multi-Mesh befinden sich noch in der Entwicklung. Das Kombinieren von Workloads mit Sidecar- und Ambient-Modus ist nur eingeschränkt möglich, insbesondere beim Verwenden von Waypoint Proxies mit Sidecars. Eine vergleichende Bewertung von Ambient und Sidecar von der Istio-Community finden Sie auf dieser Seite. 

Überlegungen zu Upgrades

Der Ambient-Modus von Istio bietet den Vorteil, dass die Data Plane von Istio aktualisiert werden kann, ohne die Workload-Pods neu zu starten, was bei Sidecar Proxies erforderlich ist. Der Nachteil dabei besteht darin, dass Ztunnel gemeinsam genutzte Agenten auf Knotenebene sind, die Teil des Datenpfads mehrerer Anwendungen sind. Beim Upgraden von Ztunnel ist daher Vorsicht geboten. Wir empfehlen, das Upgrade während eines Wartungsfensters oder in einem Zeitraum mit geringerem Datenverkehr durchzuführen. Dadurch werden langlebige TCP-Verbindungen auf diesem Knoten zurückgesetzt. Revisionsbasierte Canary-Upgrades werden bei diesem Release noch nicht unterstützt. Dieser Bereich wird in zukünftigen Releases weiterentwickelt.

Erste Schritte mit dem Ambient-Modus von Istio

Für den Einstieg in den Ambient-Modus von Istio bietet OpenShift Service Mesh die Ressource „Ztunnel“, mit der Ztunnel als DaemonSet installiert und gemanagt werden kann. Diese Ressource wird zusammen mit den Ressourcen „Istio“ und „IstioCNI“ installiert, die mit dem Profil „ambient“ konfiguriert werden müssen, auch wenn manche Workloads über Sidecars verfügen. 

Wie beim traditionellen Sidecar-Modus müssen die „Discovery-Selektoren“ von Istio konfiguriert werden, damit die Control Plane von Istio nur die Namespaces überwacht, die Teil des Mesh sein sollen. Für den Ambient-Modus wird das Label „istio.io/dataplane-mode=ambient“ verwendet, um anzugeben, dass ein Namespace oder eine Workload in das Mesh aufgenommen werden soll. Weitere Informationen zum Hinzufügen von Workloads finden Sie in der Dokumentation der Istio-Community.

Wird dem Mesh eine neue Workload hinzugefügt, konfiguriert der Istio CNI-Agent zusammen mit dem lokalen Ztunnel Proxy des Knotens die Datenverkehrsumleitung so, dass der gesamte Datenverkehr abgefangen wird und mit dem HBONE-Tunneling-Protokoll (HTTP-Based Overlay Network Environment) von Istio auf die Verwendung von mTLS upgegradet wird. Ztunnel übernimmt auch das Abrufen und Managen von Zertifikaten für sämtliche Pods auf demselben Knoten.

Wenn ein Waypoint Proxy erforderlich ist, kann er auf ähnliche Weise hinzugefügt werden wie ein Ingress- oder Egress-Gateway mit der Kubernetes-Ressource „Gateway“ aus der Kubernetes-Gateway-API, die in OpenShift 4.19 und höher enthalten ist. Weitere Informationen zur Installation von Waypoints finden Sie hier. Details zur Verwendung von Waypoints für L7-Features können Sie hier nachlesen.

In der Dokumentation zu OpenShift Service Mesh werden die ersten Schritte mit dem Ambient-Modus von Istio detailliert erklärt.

Kann ich zum Ambient-Modus migrieren, wenn ich Service Mesh bereits verwende?

Der Ambient-Modus ist ideal für neue Nutzende von Service Mesh, kann aber auch in bestehende Service Mesh-Deployments eingeführt und mit Workloads im Sidecar-Modus kombiniert werden – mit einigen Einschränkungen. Wir gehen davon aus, dass der Sidecar-Modus der bevorzugte Use Case bleibt, wenn sämtliche Features eines dedizierten Envoy Proxies pro Pod benötigt werden. 

Um den Ambient-Modus in einem vorhandenen Mesh einzuführen, muss das Mesh (Istio und Istio CNI) mit dem „ambient“-Profil aktualisiert und die Workloads mit Sidecars neu gestartet werden, damit sie über das HBONE-Tunneling-Protokoll mit Ztunneln kommunizieren können. 

Diese Koexistenz wird aktuell dadurch eingeschränkt, dass der Datenverkehr zwischen Sidecar Proxies und Ambient-Workloads normalerweise an Waypoint Proxies vorbeigeht, sodass Layer-7-Richtlinien nicht auf die Ambient-Workloads angewendet werden.

Wir empfehlen daher, für Namespaces und Anwendungsgruppen entweder den Ambient-Modus oder den Sidecar-Modus zu verwenden und die Modi nicht innerhalb eng gekoppelter Anwendungs-Workloads zu kombinieren. Es ist auch wichtig, die Pod-Labels für Sidecar- und Ambient-Modus nicht zu verwechseln.

Kiali mit dem Ambient-Modus von Istio

Kiali, die in OpenShift Service Mesh enthaltene Konsole für Istio, bietet viele Funktionen zur Konfiguration, Visualisierung und Validierung des Ambient-Modus von Istio. Workloads können sich in mehreren möglichen Zuständen befinden: im Mesh mit Ztunnel, im Mesh mit Waypoints, im Sidecar-Modus oder außerhalb des Mesh. Dadurch wird Kiali noch wichtiger, wenn es darum geht, den Zustand Ihres Mesh zu verstehen und Fehler bei verteilten Anwendungen zu beheben, die sich nicht wie erwartet verhalten.

Kiali bietet auf jeder Ebene eindeutige Bestätigungen dafür, dass der Ambient-Modus erfolgreich konfiguriert wurde. Dies beginnt damit, dass die Control Plane von Istio mit aktiviertem Ambient-Profil ausgeführt wird und dass Namespaces und Workloads mit Labels gekennzeichnet wurden, damit der Workload-Datenverkehr wie erwartet von Ztunnel und/oder Waypoint erfasst wird. Außerdem können Sie auf Pod-Ebene prüfen, ob der Datenverkehr mithilfe des HBONE-Protokolls von Istio und nicht mit unverschlüsseltem TCP gesichert wird.

Kiali bietet auch korrelierte Protokolle zwischen Ztunnel und Waypoint, die verdeutlichen, wie der Datenverkehr von der Workload durch die einzelnen Proxies fließt. Dies erleichtert auch das Troubleshooting.

Waypoint Proxies ähneln anderen Proxies zwar, aber Kiali zeigt über eine spezielle Registerkarte an, welche Services und Workloads registriert wurden. 

Außerdem sehen die Topologiediagramme für den Ambient-Modus anders aus als für den Sidecar-Modus. Da es jetzt 2 Proxy-Ebenen gibt, können pro Workload 2 unabhängige Telemetriesätze gemeldet werden: L4-Metriken (TCP) mit blauen Linien für Ztunnel und L7-Metriken (HTTP) mit grünen Linien für konfigurierte Waypoints. Kiali bietet die Möglichkeit, den angezeigten Datenverkehrstyp auszuwählen.

Da Waypoint Proxies wahrscheinlich Gruppen von eng gekoppelten Workloads darstellen (und diese möglicherweise eine gemeinsame verteilte Anwendung bilden), bietet die Waypoint-Ansicht einen besseren Überblick über Ihr Mesh – insbesondere, wenn es sich um ein sehr großes Mesh handelt.

Weitere Informationen zu den Features von Kiali für den Ambient-Modus finden Sie in der Dokumentation der Kiali-Community.

Updates von Istio 1.27

Dieses Release enthält sämtliche Updates, die in den Änderungshinweisen für Istio 1.27 genannt werden. Im Folgenden finden Sie eine Zusammenfassung der wichtigsten Punkte.

Gateway API Inference Extensions (GIE)

Dieses Release unterstützt Gateway API Inference Extensions. Um Kunden bei Red Hat OpenShift AI 3 besser zu unterstützen, haben wir die allgemein verfügbare Implementierung (Version 1.0) der API in dieses Release zurückportiert. Dieses Feature wird jedoch nur mit Red Hat OpenShift AI 3 unterstützt und gehört zur Technologievorschau für OpenShift Service Mesh 3.2. 

Multi-Cluster mit Ambient-Modus

Dieses Release bietet anfängliche Unterstützung für den Ambient-Modus von Istio in einer multiprimären Multi-Cluster-Topologie. Da sich dieses Feature noch in der Upstream-Entwicklung befindet, haben wir es für OpenShift Service Mesh 3.2 als Entwicklungsvorschau ausgewiesen. 

Native nftables-Unterstützung im Sidecar-Modus

In Vorbereitung auf Red Hat Enterprise Linux (RHEL) 10 hat Red Hat mit Unterstützung für nftables zum Istio-Projekt beigetragen, wobei die Unterstützung für den Sidecar-Modus in Istio 1.27 eingeführt wurde. Das nftable-Framework ist der moderne Nachfolger von iptables, der Linux-Funktion, die von Istio zur Konfiguration von Regeln für die Netzwerkumleitung verwendet wird. Ziel ist eine bessere Performance, Verwaltbarkeit und ein flexibleres Regelmanagement für die Umleitung des Datenverkehrs zum und vom Envoy Sidecar. Ab RHEL 10 ist nftables das Standardtool für die Verwaltung von Netzwerkregeln. Die Unterstützung für RHEL 10 wird in einem zukünftigen Release von OpenShift verfügbar sein.

Allgemeine Verfügbarkeit des Zertifikatmanagers Istio-CSR

Der Operator cert-manager wird für die Verwendung mit OpenShift Service Mesh unterstützt. Damit cert-manager Zertifikate für Workloads signieren, bereitstellen und erneuern kann, ist jedoch der Agent istio-csr erforderlich. Mit dem Release des Operators cert-manager 1.18 ist dieser Agent nun allgemein verfügbar und kann mit allen unterstützten Versionen von OpenShift Service Mesh verwendet werden. In diesem Blog-Beitrag erfahren Sie, wie cert-manager und OpenShift Service Mesh zusammen Zero Trust ermöglichen. Eine Anleitung zur Verwendung von cert-manager mit OpenShift Service Mesh finden Sie in der Dokumentation.

Erste Schritte mit OpenShift Service Mesh

Weitere Informationen zu Red Hat OpenShift Service Mesh lesen Sie in diesem Blog-Beitrag und im Folgebeitrag zu Service Mesh mit Multi-Clustern. 

Für den Einstieg in Service Mesh müssen Sie zunächst den Red Hat OpenShift Service Mesh 3 Operator installieren. Wenn Sie mit Service Mesh noch nicht vertraut sind, sollten Sie den Ambient-Modus von Istio in Betracht ziehen. Er bietet eine deutlich ressourceneffizientere Service Mesh-Architektur als der traditionelle Sidecar-Modus. Informationen zum Einstieg in den Ambient-Modus von Istio finden Sie in der Dokumentation. 

Ein umfassendes Beispiel für die Verwendung von OpenShift Service Mesh mit Workload-Monitoring für OpenShift, Distributed Tracing und Kiali finden Sie in diesem Lösungs-Pattern.