© Artspace/Shutterstock.com
Eine Einführung in die Nutzung von Istio bei Microservices-Architekturen

Keine Angst vorm Service Mesh


Je umfangreicher und verflochtener eine Microservices-Architektur wird, desto unübersichtlicher wird es. Man spricht hierbei vom sogenannten Service Mesh. Viele solcher Architekturen werden heutzutage nativ in der Cloud entwickelt. An diejenigen, die diese Microservices dann verwalten sollen, werden besondere Anforderungen gestellt. Das Tool Istio soll dabei behilflich sein, die Übersicht zu behalten.

Mit dem Einzug von Microservices als Grundlage einer modernen verteilten Anwendungsarchitektur entstehen immer öfter komplexe Laufzeitumgebungen. Bei der Verwaltung der steigenden Zahl an Services und Instanzen tauchen schnell typische Problemstellungen auf. Dabei entsteht ein Geflecht an Services, das Service Mesh. Da die Microservices in der Regel auf Cloudplattformen betrieben und Cloud-native entwickelt wurden, braucht es Werkzeuge, die bei der Verwaltung des Service Mesh in der Cloud helfen. Istio ist ein Werkzeug, das helfen soll, diesen wilden Zoo voller Services in den Griff zu bekommen.

Eine Microservices-Anwendung, die zum Beispiel aus einer zweistelligen Anzahl von Microservices besteht, kann bezüglich ihrer Verwaltung schon problematisch werden. In der Regel wird jede neue Version eines Microservice parallel zu vorhandenen Versionen desselben Microservice in Produktion deployt. Das geschieht deswegen, weil eine Abkündigung einer alten Version des Microservice nicht so einfach durchsetzbar ist und man die neue Version ohne Anpassungen an ältere Versionen mit weniger Nebeneffekten einfacher in Produktion bringt. Der Kompromiss, der dabei eingegangen wird, führt dazu, dass mehrere Versionen eines Microservice parallel existieren. Wenn durchschnittlich jeder Service in zwei oder drei Versionen parallel existiert, was nicht unüblich ist, verdoppelt bzw. verdreifacht sich die Anzahl der Services ganz schnell. Eine Microservices-Anwendung, die ursprünglich einmal mit beispielsweise fünfzehn Services gestartet ist, ist entsprechend schnell bei knapp fünfzig Services angelangt.

Was bei der Betrachtung der Services gerne zu kurz kommt, sind die notwendigen Datenbanksysteme, da ein Microservice in der Regel auch Persistenzanforderungen mit sich bringt. Die beteiligten Datenbankinstanzen gehören demnach auch zum Service Mesh (Kasten: „Service Mesh“). Dabei kann man noch froh sein, wenn sich mehrere Versionen eines Microservice dieselbe Datenbank teilen können, weil man es geschafft hat, das Datenbankschema abwärtskompatibel zu gestalten. In Erweiterung des obigen Beispiels der Microservices-Anwendung kommen zu den knapp fünfzig Services auch noch mindestens fünfzehn Datenbankservices hinzu. Das ergibt als Zwischenergebnis ungefähr sechzig Prozesse.

Service Mesh

Der Begriff Service Mesh umschreibt ein Geflecht von (Micro-)Services, die über Netzwerkaufrufe miteinander interagieren und so eine gesamtheitliche Anwendung bilden. Mit steigender Anzahl an Services wird das Aufrufverhalten der einzelnen Komponenten untereinander immer komplexer und analog auch schwieriger zu verstehen bzw. zu beherrschen.

Doch damit noch nicht genug. Die verteilte Anwendung sollte auch bezüglich Last und Ausfallsicherheit genügend Reserven mit sich bringen. Eine Verdopplung der Service-Anzahl, um die Verfügbarkeit zu erhöhen, ist in diesem Zusammenhang das einzuplanende Minimum. In unserem Anwendungsbeispiel wurde die magische Grenze von einhundert Prozessinstanzen gesprengt – bei anfänglich nur fünfzehn Microservices. Zusätzliche Faktoren, wie etwa Staging-Umgebungen oder spezielle Multi-Mandant-Anforderungen, können die Zahl nochmals deutlich in die Höhe treiben, oder lassen mehrere komplexe Service Meshes entstehen, die auch verwaltet werden müssen.

In der Konsequenz eines Service Mesh ergeben sich verschiedene Funktionalitäten, die ein Verwaltungswerkzeug bereitstellen muss. Angefangen bei Service Discovery und Load Balancing bis hin zu Resilienz und Failure Recovery. Damit wären zumindest die minimalen Notwendigkeiten der Service-zu-Service-Kommunikation abgedeckt. Für die Fehleranalyse ist es notwendig, die Aufrufketten der einzelnen Services nachverfolgen zu können. In der Regel ermöglichen das Tracing-Werkzeuge. Für die Ops-Kollegen sind Metrics und Monitoring für den stabilen Betrieb der verteilten Anwendung unerlässlich, und ohne Security (Access Control und End-to-End Authentication) kommen die wenigsten Anwendungen aus. Auch ein Rate Limiting ist manchmal notwendig, um eine Überlastung der verteilten Anwendung zu vermeiden. Darüber hinaus gibt es weitere Anforderungen, basierend auf weiterführenden Konzepten wie A/B Testing oder Canary Releasing, um neue Versionen von Microservices geordnet in Produktion zu bringen. Abschließend könnte noch der Wunsch nach Content-based Routing bestehen, um Aufrufe untereinander mittels Aufrufinhalt gezielt zu steuern. Für Entwicklung, Tests, aber auch Reproduktion von Fehlverhalten ist es des Öfteren nötig, Fehler oder Time-outs gezielt simulieren zu können.

Typische Vertreter, die dabei helfen sollen, Service Meshes zu beherrschen, basieren auf einem leichtgewichtigen Reverse Proxy, der als eigenständiger Prozess parallel zum Service-Prozess arbeitet. Dieser sogenannte Sidecar-Prozess kann dabei unter Umständen in einem eigenen Container, neben dem eigentlichen Service-Container, deployt werden. Jede eingehende und ausgehende Service-Kommunikation erfolgt entsprechend über das Sidecar. Darüber hinaus kommuniziert das Sidecar mit Service Registries und den Identity Providers oder kümmert sich um das Tracing der Aufrufketten. Durch den Ansatz eines Sidecars bekommt der eigentliche Microservice nichts von all dem mit. Dadurch muss der Service-Entwickler keine Zeile Code schreiben, um diese Funktionalitäten zu ermöglichen. Das hat den enormen Vorteil, dass sich dieselbe Technologie für eine polyglotte Microservices-Anwendung einsetzen lässt und der Entwickler sich der eigentlichen Implementierung des Microservice zuwenden kann. Die Verwendung von speziellen Frameworks (Service Discovery, Resilienz, Circuit Breaker ...) enfällt. Derzeit existieren zwei Vertreter dieser Service-Mesh-Werkzeuge: Istio [1] und Linkerd [2].

Das Istio-Patchwork

Istio an sich ist nicht neu, sondern aus einem Zusammenschluss von mehreren Open-Source-Projekten entstanden. Die Urväter von Istio, namentlich Google, IBM und Lyft, haben sich dafür offiziell zu einer Kooperation zusammengeschlossen. Die Namensgebung wurde von Googles Projekt Istio übernommen. IBM beteiligt sich mit Amalgam8, und Lyft bringt Envoy in die Ehe mit ein. Somit bleibt das einzig Neue am heutigen Istio das Zusammenwirken der einzelnen Komponenten.

Im Detail wurden beim Zusammenschluss folgende Funktionalitäten der einzelnen Parteien eingebracht: Googles Istio liefert das inhaltsbasierte Request-Routing zwischen unterschiedlichen Versionen eines Microservice. Somit kann auf Basis von geografischen Daten oder nur auf Basis des angemeldeten Users entschieden werden, welcher Service in welcher Version angesprochen werden soll. Hinzu kommen das Rate Limiting, die Auswertung von ACLs und die Sammlung der Telemetriedaten. Der wichtigste Teil aber ist die Integration von Istio in die Kubernetes-Laufzeitumgebung. Amalgam8 von IBM steuert unter anderem die Themen Service Discovery und Fehlerresilienz zusammen mit dem Test der Resilienz und Load Balancing bei. Ein erweitertes Content-based Routing ermöglicht außerdem ein Canary Releasing. Lyft liefert mit dem Envoy Proxy das Sidecar und damit das Herzstück von Istio. Der Fokus bei der Entwicklung des Envoy Proxies lag stark auf den Themen Performance und Security. Auch der Anschluss an das Tracingsystem Jaeger ist mit im Paket enthalten. Nach Angaben von Lyft lassen sich damit mehr als 10 000 VMs mit mehr als 100 Microservices ohne großen Aufwand betreiben. Die Kunst des Zusammenschlusses war es, die einzelnen Projekte zu einem Guss zu vereinen und dabei doppelte Funktionalitäten zu eliminieren, was bis Istio 1.0 stattgefunden hat.

Istio, das mit der Laufzeitplattform von Kubernetes gestartet ist, lässt sich mittlerweile auch auf Nomad und Consul betreiben. Weitere Plattformen wie Cloud Foundry und Apache Mesos sind für die Zukunft geplant. Nach Aussagen auf der Homepage von Istio [1] haben sich andere Mitbewerber wie Red Hat und Pivotal dazu entschieden, ihre existierenden Service-Discovery-Mechanismen durch Istio zu ersetzen. Dadurch soll die Kompatibilität von Istio bezüglich Kubernetes, Cloud Foundry und OpenShift erreicht werden. Damit unterstützen weitere mächtige Player in diesem Marktsegment die Einsatzmöglichkeiten von Istio. Aktuell sind Installationsskripte und -anweisungen für die folgenden Kubernetes-Plattformen vorhanden:

  • Minikube (für lokale Tests)

  • Google Kubernetes Engine

  • IBM Cloud Kubernetes Service (IKS)

  • IBM Cloud Private

  • OpenShift Origin

  • AWS

Istio lässt sich auf den gängigen Kubernetes-Cluster-Systemen entweder in der Cloud oder on premises betreiben. Sogar eigene Tests auf Minikube zusammen mit Istio sind ohne Probleme möglich.

Die Architektur von Istio

Istio unterteilt das Service Mesh logisch in zwei Ebenen: Data Plane und Control Plane (Abb. 1). Die Arbeit...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang