Red Hat OpenShift Service Mesh 3: Update zur Vorschau für Entwicklungsteams

Anfang dieses Jahres haben wir einen neuen Operator für Istio auf Red Hat OpenShift angekündigt, der als Entwicklungsvorschau der nächsten Generation von OpenShift Service Mesh, Version 3, verfügbar ist. Dieser Beitrag enthält wichtige Hintergrundinformationen zu den Änderungen, die 2024 für OpenShift Service Mesh eingeführt werden. Seitdem haben wir den Sail Operator weiterentwickelt und Feedback zu unseren Plänen für Service Mesh 3 gesammelt, bieten unseren Kunden aber nach wie vor Support für OpenShift Service Mesh 2. Der neue Operator ist zwar weiterhin nur als Entwicklungsvorschau verfügbar. In diesem Beitrag stellen wir jedoch ein Update bereit, besprechen zukünftige Pläne und geben eine erste Anleitung dazu, wie sich Nutzende von OpenShift Service Mesh auf OpenShift Service Mesh 3 vorbereiten können.

Updates zu Service Mesh 3.0

Der Service Mesh 3 Kubernetes Operator wird derzeit als „Sail Operator“ entwickelt und ist als Kubernetes Operator für die Community im Operator Hub von OpenShift verfügbar. Der Sail Kubernetes Operator wird jede Nacht aktualisiert, ist also noch in Arbeit und kann sich daher ändern. Da er sich damit auch von der Beschreibung in diesem Blog-Beitrag unterscheiden kann, sollten Sie ihn vorerst nur zum Experimentieren nutzen. Die neuesten Informationen zum Kubernetes Operator finden Sie in der enthaltenen README-Datei.

Wir planen, diese Community-Version des Kubernetes Operators in die Upstream-Organisation istio-ecosystem zu verschieben, um eine bessere Zusammenarbeit in der Community zu ermöglichen. Gleichzeitig werden Verbesserungen am Istio-Kernprojekt vorgenommen, um die Kompatibilität von Istio mit OpenShift zu optimieren. Die Downstream-Produktartefakte von OpenShift Service Mesh 3 werden sich in der neu erstellten Organisation openshift-service-mesh befinden, während die Organisation mainstra weiterhin für Service Mesh 2 verwendet wird.

Ein Kubernetes Operator nur für Istio

Wie bereits erwähnt, basiert OpenShift Service Mesh 3 auf einem neuen Kubernetes Operator für Istio. Im Gegensatz zum aktuellen OpenShift Service Mesh 2 Kubernetes Operator managt der neue Kubernetes Operator nur Istio-Ressourcen und versucht nicht, Istio-Integrationen wie Kiali zu konfigurieren. Komplementäre Komponenten wie Kiali, Metriken, Tracing und andere werden durch Kubernetes Operators unabhängig unterstützter Produkte gemanagt.

Als der Sail Operator erstmals veröffentlicht wurde, wurde die benutzerdefinierte Ressource für die Installation der Control Plane von Istio als IstioHelmInstall bezeichnet. Diese Ressource wurde in „Istio“ umbenannt, um widerzuspiegeln, dass sie für das Erstellen und Managen einer einzelnen Instanz von Istio (einer Control Plane und einer Datenschicht) verantwortlich ist.

Im Gegensatz zur benutzerdefinierten Ressource ServiceMeshControlPlane in OpenShift Service Mesh 2 verwendet die Istio-Ressource zur Definition der Istio-Konfiguration die  Helm-Werte von Upstream-Istio. Dadurch lassen sich die Konfigurationsbeispiele der Community von den Nutzenden einfacher in OpenShift Service Mesh 3 übersetzen. Außerdem wird so sichergestellt, dass zukünftige Bemühungen zur Verbesserung der Konfiguration in Zusammenarbeit mit der Istio-Community erfolgen. Wir haben eine zukünftige Konvergenz mit der Istio Operator-API der Community nicht ausgeschlossen, die mit dem Installationsprozess von istioctl und der nicht empfohlenen Upstream-Installation des Istio Operators verwendet wird.

Als Nächstes optimieren wir die Organisation der Konfiguration und Erweiterungen, um Funktionen wie Istio-Revisionen, Canary-Style-Upgrades und Mandantenfähigkeit besser zu unterstützen. Die neuesten Informationen finden Sie in der README-Datei des Kubernetes Operators.

Auswählen von Releases

Bei der erstmaligen Veröffentlichung des Sail Operators wurde die neueste Version von Istio bereitgestellt, genauer gesagt der Master-Zweig der Istio-Version, die noch in Entwicklung war. Dies war praktisch, um mit den neuesten Features der Istio-Community zu experimentieren. In den meisten Fällen sollten Nutzende jedoch ein offizielles Release von Istio verwenden, um die Stabilität und die Kompatibilität mit istioctl und Integrationen wie Kiali sicherzustellen.

Wir verwenden jetzt standardmäßig die neueste Version von Istio, aktuell die Version 1.20. Konfigurieren Sie dies im Feld version in der Istio-CRD. Beim Erstellen einer neuen Instanz mit der OpenShift-Konsole gibt es jetzt ein Drop-down-Menü, über das Sie aus einer Liste der verfügbaren Istio-Releases auswählen können. Die verfügbaren Istio-Releases sind in der Datei versions.yaml definiert, die für jedes neu verfügbare Istio-Release aktualisiert wird.

Drop-down-Menü zur Wahl des Istio-Releases

Der zukünftige Kubernetes Operator von OpenShift Service Mesh 3, der auf dem Sail Operator basiert, managt Releases von OpenShift Service Mesh auf ähnliche Weise. Dieses Feld version ähnelt zwar dem Feld version der Ressource ServiceMeshControlPlane in Service Mesh 2.x. Ein deutlicher Unterschied besteht jedoch darin, dass Nutzende eine Version bis zum „Patch“-Level Z des Releases angeben können (beispielsweise 3.1.1). Obwohl wir nur die neuesten Patch-Releases von OpenShift Service Mesh unterstützen, können Nutzende mit dieser Funktion ein bestimmtes Z-Patch-Release anpinnen oder ein Rollback zu diesem Release durchführen, was eine größere Kontrolle und Flexibilität beim Managen von Patch-Updates bietet.

Konfigurationsvalidierung

Das primäre Feld für die Konfiguration von Istio mit der neuen CRD ist das Feld values. Über dieses wirkungsvolle Feld können Nutzende direkt auf Istio Helm-Konfigurationswerte verweisen. Wir haben diesem Feld eine Validierung hinzugefügt, um nicht vorhandene Konfigurationswerte und andere Konfigurationsfehler basierend auf den protobuf-Validierungen von Upstream-Istio zu erfassen.

Diese Validierungen ermöglichen es auch, das Feld values wie folgt zu managen:

$ oc explain istio.spec.values 
KIND:     Istio 
VERSION:  operator.istio.io/v1alpha1 
RESOURCE: values <Object> 
DESCRIPTION: 
    Values defines the values to be passed to the Helm chart when installing 
    Istio. 
FIELDS: 
  base <Object> 
  cni <Object> 
  defaultRevision <string> 
  global <Object> 
  istio_cni <Object> 
  istiodRemote <Object> 
  meshConfig <> 
  ownerName <string> 
  pilot <Object> 
  revision <string> 
  revisionTags <[]string> 
  sidecarInjectorWebhook <Object> 
  telemetry <Object> 
  ztunnel <>

Da es Zeiten gibt, in denen es wünschenswert ist, diese Validierungen zu überschreiben, beispielsweise um auf eine experimentelle Konfiguration zuzugreifen, die noch nicht Teil des protobuf-Schemas von Istio ist, haben wir auch das Feld rawValues aufgenommen, das mit  values identisch ist, mit der Ausnahme, dass es nicht validiert wird.

Beachten Sie, dass die Istio-Felder resource, values und rawValues experimentell bleiben und Änderungen unterliegen können. Die neuesten Informationen finden Sie in der README-Datei des Projekts.

Istio-Status und -Konfiguration

Sobald Sie die Istio-Konfiguration angewendet haben, sollten Sie den Status Ihrer Control Plane validieren. Verwenden Sie dazu den folgenden Befehl:

$ kubectl get istioundefinedundefinedundefined

NAME         READY  STATUS VERSION AGE

istio-sample True  Healthy v1.20.0 62sundefinedundefined

Oder verwenden Sie das  Statusfeld:

Istio-CRD (Custom Resource Definition)

Wenn das Feld status.appliedValues erweitert ist, können Sie mithilfe des Felds spec.values überprüfen, ob die Konfiguration erwartungsgemäß angewendet wurde.

Istio auf OpenShift

Im Rahmen unserer Initiative, uns der Community-Version von Istio anzunähern, leisten wir weiterhin Beiträge zum Upstream-Istio, um die Kompatibilität von Istio mit OpenShift zu verbessern. Dies dient nicht nur unserem eigenen Vorteil (zur Vereinfachung der Produktivierung von Istio), sondern auch der Community sowie Kunden und Partnern. Unsere Beiträge erleichtern das Ausführen der Community-Version von Istio auf OpenShift und bieten gleichzeitig einen nahtlosen Onboarding-Pfad zu unserem unterstützten OpenShift Service Mesh.

Beispielsweise entfernten wir kürzlich in Istio 1.20 die anyuid -SCC-Berechtigung (Security Context Constraint) für die Control Plane- und Data Plane-Komponenten von Istio. Wir leisten auch weiterhin fortlaufend ähnliche Beiträge. Der wichtigste davon wird der Versuch sein, das Ambient Mesh von Istio auf OpenShift zum Laufen zu bringen.

Best Practices für Gateways

Mit der Ankündigung dieses Kubernetes Operators wurden automatisch Gateways installiert, ähnlich wie beim standardmäßigen Installations-Konfigurationsprofil von Istio. Dies steht im Einklang mit OpenShift Service Mesh 2.x, das ein standardmäßiges Ingress und Egress Gateway namens istio-ingressgateway bzw. istio-egressgateway erstellt.

Diese automatisch erstellten Gateways sind zwar für den Einstieg praktisch, bieten jedoch nicht die für Produktivumgebungen erforderliche Konfigurierbarkeit. Wir sind außerdem überzeugt, dass es besser ist, Gateways zusammen mit ihren Anwendungen in der Data Plane statt in der Control Plane zu erstellen und zu managen. Gateways, die zusammen mit ihren Anwendungen erstellt und gemanagt werden, stellen eine bessere Sicherheitspraxis dar, da sie den Geltungsbereich eines Gateways auf eine kleinere Gruppe von Anwendungen beschränken und es dem Gateway ermöglichen, den Lifecycle seiner Anwendungen statt der Control Plane zu übernehmen.

Daher haben wir uns dafür entschieden, diese Control Plane-Gateways zu entfernen. Stattdessen werden die Nutzenden dazu angeleitet, Gateways zusammen mit ihren Anwendungen zu erstellen – entweder per Gateway-Injektion oder mit der Kubernetes-Gateway-API. istio-ingressgateway und istio-egressgateway, wie in ServiceMeshControlPlane von OpenShift Service Mesh 2.x angegeben, sind in Service Mesh 3.0 nicht enthalten. Stattdessen stellen wir Beispielkonfigurationen von Gateways für die Bookinfo-Anwendung mit Gateway-Injektion und der Kubernetes-Gateway-API bereit.

Bei der Gateway-Injektion werden Gateways wie jeder andere Workload in Kubernetes oder OpenShift mit einer Deployment-Ressource erstellt und gemanagt, der ein Envoy-Proxy injiziert wird. Bei diesem Ansatz haben die Anwendungsverantwortlichen die vollständige Kontrolle über das Gateway. Dies ist die empfohlene Methode zum Erstellen und Managen von Gateways in OpenShift Service Mesh 2.3 und höher.

Mit der Gateway-API, die in der Technologievorschau von OpenShift Service Mesh 2.4 enthalten ist, wird bei jeder Gateway-Instanz eine Gateway-Instanz vom Typ „Deployment“ erstellt und konfiguriert.

Mit diesen Optionen können Gateways zusammen mit den Anwendungen erstellt und gemanagt werden, idealerweise als Bestandteil eines GitOps-Workflows.

Kubernetes-Gateway-API

Die Kubernetes-Gateway-API stellt die nächste Generation von APIs zur Netzwerkmodellierung in Kubernetes dar. Im Vergleich zur aktuellen Kubernetes-Ingress-API bietet sie wesentlich mehr Flexibilität und Erweiterbarkeit für das Netzwerkmanagement in einer großen Organisation. Obwohl diese Option ursprünglich für die Verwaltung des North-South-Datenverkehrs von Clients außerhalb des Clusters gedacht war, wurde mittlerweile auch der East-West-Datenverkehr inklusive Service Mesh miteinbezogen. Die GAMMA-Initiative wurde ins Leben gerufen, um zu definieren, wie die Gateway-API Use Cases für Service Mesh abdecken kann. Istio enthält jetzt die Gateway-API-Konfigurationsbeispiele für die meisten dokumentierten Aufgaben, beispielsweise Datenverkehrsmanagement.

Die Gateway-API ist zwar in OpenShift Service Mesh 2.4 weiterhin nur als Feature der Technologievorschau verfügbar und muss mit dem  Feature Flag aktiviert werden, aber sie ist jetzt in der Community allgemein verfügbar. Version 1.0 der API ist in Istio 1.20 verfügbar, was in OpenShift Service Mesh ab Version 2.6 enthalten ist. Istio plant, die Gateway-API in Zukunft zur Standard-API für das gesamte Datenverkehrsmanagement zu machen. Istio-APIs (Gateway, VirtualService, DestinationRule usw.) sollen aber in der absehbaren Zukunft weiterhin unterstützen werden.

Das Potenzial des Gateway-API-Projekts, einen gemeinsamen Standard für Kubernetes-Netzwerke bereitzustellen, geht weit über das Service Mesh hinaus.

Wir entwickeln eine auf der Gateway-API basierende Implementierung von OpenShift Ingress, die Nutzende unabhängig von einem Service Mesh über den Ingress Operator der Gateway-API bereitstellen können. Weitere Informationen hierzu und zur Gateway-API finden Sie in diesem Blog-Beitrag und im -Update.

In der Zwischenzeit arbeitet das Team, das 3Scale API Management entwickelt hat, am Kuadrant.io-Projekt, das die Gateway-API für Use Cases rund um den Zugang von externem Datenverkehr zu Ingress-Gateways nutzt, z. B. Multi-Cluster-Konnektivität, globales Load Balancing, Rate Limiting, Autorisierung und mehr. Informationen zu diesem Projekt finden Sie in einem späteren Blog-Beitrag.

Istio-Add-ons wie Kiali

Eine wichtige Änderung in OpenShift Service Mesh 3.0 ist, dass der Kubernetes Operator nur Istio managt. Integrationen wie Kiali, Distributed Tracing und Metriken werden unabhängig davon installiert und gemanagt. Obwohl dies den Einstieg um einige Schritte verlängert, sind wir überzeugt, dass sich der Kompromiss aus mehr Modularität und Flexibilität bei der Konfiguration dieser Komponenten lohnt.

Damit Nutzende schnell starten können, haben wir der README-Datei zum Kubernetes Operator Anweisungen zur Einrichtung von Istio mit Istioctl, Beispiel-Gateways, Prometheus, Jaeger und Kiali hinzugefügt. Dadurch wird eine Demo-/Entwicklungsumgebung bereitgestellt, die in etwa dem entspricht, was OpenShift Service Mesh 2.x standardmäßig bietet. Nutzenden wird außerdem eine Vorschau des Installations-Workflows gezeigt, den wir in OpenShift Service Mesh 3 planen. Istio wird dabei eigenständig installiert, und die Add-ons lassen sich unabhängig voneinander installieren. Natürlich verwendet das unterstützte Service Mesh 3.0 Kubernetes Operators unterstützter Produkte für jedes der Istio-Add-Ons mit einer unterstützten Distribution von Istioctl. Diese Add-On-Konfigurationen der Community-Version von Istio dienen nur zu Demonstrations-/Entwicklungszwecken und sollten nicht für Produktivumgebungen verwendet werden.

Vorbereitung auf Service Mesh 3.0

Es gibt verschiedene Möglichkeiten, wie sich Nutzende von OpenShift Service Mesh 2 auf die Einführung von Service Mesh 3.0 vorbereiten können.

Sie sollten beachten, dass OpenShift Service Mesh 3 weiterhin auf Istio basiert und die stabilen APIs von Istio, die Endbenutzende wahrscheinlich verwenden, unverändert bleiben. Was sich in OpenShift Service Mesh 3 ändert und eine Migration erfordert, sind die Konfigurationsressourcen der Control Plane, wie etwa ServiceMeshControlPlane,  ServiceMeshMemberRoll und ServiceMeshMemberRoll. Diese Ressourcen werden in der Regel von Administrations- oder Plattformteams gemanagt anstatt von den Anwendungsverantwortlichen. Wir erkunden weiterhin Möglichkeiten, wie Admins ihre bestehenden Control Plane-Konfigurationen zu den Konfigurationen in Service Mesh 3 migrieren können.

Anwendungsspezifische Konfigurationen, d. h. Istio-Ressourcen wie VirtualServices,  DestinationRules und sogar PeerAuthentication, bleiben unverändert. Daher sollten Nutzende sich sicher sein, dass sie mit OpenShift Service Mesh 2 beginnen oder die Nutzung ausweiten können, ohne anwendungs- oder servicespezifische Konfigurationen migrieren zu müssen, wenn sie zu OpenShift Service Mesh 3 wechseln.

Es gibt einige Schritte, die Nutzende schon heute unternehmen können, um die Migration zu OpenShift Service Mesh 3.0 zu vereinfachen. Neben der Verwendung des neuesten OpenShift Service Mesh Releases (2.4 oder höher) können Nutzende sich auf folgende Weise vorbereiten:

• Einführung von oder Migration zu Gateway-Injektion zur Erstellung und Verwaltung von Istio-Gateways mit ihren Anwendungen statt mit der Control Plane von Istio, was die Standardeinstellung in Service Mesh 2.0 ist. Wie oben beschrieben, erstellt die Control Plane in 3.0 keine Gateways.
• Nutzung des clusterweiten Modus, wenn nicht mehrere Control Planes erforderlich sind. In diesem Modus wird der Istiod als Ressource auf Cluster-Ebene ausgeführt. Dies ist der Standard in Service Mesh 3.0, wobei die Möglichkeit besteht, mithilfe des neuen Features Multiple-Control Plane mehrere Control Planes zu erstellen.
• Konfiguration von Service Mesh, zum Erfassen von Metriken das Workload-Monitoring in OpenShift oder die Observability-Komponente in Red Hat Advanced Cluster Management zu nutzen. Diese bieten einen produktionsreifen Monitoring-Stack mit Warnungen, der sich wesentlich besser konfigurieren und erweitern lässt als der mit OpenShift Service Mesh 2.x installierte Metrik-Stack, der in Service Mesh 3 nicht mehr enthalten ist.
• Nutzung von extern konfigurierten Kiali- und Jaeger-Ressourcen, anstatt diese direkt in der Ressource ServiceMeshControlPlane zu konfigurieren. Diese sorgen nicht nur für mehr Flexibilität beim Management von Kiali und Jaeger, sondern werden in Service Mesh 3 auch unabhängig voneinander konfiguriert.

In einem späteren Blog-Beitrag gehen wir ausführlicher auf diese Themen ein.

Wie geht es mit OpenShift Service Mesh weiter?

Unser nächstes Release OpenShift Service Mesh 2.5 (basierend auf Istio 1.18) erscheint Anfang 2024. Wir haben uns außerdem entschlossen, 2024 ein Release 2.6 basierend auf Istio 1.20 oder höher zu veröffentlichen, um sicherzustellen, dass Kunden mindestens 1 Jahr lang überschneidenden Support für das Upgrade von OpenShift Service Mesh 2 auf Service Mesh 3 haben. Das Release 2.6 gibt uns außerdem mehr Zeit, Feedback zu OpenShift Service Mesh 3 zu sammeln, während es sich im Status der Technologievorschau befindet.

Für OpenShift Service Mesh 3 entwickeln wir den neuen Kubernetes Operator weiter. Dazu zählen Anpassungen an den benutzerdefinierten Ressourcendefinitionen, um die Istio-Konfiguration besser zu verwalten, und zusätzliche Funktionen zur besseren Unterstützung von Canary-Upgrades der Control Planes von Istio. Wir planen eine Technologievorschau mit allgemeiner Verfügbarkeit für die zweite Jahreshälfte von 2024. Natürlich können sich diese Ziele ändern. Wir stellen unsere Kunden aber weiterhin Support für OpenShift Service Mesh 2.x bereit, bis wir ein OpenShift Service Mesh 3 anbieten können, das wir generell verfügbar machen wollen.

Auf dieser Seite erfahren Sie mehr über Red Hat OpenShift Service Mesh.