Alle 11 Minuten verliebt sich ein Microservice in Linkerd
Istio ist der Platzhirsch unter den Service-Meshes, aber die Alternative Linkerd weiß durch schnelle Konfiguration und leichte Bedienbarkeit zu überzeugen.
- Daniel Bornkessel
- Hanna Prinz
Neue Anforderungen an zeitgemäße Webservices erfordern oft einen Wechsel von alten, monolithischen Architekturen hin zu Microservices. Das Einführen der Architektur schafft ein verteiltes System, dessen Betrieb äußerst komplex sein kann. Zusätzlich kann die Kommunikation zwischen Services fehlschlagen, da sie über das Netzwerk verläuft. Der Container-Orchestrierer Kubernetes bietet eine Plattform, um das Betreiben von Microservices zu vereinfachen. Sie automatisiert Aufgaben, die früher Administratoren manuell ausgeführt haben.
Kubernetes hat einen klaren Zuständigkeitsbereich, der aber einige Probleme von Microservices ungelöst lässt. Es ist deshalb immer noch komplex, Microservices in einem Kubernetes-Cluster zu betreiben. Service-Meshes können helfen, die Komplexität zu verringern.
Mehr zu Service-Meshes
Auf dem Online-Channel heise Developer sind eine ganze Reihe weiterer Artikel zu finden, die sich unterschiedlichen Aspekten der Service-Mesh-Techniken widmen.
Was ist ein Service-Mesh?
Service-Meshes lösen Probleme die weder im Zuständigkeitsbereich der technischen Infrastruktur noch der Fachlichkeit liegen. Ein Beispiel ist die sichere Kommunikation zwischen Microservices: Kubernetes stellt eine Netzwerk- und eine Serviceabstraktion zur Verfügung, mit denen Microservices kommunizieren können. Es forciert aber nicht, dass die Kommunikation verschlüsselt stattfindet.
Funktionen wie das Verschlüsseln von Netzwerkkommunikation, Monitoring, Routing und andere Aspekte, die jeder Microservice benötigt, kann man als Aufgaben der Applikationsinfrastruktur bezeichnen. Entwickler setzen sie häufig mit Bibliotheken in den Microservices um. Mit einem Service-Mesh können sie die Funktionen der Applikationsinfrastruktur jedoch aus den Microservices in die Infrastruktur heben.
Wenn Aspekte der Applikationsinfrastruktur durch Bibliotheken wie Hystrix ergänzt werden, setzt das allerdings voraus, dass alle Microservices dasselbe Framework und häufig dieselbe Programmiersprache nutzen. Zusätzlich kann das Einbinden solcher Bibliotheken das lokale Entwickeln erschweren. Beim Beispiel der verschlüsselten Kommunikation muss man dazu entweder Zertifikate erstellen oder, je nach Umgebung, die Verschlüsselung ein- beziehungsweise ausschalten. Zertifikate lokal zu pflegen ist aufwendig. Die Verschlüsselung umgebungsabhängig ein- und auszuschalten ist Logik, die nicht in Microservices gehört.
Service-Meshes verlagern die Applikationsinfrastruktur in Proxys, die Anfragen an und von Microservices abfangen, analysieren, eventuell anreichern und erst anschließend an den jeweiligen Empfänger weiterleiten. Die Proxys ähneln Reverse-Proxys wie nginx oder HAProxy. Sie stellen neben den klassischen Aufgaben wie Load Balancing und Routing noch andere Funktionen zur Verfügung und können über eine API dynamisch konfiguriert werden.
Mit dem simplen Konzept der Proxys lassen sich Probleme wie Verschlüsselung, Metriken zum Netzwerkverkehr, Canary Releasing oder Resilienz lösen. Die enge Lokalität eines Microservices mit seinem Service-Proxy lässt sich in Kubernetes einfach mit Pods realisieren. Jedem Applikations-Container können Entwickler im selben Pod automatisch einen Service-Proxy-Container zur Seite stellen. Die Komposition von Applikationen und der Applikationsinfrastruktur geschieht mit Standardbordmitteln von Kubernetes. Dabei müssen Entwickler die Proxys nicht einmal explizit definieren, sondern können sie hinter den Kulissen automatisch in die Pods injizieren.
Die Gesamtheit aller Proxys bilden bei einem Service-Mesh die Data Plane. Neben der Data Plane weist ein Service-Mesh als zweite Komponente die Control Plane auf.
Die Control Plane steuert alle Proxys der Data Plane. Damit kann man die Proxys dynamisch zur Laufzeit anpassen. Service-Meshes, die auf Kubernetes laufen, können aktuelle Service-Instanzen und deren Identität über die Kubernetes API abfragen. Service Meshes können auf Veränderungen im Cluster reagieren, indem sie auf Kubernetes API-Events reagieren.
Kubernetes und Service-Meshes ergänzen sich gut und sind daher oft zusammen im Einsatz. Manche Varianten,zum Beispiel Linkerd 2, setzen Kubernetes als Laufzeitumgebung voraus. Andere wie das Service-Mesh Istio oder Consul, sind flexibler und unterstützen verschiedene Umgebungen. Linkerd 2 verlässt sich auf die Funktionen, die Kubernetes zur Verfügung stellt und integriert sich, anstatt eigene Konzepte zu Kubernetes hinzuzufügen. Im Gegensatz dazu hat Istio keine Scheu, neue Konzepte einzuführen.
Istio: Der Platzhirsch mit Schwächen
Wer über Service-Meshes spricht, kommt um Istio nicht herum. Es ist wohl das bekannteste Service-Mesh, maßgeblich entwickelt von Google und IBM. Google hat mit der Entwicklung von Kubernetes die Bedürfnisse der Industrie auf den Punkt getroffen. Entsprechend hoch waren der Vertrauensvorschuss, aber auch die Erwartungen an Istio.
Istio war von Anfang an mit vielen Features ausgestattet und wurde seitens Google intensiv beworben. Das hat Istio viel Aufmerksamkeit beschert. Die erste produktionsreife Istio-Version stellte sich jedoch als überkomplex heraus und es gibt nur wenige Berichte von der Nutzung Istios in Produktivsystemen. Die aktuelle Version 1.2 hat die Komplexität bereits reduziert und weitere Veränderungen sind geplant. Die extreme Konfigurierbarkeit und Flexibilität sind allerdings zentrale Designentscheidungen von Istio und bleiben dem Projekt daher auf absehbare Zeit erhalten.
