Einführung von Red Hat OpenShift Service Mesh 3.4

Red Hat OpenShift Service Mesh 3.4 ist allgemein mit Red Hat OpenShift und Red Hat OpenShift Platform Plus verfügbar. Basierend auf den Projekten Istio, Envoy und Kiali aktualisiert dieses Release die Version von Istio auf 1.30 und Kiali auf 2.27. Dieses Release enthält mehrere Updates für den Ambient-Modus (ohne Sidecar) von Istio und weitere Funktionen. Kiali führt eine neue Übersichtsseite ein, um Service Meshes in großem Umfang besser zu verwalten. Gleichzeitig stellt Kiali KI-gestützte Funktionen mit Red Hat OpenShift Lightspeed in der Technology Preview bereit, damit Sie Probleme schneller diagnostizieren und beheben können. In diesem Blog-Beitrag erhalten Sie auch eine Vorschau auf kommende Neuerungen in diesem Jahr.

Beachten Sie, dass OpenShift Service Mesh 2.6 am 30. Juni 2026 sein End of Life erreicht hat. Wenn Sie weiterhin 2.6 ohne eine genehmigte Support-Erweiterung ausführen, erfahren Sie in den Hinweisen am Ende dieses Beitrags, wie Sie vorgehen.

Die neue Multi-Cluster-Übersichtsseite von Kiali

OpenShift Service Mesh auf dem Red Hat Summit

Red Hat Summit 2026 fand im Mai in Atlanta, Georgia, statt. Falls Sie es verpasst haben: OpenShift Service Mesh war ein Schwerpunkt in der Red Hat OpenShift Product Spotlight Session. Darunter waren 2 Kunden, die über ihre Erfahrungen mit Service Mesh sprachen. Zudem gab es eine Demo von Service Mesh mit OpenShift Virtualization sowie eine zukunftsorientierte Demo zur agentischen KI-Fehlerbehebung.

Basierend auf Istio 1.30 und Kiali 2.27

Dieses Release überspringt zwei Nebenversionen von Istio gegenüber OpenShift Service Mesh 3.3 und enthält Änderungen aus Istio 1.29 und 1.30. Diese beiden Releases beinhalten wichtige Updates für den Ambient-Modus von Istio, insbesondere für Multi Cluster. Kiali wechselt zur Version 2.27, die wichtige Updates auf den Übersichts- und Detailseiten enthält. Wir stellen hier einige wichtige Änderungen vor. Die vollständige Liste der Updates finden Sie in den Änderungshinweisen für Istio 1.29 und 1.30 sowie in den Kiali Release Notes. Einzelheiten zum Produktsupport finden Sie in den Tabellen zum Support von OpenShift Service Mesh 3.4-Features.

Updates für Ambient-Modus

Diese Version enthält mehrere Updates für den Ambient-Modus (ohne Sidecar) von Istio. Dieser entwickelt sich in Richtung Funktionsparität mit dem traditionellen Sidecar-Modus von Istio weiter.

Anleitung für Koexistenz und Migration aus dem Sidecar-Modus

Diese Version bietet offizielle Unterstützung und Anleitungen für die Koexistenz von Workloads im Ambient- und Sidecar-Modus innerhalb desselben Service Mesh. Zudem enthält sie Anleitungen für die Migration von Workloads vom Sidecar-Modus in den Ambient-Modus. Beide Verfahren weisen auf mehrere Einschränkungen hin, die derzeit für die Koexistenz und Migration von Workloads zwischen Ambient- und Sidecar-Modus bestehen. Die Migration ist schrittweise und reversibel geplant, wobei Ambient- und Sidecar-Workloads über einen längeren Zeitraum gleichzeitig existieren.

Multi Cluster im Ambient-Modus entwickeln sich weiter (Technology Preview)

Diese Version enthält viele Updates für das Feature-Set des Multi-Primary-Multinetwork (Multi Cluster)-Betriebs im Istio-Ambient-Modus. Dies umfasst eine aktualisierte Dokumentation in OpenShift Service Mesh für die Installation eines Multi-Primary-Multinetwork-Mesh im Ambient-Modus.

Zur Erinnerung: Multi Cluster-Topologien von Istio erweitern den Umfang eines einzelnen Mesh über mehrere Cluster hinweg. Sie bieten einen zentralen Punkt für die Überwachung des Datenverkehrs und die Verwaltung von Richtlinien über mehrere Cluster, Verfügbarkeitszonen und Regionen hinweg. Sie sind besonders nützlich für das Erstellen hochverfügbarer Anwendungen. Das ortsbasierte Load Balancing von Istio ermöglicht dabei die Weiterleitung des Datenverkehrs auf Basis physischer oder geografischer Standorte. Für den Sidecar-Modus handelt es sich um ein allgemein verfügbares Feature in OpenShift Service Mesh.

Dieses Release enthält wichtige Verbesserungen und Fehlerbehebungen, die Multi Cluster im Ambient-Modus der Produktionsbereitschaft näherbringen. Dieses Release behebt zudem einen Fehler, bei dem Ingress-Gateways Anfragen nicht an exponierte Remote-Backends weiterleiteten. Dieser Fix befindet sich hinter dem Feature-Flag AMBIENT_ENABLE_MULTI_NETWORK_INGRESS, das standardmäßig auf „false“ festgelegt ist.

Wir haben die Telemetrie-Implementierung verbessert. Dies schließt Lücken beim Austausch von Peer-Metadaten und Telemetrie über Netzwerkgrenzen hinweg, an denen Waypoints zum Einsatz kommen. Diese Funktionen erfordern möglicherweise die Aktivierung des Feature-Flags AMBIENT_ENABLE_BAGGAGE. Das Istio-Projekt bietet jetzt auch einen ausführlichen Guide zur Konfiguration des Multinetwork-Ambient-Modus mit Kiali.

Die Unterstützung für Multi-Primary-Multinetwork (Multi Cluster) im Ambient-Modus von Istio ist ein Technology Preview-Feature in OpenShift Service Mesh 3.4. Obwohl wir es noch nicht für den Produktionseinsatz empfehlen, ermutigen wir Nutzende von OpenShift Service Mesh, mit der Entwicklung und Experimenten zu beginnen und Feedback zu geben.

Unterstützung für Zertifikatsperrlisten (Certificate Revocation List, CRL) in ztunnel

Diese Version fügt ztunnel Unterstützung für Zertifikatsperrlisten (Certificate Revocation List, CRL) hinzu. Damit kann der Ambient-Modus widerrufene Zertifikate bei Verwendung externer Zertifizierungsstellen validieren und ablehnen. Ähnlich wie im Sidecar-Modus können Sie dies mit einer ca-crl.pem-Datei konfigurieren, die zusammen mit Ihren eingebundenen CA-Dateien in ClientTLSSettings bereitgestellt wird. Die Istio Control Plane (Istiod) verteilt diese CRLs automatisch an alle teilnehmenden Namespaces im Cluster.

Native nftables-Unterstützung für RHEL 10 und höher

Diese Version bietet native nftables-Unterstützung für den Sidecar- und den Ambient-Modus. Diese Funktion wurde von Red Hat beigesteuert, um Istio für zukünftige Versionen von Red Hat Enterprise Linux (RHEL) und OpenShift vorzubereiten. Nftables bieten eine alternative Methode zur Verwaltung von Netzwerkregeln gegenüber herkömmlichen iptables. Diese ist bei Verwendung von Service Mesh mit RHEL 10 und höher erforderlich.

Netzwerkrichtlinien für Kernkomponenten von Istio

Um die Sicherheit der Kernkomponenten von Istio (istiod, istio-cni und ztunnel) zu verbessern, hat Red Hat einen optionalen Satz von Netzwerkrichtlinien eingeführt. Diese beschränken die Komponenten auf die jeweils erforderlichen Ingress-Ports. Sie können diese Richtlinien aktivieren, indem Sie global.networkPolicy.enabled=true in der Wertekonfiguration Ihrer Istio-Ressource festlegen. 

In OpenShift Service Mesh 3.4 sind diese standardmäßig deaktiviert. In einer zukünftigen Nebenversion von OpenShift Service Mesh werden sie jedoch standardmäßig aktiviert.

Verbesserte Kubernetes Gateway API

Der Support für die Kubernetes Gateway API in Istio entwickelt sich ständig weiter. Diese Version von Service Mesh enthält wichtige Updates mit Unterstützung für die Kubernetes Gateway API 1.5. Beachten Sie, dass die Gateway-API-Unterstützung auf OpenShift die Installation von Custom Resource Definitions (CRDs) erfordert. Die derzeit unterstützte Version dieser CRDs hängt von der OpenShift-Plattformversion ab.

Diese Version bietet vollständige Unterstützung für TLSRoute-Terminierung und gemischten Modus sowie TLS-Passthrough für East-West-Gateways. Dies ist ein wichtiges Feature zur Unterstützung von verschlüsseltem Cluster-übergreifendem Datenverkehr im Ambient-Modus von Istio. 

Die Gateway-Ressource enthält jetzt die Option zum Angeben benutzerdefinierter Cipher-Suites mit der Annotation gateway.istio.io/tls-cipher-suites. Wir haben das Statusreporting der Gateway-Ressource verbessert. Es enthält die Anzahl der angehängten ListenerSets, während das ListenerSet-Statusreporting nun die Anzahl der angehängten Routes anzeigt.

Wenn Sie die Kubernetes Gateway API nur zur Konfiguration Ihres Service Mesh (GAMMA) oder Istio nur als Ingress-Controller verwenden, benötigen Sie möglicherweise nicht alle standardmäßigen Ressourcen und Funktionen. Mit der neuen Umgebungsvariable PILOT_IGNORE_RESOURCES können Sie Istio optimieren, indem Sie Ressourcen ignorieren, die nicht für Ihre Use Cases benötigt werden. Dies kann den Footprint von Istio reduzieren sowie Speicherplatz und Zeit für den Konfigurationsabgleich sparen.

Unterstützung für Kubernetes User Namespaces

Dieses Release unterstützt die Sidecar-Injektion zu Pods, die Kubernetes User Namespaces (hostUsers: false) nutzen, wenn sie mit Istio CNI ausgeführt werden.

Kubernetes User Namespaces verbessern die Cluster-Sicherheit, indem sie den Root-Benutzer in einem Container vom Root-Benutzer auf dem Host-Knoten isolieren. Dies stellt sicher, dass ein containerisierter Prozess keine Berechtigungen besitzt, selbst wenn er auf den Host gelangt.

Um dieses Feature zu nutzen, müssen Sie die Standardbereiche für User ID (UID) und Group ID (GID) im Ziel-Namespace-Objekt explizit konfigurieren. Verwenden Sie dazu die Annotationen openshift.io/sa.scc.uid-range und openshift.io/sa.scc.supplemental-groups. Die Länge dieser zugewiesenen ID-Bereiche muss auf 65.535 oder weniger festgelegt werden, da eine Überschreitung dieser Kapazitätsgrenze zum Fehlschlagen der Pod-Erstellung führt.

Unterstützung für Zero Trust Workload Identity Manager (Technology Preview)

Mit dieser Version wird die Unterstützung von OpenShift Service Mesh für den Zero Trust Workload Identity Manager von Red Hat (basierend auf SPIRE) auf Technology Preview aktualisiert. OpenShift Service Mesh umfasst eine sofort einsatzbereite Workload-Identität und -Erstellung mit dem SPIFFE-Protokoll. Der Zero Trust Workload Identity Manager ist mit Red Hat OpenShift Platform Plus verfügbar und bietet eine stärkere, mehrstufige Workload-Identitätszertifizierung. Dies gibt zusätzliche Sicherheit, dass eine Workload tatsächlich mit ihrer angegebenen Identität übereinstimmt.

Zero Trust Workload Identity Manager enthält außerdem eine leistungsstarke Funktion namens Federation. Damit können sich Workloads unterschiedlicher Vertrauensdomänen gegenseitig authentifizieren und geschützt kommunizieren. In Kombination mit Service Mesh wird die Sicherheit für das Teilen von Vertrauen vereinfacht und erhöht – unabhängig davon, ob sich diese Workloads in verschiedenen Service Meshes, Clustern oder Standalone-Umgebungen wie virtuellen Maschinen (VMs) befinden.

Wir haben diese Integration in einer Reihe von Blog-Beiträgen detailliert beschrieben. Dies umfasst auch die Erweiterung der Anwendung auf eine externe virtuelle Maschine.

Neue TrafficExtension API (Technology Preview)

Diese Version führt zudem eine neue API zur Erweiterung von Istio ein, die API TrafficExtension. Istio bietet zwar sehr viele Features, wir stellen jedoch fest, dass viele Kunden spezielle Use Cases haben. Diese erfordern eine Erweiterung der Funktionen von Istio – entweder über die EnvoyFilter-API (eine Low-Level-API mit erheblichem Ausfallrisiko bei Updates) oder WebAssembly-Plugins (gut für komplexe Use Cases, aber oft aufwendig zu entwickeln und zu verteilen). 

Die TrafficExtension-API soll eine einzelne, einheitliche und verbesserte API zur Erweiterung der Funktionalität von Istio bereitstellen. Sie enthält die Funktionen der WasmPlugin-API (die sie ersetzen soll), bietet aber auch Support für Lua-Skripte, die direkt in die Ressource eingebettet sind, ohne dass eine Modul-Distribution erforderlich ist. Dies stellt eine schlankere Methode zur Erweiterung von Istio dar, die zudem sicherer als ein EnvoyFilter sein soll. Wie andere Istio-Ressourcen können Sie TrafficExtensions mit Kiali konfigurieren und verwalten. Weitere Informationen finden Sie unter Extending Envoy proxies.

Neue Kiali-Übersichts- und -Detailseiten mit verbessertem Multi Cluster-Support

Die Kiali Console und das dazugehörige Plugin für OpenShift Service Mesh Console bieten einen zentralen Ort zur Überwachung, Verwaltung und zum Schutz von Istio und den Services Ihres Service Mesh.

Diese Version umfasst eine komplett neu gestaltete Übersichtsseite in Kiali (siehe Screenshot oben). Dies verbessert die Lesbarkeit und Leistung für große Multi Cluster Service Mesh Deployments, die mehrere hundert Namespaces haben können. Die neue Architektur reduziert die Speichernutzung und Ladezeit. Das aktualisierte Layout ist Multi Cluster-fähig und hebt den globalen Status mit Anwendungs-Insights auf einen Blick hervor. Wir haben ähnliche Aktualisierungen auf der Plugin-Übersichtsseite von OpenShift Service Mesh Console vorgenommen.

Eine aktualisierte Namespace-Seite bietet bessere Unterstützung für große Multi Cluster-Meshes mit erweiterten Filtern, Sortierungen und dem mTLS-Status für jeden Namespace. 

Aktualisierte Multi Cluster-Namespace-Seite von Kiali

Die Überprüfung eines bestimmten Namespace bietet eine aktualisierte Zusammenfassung und Diagrammansicht dieses Namespace. Wenn Sie eine bestimmte Workload aufschlüsseln, erhalten Sie eine ähnliche Zusammenfassungsansicht mit einem Diagramm der Abhängigkeiten für diese Workload.

Die aktualisierte Namespace-Detailseite von Kiali

Die aktualisierte Workload-Detailseite von Kiali

KI-gestützte Unterstützung im Service Mesh (Technology Preview)

Die Komplexität von Istio und die Fülle an Informationen, auf die Kiali Zugriff hat (Metriken, Protokolle und Traces), machen das System zu einem idealen Einsatzort für KI-Unterstützung. In der Kiali Console können Sie den Kiali-eigenen Chatbot einrichten. Diese Version umfasst Token Usage Analytics, damit Sie die Kosten besser überwachen und kontrollieren können. Wir haben den System-Prompt zudem gegen Injection-Angriffe gehärtet. Dies verhindert, dass böswillige Eingaben sensible Mesh-Konfigurationen oder Zugangsdaten offenlegen.

Für noch mehr Leistung und Integration können Sie Model Connect Protocol (MCP) in Kombination mit OpenShift Lightspeed verwenden, um das Service Mesh und die restliche OpenShift-Plattform zu unterstützen. Der OpenShift Model Connect Protocol (MCP) Server ist seit Kurzem als Technology Preview verfügbar und enthält Tools speziell für Kiali und OpenShift Service Mesh. 

Sie können diese in Kombination mit der Kiali Console oder dem OpenShift Service Mesh Console Plugin verwenden. So überwachen Sie Ihr Mesh, während Sie über Lightspeed oder Ihre bevorzugte agentische Umgebung mit MCP interagieren.

OpenShift Lightspeed mit dem Plugin OpenShift Service Mesh Console

Wir haben bereits gesehen, dass diese Kombination dazu beiträgt, Hürden für gängige Service Mesh Use Cases abzubauen. Dazu gehören das Aufteilen von Datenverkehr (oben angezeigt und hier demonstriert), Telemetrieanalyse, die Erkennung von Konfigurationsfehlern bis hin zu komplexen Fehlerbehebungsszenarien (Demo hier) und andere Aufgaben, die zuvor möglicherweise fundiertes Fachwissen zu Istio (oder viel Zeit beim Durchsuchen der Dokumentation) erforderten.

Verbesserte Mandantenfähigkeit für Namespaces in Kiali

Kiali hat eine neue Konfigurationsoption hinzugefügt, KialiFeatureFlags.Authz.RequireNamespaceGet. Damit können Administratoren die Sichtbarkeit von Namespaces auf jene beschränken, für die Nutzende explizite „get“-Berechtigungen (nicht nur „list“) haben. Dies ist nützlich in Single-Mesh-Umgebungen mit mehreren Mandanten, in denen Nutzende nur ihre eigenen Namespaces und nicht das vollständige Cluster-Inventar sehen sollten.

Wie geht es weiter?

Diese Version enthält eine Reihe von Updates für Istio und Kiali. Wir können uns jedoch auf weitere wichtige Features im Laufe des Jahres freuen. Wir arbeiten daran, die Multi-Primary-Multinetwork-Topologie (Multi Cluster) des Ambient-Modus zur allgemeinen Verfügbarkeit zu bringen. Wir planen, unseren VM-Support auf Workloads in separaten Netzwerken auszuweiten. Dies umfasst auch Workloads, die nicht Teil eines OpenShift Clusters sind. Die Unterstützung für die Integration von RHEL VMs ist ein Developer Preview Feature. Wir prüfen auch Erweiterungen für Red Hat Advanced Cluster Management for Kubernetes, um die Konfiguration und Verwaltung von Service Mesh über eine Flotte von Clustern hinweg zu verbessern.

End of Life von OpenShift Service Mesh 2.6

OpenShift Service Mesh 2.6 hat am 30. Juni 2026 sein End of Life erreicht. Wir unterstützen Kunden weiterhin bei der Migration zu einer unterstützten Version von OpenShift Service Mesh 3. Wir stellen jedoch keine Bugfixes und Sicherheitskorrekturen für OpenShift Service Mesh 2.6 mehr bereit.

Wenn Sie noch OpenShift Service Mesh 2.6 nutzen, wenden Sie sich bitte an Ihren persönlichen Ansprechpartner bei Red Hat. So können Sie eine Supporterweiterung und einen Migrationszeitplan besprechen. Detaillierte Informationen zu den Unterschieden zwischen OpenShift Service Mesh 2.6 und 3.0 finden Sie hier. Ein ausführlicher Migrations-Guide beschreibt zudem ein Verfahren ohne Ausfallzeiten für verschiedene Produktions-Setups. Gerne besprechen wir mit Ihnen individuelle Situationen oder Herausforderungen.

Einstieg oder Upgrade auf OpenShift Service Mesh 3.4

Wenn Sie noch keine Erfahrungen mit Service Mesh haben, finden Sie im Installations-Guide Anweisungen zur Installation von Istio mit dem OpenShift Service Mesh 3-Operator. Der Operator verarbeitet Installationen und Upgrades von Istio. Dies umfasst mehrere Service Meshes auf einem einzelnen Cluster (nur Sidecar-Modus) oder auf mehreren Clustern innerhalb eines Service Mesh.

Wenn Sie ein Upgrade von OpenShift Service Mesh 3.3 durchführen, finden Sie in den Versionshinweisen eine Liste wichtiger Änderungen. Beachten Sie diese vor dem Upgrade. Die detaillierte Vorgehensweise für das Upgrade finden Sie in der aktuellen Dokumentation von OpenShift Service Mesh.

Erfahren Sie mehr über Red Hat OpenShift Service Mesh.