Istio: Das Service-Mesh für verteilte Systeme
Verteilte Systeme und insbesondere Microservices bieten gegenüber einem Monolithen eine höhere Flexibilität, haben aber auch zusätzliche Anforderungen.
- Heiko W. Rupp
Jeder, der schon mal ein System implementiert hat, das aus mehreren Einzelteilen besteht, kennt das Problem: Die eine Komponente muss die andere finden, sie muss auf Fehler im Kommunikationsnetzwerk reagieren und zu guter Letzt sollte die Kommunikation über das Netzwerk auch noch verschlüsselt erfolgen.
In der Java-Welt hat sich dafür der Netflix-Stack etabliert, der einige der technischen Anforderungen erfüllt. Entwickler fügen ihn jeder Anwendung hinzu, sodass sich ein Szenario wie in der nächsten Abbildung ergibt.
Allerdings ist es nun so, dass zum einen alle Dienste den Stack mitbringen und aktuell halten müssen. Zum anderen funktioniert das nur so lange gut, wie alle Dienste in Java oder anderen Umgebungen implementiert sind, für die es einen vergleichbaren Stack gibt. Populäre Sprachen wie Shell-Skripte oder Perl haben es schwer.
Das Projekt Istio geht einen anderen Weg. Jede Anwendung verfügt über ein Proxy Envoy, über den die Kommunikation erfolgt. In Umgebungen wie Kubernetes läuft er in einem eigenen Container im selben Pod wie die Anwendung. Es ist aber auch möglich, Envoy direkt als Prozess auf einer (virtuellen) Maschine laufen zu lassen, um damit eine Anwendung in das Mesh einzubinden.
Istio auf der ContainerConf
Auf der vom 13. bis 16. November stattfindenden ContainerConf in Mannheim ist das Service-Mesh Istio ebenfalls ein Thema. Sowohl in einem Vortrag des Artikelautors als auch in einem ganztägigen Workshop erfahren Teilnehmer alles, was sie über Istio wissen müssen. Bis zum 21. September ist die Anmeldung zu Frühbucherkonditionen möglich.
Die Kommunikation zwischen den Diensten erfolgt zwischen den beteiligten Proxies. In einer Anwendung müssen Entwickler die technischen Aspekte (fast) nicht mehr berücksichtigen, da der Proxy das erledigt – dazu aber später mehr. Im Moment stellt sich nur noch die Frage, wie die Proxies wissen, mit welchem anderen Proxy sie reden müssen und ob die Kommunikation verschlüsselt sein soll.
Istio bedient sich dafür einer so genannten Controlplane, die aus mehreren Komponenten besteht. Der Pilot verteilt die Konfiguration auf die Proxies, der Mixer nimmt Telemetriedaten entgegen und Citadel sorgt für die Verteilung der TLS-Zertifikate an die einzelnen Proxies. Wie vielleicht vermutet, ist nur der Pilot zwingend notwendig, Mixer und Citadel können Nutzer in einem kleinen Setup weglassen. Neben dem Kern an Diensten bietet Istio noch eigene Ingress- und Egress-Gateways für die Kommunikation mit der Welt außerhalb des Meshes. Und schließlich sorgt Galley für die Validierung der übergebenen Konfiguration. Darauf geht der Artikel später noch ein. Damit gibt sich das folgende Bild der Komponenten:
Anfragen der Nutzer gehen (idealerweise) über das Ingress-Gateway und dann zum Proxy im Ziel-Pod, in diesem Fall zu Alice. Möchte ein Dienst wie Bob ein externes System (zum Beispiel einen entfernten Webdienst) kontaktieren, kann er diesen über das Egress-Gateway ansprechen. Damit Istio die Kontrolle über den Verkehr im Netz regeln kann, ist bei der Installation in Kubernetes noch sicherzustellen, dass es keine anderen Gateways gibt, die ihrerseits eingehende Daten direkt an Services leiten und das Ingress-Gateway umgehen.
