© DrHitch/Shutterstock.com
Von Monolithen und Microservices

5 Verwaltung Cloud-nativer Microservices mit Istio


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, und es werden besondere Anforderungen an diejenigen gestellt, die diese Microservices dann verwalten sollen. Das Tool Istio soll dabei behilflich sein, die Übersicht zu behalten.

Im vorigen Kapitel haben wir uns mit den Themen Service Mesh und Istio als Werkzeug zur Beherrschung solcher Service Meshes beschäftigt. Nachdem wir die Architektur von Istio genauer beschrieben haben, beschäftigen wir uns diesmal mit den zur Verfügung stehenden Tools von Istio. Anhand von Beispielen erläutern wir dabei die verschiedenen Konfigurationsmöglichkeiten. Dazu dient die Bookstore-Anwendung, die in einem Kubernetes-Cluster installiert wird. Die Bookstore-Anwendung stellt ein einfaches Service Mesh dar, bestehend aus einer Webapplikation und mehreren REST Services in verschiedenen Versionen. Dies sollte ausreichen, um verschiedene Aspekte Istios genauer kennen zu lernen.

Automatic Sidecar Injection

Ein wesentliches Feature von Istio ist es, das Sidecar automatisch bereitzustellen. Durch das Sidecar werden alle Requests und Responses der Anwendung geleitet. Beim Deployment einer Anwendung wird anhand des benutzten Kubernetes Namespace festgelegt, ob ein Sidecar provisioniert werden soll oder nicht. Um beispielsweise den Default-Namespace in Kubernetes für Sidecar Injection zu aktivieren, muss das Label istio-injection in diesem Default-Namespace auf enabled gesetzt werden:

kubectl label namespace default istio-injection=enabled

Wird eine neue Anwendung installiert bzw. ein Pod neu erzeugt, stellt Istio automatisch einen Envoy Proxy als Sidecar zur Verfügung. Über iptables-Regeln wird der Datenverkehr dieses Pods via Sidecar abgewickelt, und Kubernetes kümmert sich ab sofort um die Verwaltung dieses Sidecars. Auf diese Weise erhält man die gesamte Bandbreite an Istio-Features, ohne eine Zeile Code in der Anwendung verändern zu müssen.

Das Sidecar, das essenziell für den Betrieb von Istio ist, muss logischerweise überwacht werden. Diesen Part übernimmt Kubernetes, indem es auf Prozessebene die laufenden Container überwacht und sie je nach konfigurierter Policy gegebenenfalls neu startet. Darüber hinaus ruft Kubernetes zur Erkennung von dysfunktionalen Prozessen regelmäßig die sogenannten Health Checks auf. Diese Requests werden ebenfalls durch das Sidecar geleitet, wodurch diese Services indirekt funktional überwacht werden. Im Fehlerfall wird ein Restart eines neuen Pods veranlasst, in dem auch wieder das Sidecar aktiviert ist.

Distributed Tracing

Kommt es in verteilten Systemen zu Problemen, ist es oft schwierig, die zugrunde liegende Ursache herauszufinden. Die Fehlersuche innerhalb eines Service Mesh stellt die Entwicklung und den Betrieb regelmäßig vor große Herausforderungen. Ein Request kann auf unterschiedlichen Pfaden über mehrere Service-Aufrufe durch das Mesh traversieren. Dabei können Probleme an unterschiedlichen Stellen auftreten, wobei sich die Ursachenforschung insbesondere für Timeouts und Latenzprobleme ohne entsprechende Unterstützung sehr schwierig gestaltet. Auch das Aufspüren von Fehlerkaskaden ist ohne ein geeignetes Werkzeug kaum zu bewerkstelligen. Istio verwendet hierzu Distributed-Tracing-Tools wie beispielsweise Zipkin oder auch Jaeger. Dazu sammelt Istio über das Sidecar alle notwendigen Informationen und übermittelt diese an das konfigurierte Tracingsystem. Konkret erfolgt das über spezielle Tracingheader (x-request-id und x-b3-traceid), die über die gesamte Request-Kette von Service zu Service weitergeleitet werden müssen. Dieser sogenannte Span kann dann mittels Zipkin- oder Jaeger-GUI angezeigt werden (Abb. 5.1).

image

Abbildung 5.1: Der Span lässt sich via Jaeger GUI anzeigen

In der Beispielanwendung Bookstore ist das Weiterleiten der Headerparameter für den Span von Hand implementiert worden. Diese Implemetierung sollte jedoch von einem Framework transparent für den Entwickler übernommen werden. Zum Beispiel werden in einer auf MicroProfile basierenden Applikation diese Headerdaten automatisch verwaltet, sobald in der Anwendung das MicroProfile OpenTracing aktiviert worden ist. Somit wird der Entwickler durch das Zusammenspiel von MicroProfile und Istio von dieser rein technischen Aufgabe befreit.

Fault Injection

Hat man beispielsweise über einen Ja...

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

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang