Service-Mesh: Istio 1.1 zielt auf Skalierbarkeit und Performance
Das quelloffene Service-Mesh bringt unter anderem Ressourcen zum Konfigurieren der Sidecar-Proxys und beschränkt die Sichtbarkeit von Services.
Monika1607, Pixabay
- Rainald Menge-Sonnentag
Gut neun Monate nach der ersten Hauptversion ist nun Istio 1.1 erschienen. Die Macher des Service-Mesh setzen für das Release vor allem auf unternehmensgerechte Performance und Skalierbarkeit. Dafür haben sie sowohl die Daten- als auch die Steuerebene überarbeitet. Außerdem gibt es zahlreiche kleinere Verbesserungen in den Bereichen Security und Policy-Verwaltung.
Details und Benchmarks zu der Performance und Skalierbarkeit von Istio 1.1 hat das Istio-Team auf einer Übersichtsseite zusammengefasst. Zugunsten der Performance sind Policy-Checks standardmäßig deaktiviert. Die Istio-Dokumentation beschreibt, wie Administratoren sie während der Installation oder für vorhandene Meshes aktivieren können.
Namensräume und Proxys
Namespaces lassen sich in Istio 1.1 besser verwalten. Unter anderem können Service Owner mit exportTo festlegen, welche Namensräume den Dienst referenzieren dürfen. Die Begrenzung ist sowohl für VirtualService- und ServiceEntry als auch für Kuberentes-Services möglich. Außerdem lassen sich Namespaces einem speziellen Scope zuweisen, um Unklarheiten zu vermeiden, wenn mehrere Namensräume einen VirtualService für denselben Host-Namen definieren.
Neu ist zudem die Sidecar-Ressource zum Konfigurieren der Sidecar-Proxys. Administratoren können damit unter anderem festlegen, dass alle Dienste in einem Namensraums nur auf andere Dienste innerhalb desselben Namespace zugreifen dürfen. Die passenden Begrenzungen reduzieren den Speicherbedarf gegenüber der standardmäßigen Konfiguration, bei der jeder Sidecar-Proxy jeweils die vollen Ressourcen benötigt, um jeden anderen Dienst innerhalb des Mesh erreichen zu können.
Eine neue Komponente namens Galley verwaltet Konfigurationen und verteilt sie an die Istio-Komponenten, die sie dabei von den Kubernetes-Details abschirmt. Galley setzt auf das Mesh Configuration Protocol (MCP), eine Subscription-basierte API zum Verteilen von Konfigurationen.
Istio: Historie und Weiterentwicklung
Die ursprünglichen Initiatoren von Istio waren 2017 Google, IBM und Lyft. Letzteres hat Envoy beigesteuert, von Big Blue stammt Amalgam8 und Googles Service Control rundet das Ursprungsprojekt ab. Seit dem 1.0-Release im August 2018 gilt das Projekt als stabil für den Produktiveinsatz. Istio bildet als Service Mesh eine Infrastrukturkomponente in Microservice-Architekturen und soll die Komplexität der verteilten Deployments reduzieren beziehungsweise das Management vereinfachen. Mit Istio können Administratoren und Entwickler einzelne Dienste miteinander verbinden, beobachten, steuern und absichern.
Weitere Details zu Istio 1.1 lassen sich einem Blogbeitrag entnehmen. Alle wesentlichen Neuerungen finden sich in den Release Notes. Für die Weiterentwicklung finden vierzehntägig Community-Meetings statt, die öffentlich und als Aufzeichnungen in einem eigenen YouTube-Channel verfügbar sind. Eine Übersicht auf GitHub listet die einzelnen Arbeitsgruppe von Istio auf.
Siehe dazu auf heise Developer:
Microservices sind zudem das Titelthema von iX 4/2019.
(rme)
