© Jozsef Bagota/Shutterstock.com
Eine Infrastruktur für Microservices

Service Mesh und Istio


Die Flexibilität und die Geschwindigkeit von Microservices [1], [2] haben den hohen Preis eines verteilten Systems. Während der Betrieb dank Kubernetes kaum herausfordernd ist, müssen andere Funktionen aufwendig mit Bibliotheken implementiert und Werkzeuge für die Datenauswertung installiert werden. Ein Service Mesh wie Istio hilft, indem es viele Funktionen auf die Infrastrukturebene hebt und Analysetools mitbringt.

Es gibt sehr viele unterschiedliche Technologien für die Implementierung von Microservices-Architekturen [3], [4]. Kubernetes [5] ist gerade für den Betrieb von Microservices eine hervorragende Infrastruktur: Docker-Container laufen nicht mehr auf einzelnen Knoten, sondern im Cluster; das erlaubt Ausfallsicherheit und Skalierung. Außerdem hilft Kubernetes beim Deployment der Anwendungen. Durch Rolling Updates können neue Versionen schrittweise eingeführt werden, indem Container mit der neuen Version gestartet und dann die Container mit der alten Version entfernt werden.

Außerdem ermöglicht Kubernetes Service Discovery: Container können andere Container anhand des DNS-Namens finden. DNS dient auch im Internet zum Auflösen von Hostnamen zu IP-Adressen und hat daher eine breite Unterstützung über viele Programmiersprachen hinweg. Load Balancing löst Kubernetes ebenfalls: Die Last kann auf mehrere Instanzen verteilt werden; dabei wird der Netzwerkverkehr transparent auf IP-Ebene umgeleitet.

Aus diesen Gründen ist Kubernetes mittlerweile eine der wichtigsten Plattformen für Microservices: Ohne Eingriffe in den Code werden wichtige Herausforderungen für Microservices gelöst. So bleibt die Technologiefreiheit bestehen. Aber Kubernetes löst noch nicht alle Herausforderungen von Microservices.

Service Mesh: Proxies im Einsatz

Der Zweck von Kubernetes ist der zuverlässige Betrieb von beliebigen Containern. Der Orchestrierer bildet deshalb keine Microservice-spezifischen Funktionen ab. Genau dort setzt ein Service Mesh an. Es handelt sich um eine zusätzliche Infrastrukturebene für das Management der Service-zu-Service-Kommunikation. Anders als ein ESB ist ein Service Mesh jedoch dezentral und implementiert keine Geschäftslogik, da es typischerweise kein contentbasiertes Routing umsetzt. Ähnlich wie Kubernetes beliebige Container orchestriert, ist der Zweck eines Service Mesh, beliebige Microservices zu verwalten.

Im Detail betrachtet besteht ein Service Mesh aus zwei zusätzlichen Ebenen, die zwischen einem Orchestrierer wie Kubernetes und den Anwendungen liegen. Ein Service Mesh stellt jeder Service-Instanz einen sogenannten Sidecar-Container zur Seite. In Kubernetes wird dieser in den gleichen Pod, der Deployment-Einheit von Kubernetes, platziert. Daher laufen beide Container auf demselben physischen Host, teilen sich ein Netzwerkinterface und können sich Dateisysteme teilen. Im Sidecar-Container befindet sich ein Service Proxy, durch den jegliche eingehende und ausgehende Kommunikation verläuft. Alle Service Proxies zusammen bilden die dezentrale Data Plane (Datenebene), die nicht nur Werte wie Quelle und Ziel einer Anfrage, Latenz und Fehlercodes erfassen, sondern den Verkehr auch steuern und manipulieren kann. Die zweite Ebene, die ein Service Mesh hinzufügt, ist die Control Plane (Kontrollebene). Sie enthält zentrale Komponenten, die die Sidecar Proxies auf der Data Plane konfigurieren. Dazu gehört, wie die gesammelten Daten verarbeitet werden sollen, aber auch wie der Netzwerkverkehr auf Basis von Regeln geprüft, geändert oder gelenkt werden soll.

Istio

Der bekannteste Vertreter eines Service Mesh ist Istio [6], was auf Griechisch segeln bedeutet und sich damit in die nautische Metaphorik der Kubernetes-Infrastruktur einreiht. Auch wenn Kubernetes offensichtlich die primär unterstützte Plattform ist, ist Istio grundsätzlich auch in anderen Umgebungen einsetzbar. Das von Google, IBM und Lyft initiierte Projekt ist Open Source und basiert wie Kubernetes konzeptionell auf einem System, das Google für die interne Infrastruktur entwickelt hat und schon lange verwendet. Istio nutzt neben Kubernetes weitere etablierte Technologien wie den Service Proxy Envoy, das Monitoringtool Prometheus, das Dashboard Grafana und das Tracing-Backend Jaeger. All diese Komponenten gehören standardmäßig zu einer Istio-Installation.

Die Data Plane von Istio besteht aus Instanzen von Envoy, einem Open-Source-Service-Proxy, der von Lyft entwickelt wurde. Ein Kubernetes-Cluster kann durch Istio so konfiguriert werden, dass jeder Pod automatisch einen Sidecar-Container mit einem Envoy erhält. Wenn eine Anwendung eine Anfrage stellt, passiert diese die Envoy Proxies des Sender- und Empfänger-Pods, bevor sie den Ziel-Service erreicht. Auf diese Weise ermöglicht Istio einen konsistenten Einblick in eine Microservices-Anwendung und die lückenlose Kontrolle der Kommunikation zwischen Services (Abb. 1).

In der Control Plane wendet Pilot die Konfiguration auf die Envoy Proxies an. Bevor ein Envoy Proxy eine Anfrage an den Ziel-Service weitergibt, ruft er optional die Control Plane auf, die die Anfrage anhand von Regeln prüfen kann. Außerdem verarbeitet Mixer die durch die Envoy Proxies erfassten Daten und Citadel verwaltet die Zertifikate.

wolff_prinz_servicemesh_1.tif_fmt1.jpgAbb. 1: Istio-Architektur

Monitoring

Kubernetes allein kann zumindest Systemmetriken anbieten, zum Beispiel CPU- oder Speicherauslastung. Mit Istios Proxies ist es zusätzlich möglich, ohne Eingriffe in die Anwendung auch Metriken über die Requests zu erstellen: Anzahl, Durchsatz und Latenzzeiten gehören dazu. Istio versteht nicht nur TCP sondern auch Protokolle wie HTTP/1.1, HTTP/2 oder gRPC. So kann Istio z. B. anhand des HTTP-Statuscodes auch entscheiden, ob ein Request erfolgreich bearbeitet worden ist oder nicht.

Die Metriken kann Istio auch gl...

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