Microsofts Antwort auf Googles Eigensinn Open Service Mesh – Das Ende von Istio?

Anbieter zum Thema

netfiles GmbH

Hyland Software Germany GmbH

Cloudgermany.de GmbH

Verteilte Anwendungen verdanken ihre cloud-native Skalierbarkeit einem Orchestrierungsframework wie Kubernetes, welches für die reibungslose Konnektivität containerisierter Anwendungsarchitekturen einen robusten Service-Mesh in die Pflicht nimmt.

Zur Verwaltung verteilter Anwendungsinfrastrukturen durch einen Cloud-Orchestrierer ist ein leistungsstarker dynamischer Service Mesh unumgänglich (Service-Netz). Dabei handelt es sich um eine Virtualisierungsebene verteilter Konnektivität zur Gewährleistung kontinuierlicher Dienstverfügbarkeit.

Kubernetes setzt auf Istio, den quelloffenen Service Mesh von Google. Doch während der quelloffene Orchestrierer alle Rekorde der Popularität bricht, stößt sein Service Mesh Istio bei den Nutzern auf wenig Gegenliebe. Es sei zu kompliziert, zu umständlich und zu unflexibel.

Auf das richtige Pferd setzen

Das größte Problem besteht wohl aber auch darin, dass es schlicht zu viele ähnlich praxisfremde Lösungen gibt: Googles Istio, Open Source Linkerd, HashiCorp's Consul und experimentellere Tools wie das Aspen Mesh von F5. Azure Kubernetes Service vertraute bisher auf Istio, Linkerd oder Consul. Unternehmen tun sich also schwer, die für sie passende Wahl zu treffen und diese unternehmensweit zu standardisieren.

Googles Konzernzentrale bereut inzwischen die Übergabe von Kubernetes an die CNCF (Cloud Native Computing Foundation). Denn auf dem Kubernetes-Unterbau ist inzwischen eine ganze Industrie entstanden, welche dem Cloud-Riesen mehr geschadet als geholfen hat. Googles direkte Mitbewerber HPE, VMware, RedHat und SAP haben einen wesentlichen Teil ihres Geschäftes auf Kubernetes aufgesetzt und erwirtschaften damit beachtliche Umsätze, ohne dass Google jetzt davon profitieren kann.

Mit Istio möchte Google diesen Fehler nicht wiederholen. Istio entstammt genauso wie Kubernetes der Feder von Googles Ingenieuren und zählt zu den prominentesten Open-Source-Projekten aller Zeiten. Die hohe Popularität des cloud-nativen Orchestrierers hat auch Istio zu einer hohen Akzeptanz verholfen. Umso größer war die Empörung der Nutzer- und Entwicklergemeinde, als Google bei der schon lange geplanten Freigabe des Projektes an die CNCF plötzlich „kalte Füße“ bekam.

Aus der Sicht von Marktakteuren wie HPE (Ezmeral) und VMware (Tanzu) hat sich die Unsicherheit rund um Istio zu einem ernsthaften Problem entwickelt. Denn wer das Service Mesh kontrolliert, kontrolliert das gesamte Kubernetes-Ökosystem. Microsoft hält Googles Kontrolle über das Istio-Projekt ebenfalls für eine schlechte Idee und wertet die Zukunft der Software als ungewiss.

Microsofts Gegenoffensive

Als Antwort auf die Unsicherheit rund um die Governance von Istio hat Microsoft eine eigene quelloffene Service-Mesh-Implementierung in Googles eigener universellen cloud-nativen Sprache Go/golang entwickelt und im vergangenen August (2020) veröffentlicht. Microsofts Ingenieure haben es nicht dabei belassen, einen vermeintlich cloud-freundlicheren Service Mesh als Alternative zu Istio zu erfinden.

Redmond hat das Projekt unter eine Open-Source-Lizenz gestellt und die Kontrolle daran an dieselbe Cloud Native Computing Foundation (CNCF) übertragen, der Google sein Istio nicht mehr gönnen wollte, obwohl sie Kubernetes zum derart durchschlagenden Erfolg verholfen hatte. Die CNCF verantwortet somit sowohl die Entwicklung von Kubernetes als auch jene des Open Service Mesh und dürfte sich im Eigeninteresse um die reibungslose Integration der beiden Projekte kümmern, wenn auch zum Nachsehen von Google.

Bei Microsofts Open Service Mesh handelt es sich um eine quelloffene Referenzimplementierung von SMI auf der Basis von OSM (Open Service Mesh). „SMI ist bei den Leuten sehr beliebt und wir dachten, dass das Ökosystem genug Raum für eine Referenzimplementierung von SMI hergibt, bei der die Mesh-Technologie in erster Linie diese SMI-APIs implementiert und sie für Kunden in ein bestmögliches [anbieter-agnostisches] Erlebnis verwandelt“, kommentierte Microsoft Gabe Monroy, Director of Partner Management für Azure Compute und CNCF-Vorstandsmitglied.

Google in der Defensive

Bei SMI (kurz für Service Mesh Interface) handelt es sich um eine Sammlung von standardisierten portablen Schnittstellen für Service-Mesh-Dienste auf Kubernetes. SMI versteht sich als eine Sammlung von CRDs (Kubernetes Custom Resource Definitions) und Extension API Servern, die sich auf jedem Kubernetes-Cluster anbieter-agnostisch einrichten und mit Standardtools bearbeiten lassen. Auf diese Weise können Benutzer in ihren Anwendungen Service-Mesh-Technologie verwenden, ohne sich an eine bestimmte Implementierung irreversibel zu binden.

OSM implementiert das Service Mesh Interface (SMI) zum Absichern und Verwalten von Microservice-Anwendungen. Hierzu macht sich OSM ein Tool namens Envoy zu Nutze, welches genauso wie Kubernetes unter der Schirmherrschaft der CNCF entwickelt wird. Damit ist Microsoft ein schlauer Schachzug gelungen:

• Sowohl OpenShift Kubernetes von Red Hat, HPE Ezmeral als auch VMware Tanzu Service Mesh nutzen Istio als eine Abstraktionsebene zum Verwalten von Microservices in Kubernetes-Workloads. Das OSM-Projekt baut auf den Ideen und Implementierungen vieler cloud-nativer Ökosystemprojekte auf, darunter Linkerd, Istio, Consul, Envoy, Kuma, Helm und die SMI-Spezifikation.

• Die Steuerebene von OSM implementiert das xDS von Envoy und ist mit SMI-APIs konfiguriert. OSM fügt einen Envoy-Proxy als Sidecar-Container neben jeder Instanz einer Anwendung ein.

• Die Datenebene (die Gruppe von Envoy-Proxys, die als Teil von OSM ausgeführt werden) führt Zugriffssteuerungsrichtlinien aus, implementiert die Routing-Konfiguration und erfasst Metriken. Die Steuerebene programmiert die Datenebene kontinuierlich, um sicherzustellen, dass Richtlinien und Routing-Regeln auf dem neuesten Stand sind und die Datenebene fehlerfrei funktioniert.

Stein des Anstoßes und Qual der Wahl

Zur Verwaltung des Zugriffs externer Nutzer auf die Dienste eines Kubernetes-Clusters dient in Kubernetes ein API-Objekt namens Kubernetes Ingres. Es stellt Routing-Tabellen für die regelbasierte Steuerung von Datenflüssen und Dienste wie die Lastverteilung bereit. Das Hauptproblem beim Einsatz des API-Objektes Kubernetes-Ingress liegt in der Tatsache, dass es nicht von der Istio-Steuerungsebene verwaltet werden kann, sodass Istio-Funktionen wie Routing-Regeln, verteilte Ablaufverfolgung, Telemetrie und Richtlinienprüfung beim Ingress nicht verfügbar sind.

Für den Einsatz mit Azure Kubernetes Service empfiehlt Microsoft derzeit nach wie vor Istio, Linkerd oder Consul. Dies ist nicht der einfachste Ansatz. Denn zum Verwalten des Service Mesh werden sowohl eine separate virtuelle Maschine als auch ein laufendes Kubernetes-Cluster auf AKS benötigt. SMI (Service Mesh Interface) soll das Problem lösen. Es stellt einen Standardsatz von Schnittstellen zum Verknüpfen von Kubernetes mit Service Meshes bereit. Azure unterstützt bereits SMI, da das Kubernetes-Team die Entwicklung geleitet hatte.

* Das Autorenduo Anna Kobylinska und Filipe Pereira Martins arbeitet für McKinley Denali Inc. (USA).

(ID:47006260)