Michael Hofmann Selbstständig

Der Schwerpunkt von Istio liegt ganz eindeutig in der Verwaltung und Konfiguration von Service Meshes.

Markus Lackner Selbstständig

In Kombination mit beispielsweise MicroProfile befreit Istio die Anwendungen von dem sonst oft notwendigen technischen Boilerplate-Code.

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 ersten Teil dieser Artikelserie zu Istio 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.

Den vollständigen Artikel lesen Sie in der Ausgabe:

Java Magazin 9.18 - "Jakarta EE"

Alle Infos zum Heft
579851297Verwaltung Cloud-nativer Microservices mit Istio
X
- Gib Deinen Standort ein -
- or -