Cloud-nativ: Open Service Mesh steuert auf Version 1.0 zu

Das Team hinter dem Open Service Mesh (OSM) hat den Release Candidate der ersten Hauptversion veröffentlicht. Damit steuert das Projekt auf einen stabilen Stand zu. OSM ist ein Sandbox-Projekt unter dem Dach der Cloud Native Computing Foundation (CNCF).

Microsoft hatte das Open-Source-Projekt im Sommer 2020 mit dem erklärten Ziel veröffentlicht, die Community maßgeblich in die Weiterentwicklung einzubeziehen. OSM ist bewusst schlank gehalten und setzt auf Erweiterbarkeit. Zu den Designzielen gehört, dass es einfach zu verstehen, zu installieren und zu verwenden sein soll. Es implementiert das ebenfalls von der CNCF betreute Service Mesh Interface (SMI), das sich als Standardinterface für Service-Meshes im Kubernetes-Ökosystem versteht.

Strikt auf SMI ausgelegt

Neben OSM existieren zahlreiche Service-Meshes, darunter der Platzhirsch Istio, das Urgestein Linkerd, Kuma von Kong und Hashicorp Consul. SMI soll eine Mesh-übergreifende Kompatibilität gewährleisten, und an der Spezifikation sind unter anderem Microsoft, Hashicorp und Buoyant (das Unternehmen hinter Linkerd) beteiligt. Das Open Service Mesh ist von Beginn an streng auf SMI ausgerichtet.

Im Unterbau setzt OSM wie zahlreiche andere Service-Meshes auf Envoy. Neben den einzelnen Anwendungen läuft jeweils ein Envoy-Proxy als Sidecar im Container. Der Proxy verwaltet die Regeln unter anderem für die Zugriffskontrolle und die Routing-Konfigurationen. Die Kontrollschicht des Service-Mesh konfiguriert die einzelnen Proxies mit den zugehörigen Vorgaben und Richtlinien.

Vernetzte Microservices: Service-Meshes

In einer Microservice-Architektur arbeiten viele kleine Anwendungen beziehungsweise Dienste unabhängig voneinander. Ein Service-Mesh ist dafür zuständig, die unterschiedlichen Services miteinander zu verknüpfen. Es besteht aus einer Steuerungs- (Control Plane) und einer Datenschicht (Data Plane). Letztere setzt sich aus Proxies zusammen, die neben den Microservices laufen – in einem Kubernetes-Cluster üblicherweise in einem Sidecar.

Die Steuerungsebene ist für die Verwaltung der Dienste zuständig und greift auf die Services über die Proxies zu. Sie kann sie zum einen die Daten der Dienste auslesen und zum anderen die Interaktion steuern sowie die einzelnen Services konfigurieren.

Durch die Anbindung über Proxies im Sidecar müssen Entwicklerinnen und Entwickler ihre Anwendungen nicht für das Zusammenspiel mit dem Service-Mesh anpassen. Auch ist kein einheitliches Framework oder API-Gateway erforderlich, um die Dienste zu vernetzen.

Weitere Details lassen sich dem OSM-Blog entnehmen. Das Team hat sich demnach auch an zahlreichen anderen Projekten aus dem Kubernetes-Ökosystem beteiligt, um ein reibungsloses Zusammenspiel mit OSM zu gewährleisten. Dazu gehören der Open Policy Agent (OPA), das Delivery-Tool Flagger und der Ingress-Controller Contour. Einen genauen Termin für das endgülitge Release nennt der Beitrag dagegen nicht, sondern verspricht lediglich die Veröffentlichung in den nächsten Wochen.

(rme)