Einführung in OpenShift Service Mesh 3.1

Red Hat OpenShift Service Mesh 3.1 ist jetzt verfügbar und in Red Hat OpenShift Container Platform und Red Hat OpenShift Platform Plus enthalten. Basierend auf den Projekten Istio, Envoy und Kiali aktualisiert dieses Release die Version von Istio auf 1.26 und Kiali zu 2.11 und wird auf OpenShift Container Platform 4.16 und höher unterstützt.

Dies ist die erste Nebenversion nach Red Hat OpenShift Service Mesh 3.0. Die Hauptversion führt OpenShift Service Mesh mit dem Community-Projekt Istio zusammen und der Sail Operator übernimmt dabei die Installation und Verwaltung. Diese Änderung trägt dazu bei, dass OpenShift Service Mesh die aktuellen stabilen Istio-Funktionen mit Support durch Red Hat anbieten kann.

Upgrade auf OpenShift Service Mesh 3.1

Wenn Sie OpenShift Service Mesh 2.6 oder frühere Versionen verwenden, müssen Sie ein Upgrade auf OpenShift Service Mesh 3.0 durchführen, bevor Sie ein Upgrade auf 3.1 durchführen können. Wir empfehlen eine umgehende Migration zu OpenShift Service Mesh 3.0, da die Version 2.6 am 12. März 2026 ihr End of Life erreicht. Eine ausführliche Migrationsanleitung finden Sie in der Dokumentation zu OpenShift Service Mesh 3.0, einschließlich einer Analyse zu den Unterschieden zwischen OpenShift Service Mesh 2.6 und 3.0.  

Wir haben außerdem kürzlich einen Artikel veröffentlicht, der die Verwendung der Kiali-Konsole für die Migration zwischen OpenShift Service Mesh 2.6 und 3.0 beschreibt.

Ein Beispiel für OpenShift Service Mesh 3.0 in Aktion, mit vollständig konfigurierten Metriken und der Kiali-Konsole, finden Sie in diesem Lösungs-Pattern.

Kubernetes-Gateway-API-Unterstützung in OCP 4.19+

Kubernetes-Gateway-API ist die nächste Generation von Kubernetes Ingress-, Load Balancer- und Service Mesh-APIs. Istio plant, es zum Standardsatz von APIs für die Erstellung und das Management des Datenverkehrs mit einem Service Mesh zu machen. Es ist zudem für die Nutzung des Umgebungsmodus von Istio erforderlich. Beachten Sie, dass keine Pläne zum Entfernen der stabilen Istio-APIs wie VirtualService, DestinationRule und andere bestehen. Es kann vorkommen, dass Sie diese APIs verwenden müssen, um von Funktionen zu profitieren, die Kubernetes-Gateway-API noch nicht bietet.

Während OpenShift Service Mesh 3.0 Unterstützung für die Kubernetes-Gateway-API bot, mussten die Nutzenden nicht unterstützte Custom Resource Definitions (CRDs) installieren, um diese Funktion verwenden zu können. Dies hat sich ab OpenShift Container Platform 4.19 geändert. Die erforderlichen CRDs sind nun standardmäßig in OpenShift verfügbar. Sie müssen diese CRDs nicht mehr separat installieren. Red Hat unterstützt die in OpenShift enthaltenen Gateway-API CRDs vollständig.

Um eine optimierte Unterstützung für generative KI-Workloads und Datenverkehrsmuster bereitzustellen, haben wir die Unterstützung für die Gateway API Inference Extension als Technologievorschau aufgenommen. Dazu haben wir diese Funktion in OpenShift Service Mesh 3.1 zurückportiert.

Allgemein verfügbare Dual-Stack-Unterstützung für x86-Cluster

Mit diesem Release ist die Unterstützung für Dual-Stack-IPv4- und IPv6-Workloads mit OpenShift Service Mesh für OpenShift-Cluster, die x86-Hardware ausführen, allgemein verfügbar. Zum Aktivieren der Dual-Stack-Unterstützung in OpenShift Service Mesh müssen Sie in Ihrer Istio-Kundenressource das Flag ISTIO_DUAL_STACK auf true setzen. Dies wird in der Upstream-Sail-Operator-Dokumentation für Dual-Stack sowie in der Community Istio Dual-Stack-Dokumentation demonstriert. Die Produktdokumentation zu OpenShift Service Mesh folgt demnächst.

Wechsel zu UBI Micro Containern

Mit diesem Release werden die meisten Container, einschließlich der zentralen istiod- und Proxy-(Envoy)-Container, auf die Verwendung von UBI Micro Base Images umgestellt. UBI Micro ist ein sehr kompaktes Universal Base Image (UBI) von Red Hat Enterprise Linux. Es entsteht durch den Ausschluss eines Paketmanagers und all seiner Abhängigkeiten, die ein Container-Image normalerweise enthält. Die Einführung von UBI Micro trägt dazu bei, die Angriffsfläche von Container-Images zu minimieren, die als Teil von OpenShift Service Mesh bereitgestellt werden.

Auf dem Weg zu einem Service Mesh ohne Sidecar: Der Ambient-Modus von Istio

OpenShift Service Mesh 3.1 basiert auf Istio 1.26 und enthält hauptsächlich inkrementelle Updates im Vergleich zu OpenShift Service Mesh 3.0, das auf Istio 1.24 basierte. Das liegt daran, dass sich die Istio-Community und Red Hat stark auf die nächste Generation der Service Mesh Data Plane konzentrieren: den Ambient-Modus von Istio.

Die Nutzung von Service Mesh hat in den letzten Jahren stetig zugenommen. Allerdings stellt die Notwendigkeit von Sidecar Proxies oft ein Hindernis für die Einführung dar. Dies liegt an den zusätzlichen Ressourcen (primär Arbeitsspeicher und CPU), die für die Ausführung von Sidecar Containern neben den Anwendungs-Containern benötigt werden. Dies erschwert die Einführung von Service Mesh, da Sidecar-Proxies als Teil des Pod-Lifecycle hinzufügt und aktualisiert werden müssen. Dies bedeutet, dass Anwendungen neu gestartet werden müssen, um ein Update des Service Mesh durchzuführen.

Der Ambient-Modus von Istio zielt darauf ab, diese Bedenken zu berücksichtigen, indem die Notwendigkeit von Sidecar-Proxies entfällt und die Istio Data Plane in zwei separate Schichten aufgeteilt wird. Dies ermöglicht die inkrementelle Einführung von Service Mesh-Funktionen mit weniger Komplexität für Anwendungsverantwortliche.

Diese geteilte Architektur führt dazu, dass deutlich weniger Proxies zur Aktivierung des Service Mesh bereitgestellt werden. Dies reduziert die zum Ausführen eines Service Mesh erforderlichen Ressourcen erheblich. Da der Ambient-Modus von Istio keine Sidecar-Proxies erfordert, können Sie Anwendungen dem Mesh hinzufügen und daraus entfernen, ohne dass Sie Anwendungs-Pods ändern oder neu starten müssen.

Die zwei separaten Schichten des Ambient-Modus von Istio sind:

• Ztunnel: Ein schlanker Layer-4-Proxy auf Knotenebene (ausgeführt als Daemonset in Kubernetes), der einen Listen-Socket im Netzwerk-Namespace des Anwendungs-Pods erstellt, um den Datenverkehr auf Pod-Ebene transparent mit mTLS-Verschlüsselung zu aktualisieren. Ztunnel übernimmt auch das Zertifikats- und Identitätsmanagement für Pods auf dem Knoten (und nur die Pods auf dem Knoten). Mit Ztunnel allein können Sie automatische mTLS-Verschlüsselung, Layer-4-Telemetrie und Richtlinienverwaltung realisieren.
• Waypoint: Ein optionaler Envoy-Proxy, ähnlich einem Gateway, bietet für eine Reihe von Anwendungen (standardmäßig bezogen auf Namespace) Layer-7-Mesh-Funktionen. Dazu gehören Sicherheits- und Datenverkehrsrichtlinien auf Anwendungsebene, Telemetrie auf Anwendungsebene und Mesh-Resilienzfunktionen. Im Gegensatz zu Sidecars können Sie Waypoint-Proxys bei Bedarf hinzufügen und unabhängig von Anwendungscontainern skalieren.

Weitere Details zur Architektur des Ambient-Modus von Istio und zu verbundenen Kompromissen finden Sie im Beitrag Try Istio ambient mode on Red Hat OpenShift.

OpenShift Service Mesh 3.1 aktualisiert den Status des Ambient-Modus von Istio auf Technologievorschau mit einem vollständig von Red Hat unterstützten Ztunnel-Proxy, der OpenSSL-Verschlüsselung verwendet und so sicherstellt, dass er FIPS-konform ist. OpenShift Service Mesh 3.1 enthält als Teil des Installationshandbuchs eine Dokumentation für die ersten Schritte mit dem Ambient-Modus von Istio auf OpenShift. Dies wird in den kommenden Monaten auf dem Weg zur allgemeinen Verfügbarkeit erfolgen.

Beachten Sie, dass der Ambient-Modus von Istio die Kubernetes-Gateway-API erfordert. Verwenden Sie sie daher auf OpenShift Container Platform 4.19 oder höher, die unterstützte Gateway-API-CRDs enthält, die standardmäßig installiert sind. Wenn Sie mit dem Ambient-Modus von Istio in früheren Releases von OpenShift experimentieren möchten, müssen Sie nicht unterstützte Kubernetes Gateway API-CRDs installieren, wie in der Istio-Community-Dokumentation beschrieben. Beachten Sie, dass das Upgrade auf die unterstützten Kubernetes Gateway API-CRDs in OCP 4.19 Ausfallzeiten verursachen kann.

Wir empfehlen außerdem, mit dem Ambient-Modus von Istio in Clustern zu experimentieren, auf denen OpenShift Service Mesh noch nicht installiert ist, um mögliche Interferenzen mit bestehenden Service Mesh-Deployments zu verringern. In Zukunft stellen wir eine Dokumentation zum Ausführen einer Data Plane im Ambient-Modus neben einer Data Plane im Sidecar-Modus sowie Anleitungen zur Migration von Anwendungen vom Sidecar-Modus in den Ambient-Modus bereit.

Beachten Sie, dass ab Istio 1.26 nicht alle Sidecar-Modus-Funktionen im Ambient-Modus unterstützt werden und einige Features im Upstream Istio weiterhin auf „Alpha“ bleiben. Der Ambient-Modus ist möglicherweise nicht für sämtliche Use Cases von Service Mesh geeignet. Die wichtigsten Lücken sind Konfiguration mit mehreren Clustern und mehreren Netzwerken sowie die Interoperabilität zwischen Data Planes im Ambient- und Sidecar-Modus. Diese und weitere Features werden von der Istio-Community weiterentwickelt.

Kiali-Updates

Kiali ist die Konsole für das Istio Service Mesh, die in OpenShift Service Mesh enthalten ist. Dieses Release aktualisiert Kiali auf Version 2.11, die viele Updates und Erweiterungen enthält (wie den Ambient-Modus von Istio).

Updates der Mesh-Seite

Die Mesh-Seite wird weiterhin als primäres Dashboard für die Überwachung des Status der Istio-Infrastruktur verbessert, darunter die Istio Control Plane selbst, die Komponenten der Data Plane und die Beobachtbarkeits-Add-Ons wie Prometheus und Tempo. Dieses Release enthält mehrere Updates, darunter Istio-Gateways und die Komponenten der Data Plane im Ambient-Modus: Ztunnel und Waypoint. Von der Mesh-Seite aus können Sie Komponenten untersuchen und wichtige Statusinformationen sehen, einschließlich Metriken und Konfigurations-Dumps, die für die einzelnen Komponenten relevant sind.

Leistung und Skalierbarkeit bei großen Meshes

Eine häufige Sorge bei Kiali ist die Performance, wenn die Anzahl der Workloads im Service Mesh wächst. In der Vergangenheit hätte Kiali Schwierigkeiten gehabt, bei sehr großen Service Meshes reaktionsfähig zu bleiben. Die FAQ des Kiali-Projekts enthält jetzt einen neuen Abschnitt zum Thema Performance, der Anleitungen für die Verwendung von Kiali mit großen Mesh-Bereitstellungen enthält. Dieses Release enthält Updates zur Verbesserung der Performance, einschließlich Updates zur besseren Verwaltung großer Meshes.

Zum Beispiel versucht Kiali standardmäßig sofort, eine Seite zu rendern, und aktualisiert die meisten Seiten automatisch basierend auf der Einstellung im Dropdown-Menü Refresh Interval. Bei sehr großen Meshes kann selbst das anfängliche Rendering langsam sein, was Ihre Fähigkeit, die Konsole zu verwenden, verzögert. Kiali bietet jetzt eine Option Manual Refresh, mit der eine Seite nur aktualisiert wird, wenn die Schaltfläche Refresh manuell geklickt wird. Sie können dies mit spec.kiali_feature_flags.ui_defaults.refresh_interval: manual in der Kiali Custom Resource Definition (CRD) festlegen. 

Sie können jetzt auch Validierungen deaktivieren, um die Performance und Reaktionsfähigkeit bei großen Meshes zu verbessern. Sie können dies tun, indem Sie die Kiali Operator-Konfiguration wählenspec.external_services.istio.validation_reconcile_interval to 0.

Erste Schritte mit OpenShift Service Mesh

Wenn Sie neu bei OpenShift Service Mesh sind, beginnen Sie mit unserer Einführung in OpenShift Service Mesh und unseren Installationsanweisungen für Day 1. Für ein vollständiges Arbeitsbeispiel sehen Sie sich das Lösungsmuster Optimizing Traffic and Observability with OpenShift Service Mesh 3 an.

Wenn Sie mit OpenShift Service Mesh 3.0 arbeiten, lesen Sie die Upgrade-Dokumentation für verschiedene Ansätze zur Aktualisierung des OpenShift Service Mesh 3 Operators, der Istio Control Planes, der Istio CNI-Ressource und der Proxies, die die Data Plane bilden.

Wenn Sie OpenShift Service Mesh 2.6 oder früher nutzen, lesen Sie mehr über die Unterschiede zwischen OpenShift Service Mesh 2 und 3 sowie unsere ausführliche Migrationsdokumentation. Es gibt auch einen Blog-Beitrag, der das Verfahren unter Verwendung von Kiali beschreibt.