Microservices-Umgebungen unter Kontrolle halten Service-Meshes mit Envoy Proxy, Istio, Consul und Linkerd

Anbieter zum Thema

Confluent Germany GmbH

Ein Service Mesh hilft zu kontrollieren, welche Microservices Daten miteinander teilen und austauschen. Wir stellen kurz die bekanntesten Service-Proxie- und -Mesh-Lösungen vor.

Ein Service Mesh hilft zu kontrollieren, welche Microservices Daten miteinander teilen und austauschen. Wir stellen kurz die bekanntesten Service-Proxie- und -Mesh-Lösungen vor.

Geht es darum, Service-Meshes in Microservices-Umgebungen zu betreiben, kommen Entwickler kaum um die bekannten Lösungen Istio, Consul, Envoy, Proxy und Linkerd herum. Die meisten Service-Meshes basieren auf Open Source-Lösungen und arbeiten natürlich ideal mit Docker und Kubernetes zusammen.

Bildergalerie

Bildergalerie mit 5 Bildern

Im folgenden Beitrag zeigen wir einige Proxies und Service-Mesh-Lösungen – und wie diese in Kubernetes eingebunden werden können. In den meisten Fällen erfolgt die Bereitstellung der Service-Meshes als Container/Pod in Kubernetes-Clustern.

Generell binden Service-Meshes ihre Funktionalität über TCP-Proxies in die Umgebung mit ein. Die Proxys werden als „Sidecar“ im Service-Mesh eingebunden und steuern den Datenverkehr zwischen den Microservices und Konponenten eines Dienstes. Dadurch erhalten Lösungen wie Istio und Linkerd die Kontrolle über das System. Istio setzt bei Proxys oft auf Envoy. Linkerd nutzt vor allem interne Funktionen für die Proxy-Funktionalität.

Envoy Proxy nutzen

Envoy Proxy ist ein quelloffener Edge- und Service-Proxy, mit dem sich Daten zu verschiedenen Diensten routen lassen. Dazu gehören Webseiten genauso wie Container oder Dateien. Auch Load Balancing ist mit Envoy Proxy möglich.

Die Konfiguration von Envoy basiert auf YAML-Definitionen. Dabei kann die Konfiguration statisch und dynamisch konfiguriert werden. Bei der Ersteinrichtung muss daher festgelegt werden, wie die Konfiguration stattfinden soll. Mit der Zeile „static_resources:“ in der YAML-Datei nutzt Envoy die statische API.

Im Rahmen der Bereitstellung von Envoy müssen auch die Listener definiert werden. Dabei handelt es sich um die IP-Adressen und Ports, an denen der Envoy Proxy auf Anfragen wartet. Envoy nutzt dazu seinen eigenen Docker-Container. Um die Konfiguration zum Beispiel auf die IP-Adresse des Docker-Containers zu setzen und damit den Port 10.000 zu nutzen, wird die YAML-Datei mit dem folgenden Inhalt gefüllt:

Wenn Daten bei Envoy eingehen, muss festgelegt sein, wie der Proxy mit den Daten umgeht. Dazu haben die verschiedenen Listener unterschiedliche Filter, mit denen Entwickler steuern, wie Envoy mit den eingehenden Daten umgehen soll. Envoy bietet bereits einige integrierte Filter, die genutzt werden können, zum Beispiel „envoy.http_connection_manager“ zum Aufbauen von HTTP-Verbindungen.

Sobald ein Filter an einem Listener passt, leitet Envoy die Daten an einen Cluster weiter. Hier arbeitet Envoy auch mit Round Robin. Eine Beispielkonfiguration ist auf GitHub zu finden. Nach der erfolgreichen Konfiguration auf Basis des verlinkten Beispiels kann der Docker-Container mit Envoy gestartet werden. Das kann mit dem folgenden Befehl erfolgen:

Istio und Kubernetes

Istio ist eines der bekanntesten Service-Meshes. Im Beitrag „9 Tipps für den Betrieb des Service-Meshes Istio“ auf Datacenter-Insider hat der Autor bereits beschrieben, wie sich Istio in solchen Umgebungen einbinden lässt.

Wer eine Testumgebung mit Kubernetes und Istio aufbauen will, kann Minikube nutzen. Auch hier ist es möglich, Istio einzubinden (https://istio.io/latest/docs/setup/platform-setup/minikube/). Um Istio zu betreiben, ist ein Kubernetes-Cluster notwendig. Istio lässt sich über Curl direkt in Kubernetes einbinden, zum Beispiel mit dem Befehl:

Istio erweitert Kubernetes mit Custom Resource Definitions (CRD), die zum Beispiel über die YAML-Datei „crds.yaml“ konfiguriert werden:

Nach der erfolgreichen Bereitstellung lassen sich die Pods von Istio über den kubectl-Befehl abfragen:

Bei SPIFFE (Secure Production Identity Framework for Everyone) handelt es sich wiederum um ein Identitäts-Framework, das vor allem in Cloud-Umgebungen oder mit Kubernetes eingesetzt wird, um Autorisierungen zu erleichtern. Da SPIFFE/SPIRE mit Envoy zusammenarbeiten kann, lässt sich auch das Open-Source-Servicenetz Istio, das wiederum mit Envoy als Datenebene zusammen aufgebaut wurde, gemeinsam verwenden.

Consul Connect – Autorisierung und Verschlüsselung mit TLS

Consul Connect spielt in Microservice-Umgebungen ebenfalls eine wichtige Rolle. Mit der Lösung können Entwickler Autorisierung und Verschlüsselung von Service-zu-Service-Verbindungen mit gegenseitiger Transport Layer Security (TLS) umsetzen. Im Zusammenhang mit Sidecar-Proxys in einer Service-Mesh-Konfiguration lassen sich damit TLS-Verbindungen für ein- und ausgehende Verbindungen herstellen.

Das Open-Source-Tool steht zum Download bereit, kann aber auch als Managed Service in der Cloud bei den Entwicklern gebucht werden. Für Entwicklungsumgebungen lässt sich Consul Connect auch kostenlos in der Cloud nutzen. Dazu sind auch keine Bezahlinformationen notwendig. Über die Entwicklungsumgebung steht Consul in wenigen Minuten über die Cloud bereit, ohne dass lokale Installationen notwendig sind. Auch eine Anbindung an AWS ist möglich.

Das oberhalb eingehängte Video zeigt die Einrichtung und wie Consul Connect als Proxie in einer Service-Mesh-Umgebung mit Microservices zum Einsatz kommen kann. Zusätzlich beschreiben die Entwickler im Video unten die Einrichtung und den Betrieb in der Dokumentation von Consul Connect.

Linkerd – Begründer der Service-Meshes

Wer sich mit der Entwicklung von Microservices, Container und Kubernetes beschäftigt, kennt die verschiedenen Tools der Cloud Native Computing Foundation (CNCF). Die CNCF ist wiederum ein Projekt der Linux Foundation. Bekannte Projekte sind zum Beispiel Kubernetes, Istio und Linkerd.

Linkerd gehört zusammen mit Istio sicherlich zu den bekanntesten Service-Meshes auf dem Markt. Istio wird vor allem durch Google und IBM weiterentwickelt, während Linkerd ein Projekt der Cloud Native Foundation ist. Linkerd 2 ist eindeutig für Kubernetes optimiert.

Wer auf eine andere Lösung zur Container-Orchestrierung setzt, nutzt eher andere Service-Mesh-Systeme als Linkerd. Wer allerdings Kubernetes nutzt, sollte sich die Möglichkeiten von Linkerd genauer anschauen. Generell ist Linkerd auch schneller installiert als Istio und einfacher in der Bedienung.

Die Installation von Linkerd besteht zunächst aus der Installation der CLI mit:

Um zu überprüfen, ob Linkerd eingebunden ist, kann im Kubernetes-Cluster mit folgendem Befehl ein Checkup der Umgebung durchgeführt werden:

Linkerd stellt eine Weboberfläche zur Verfügung, wird aber meistens über eine CLI verwaltet, die direkt in Kubernetes eingebunden ist. Die Control Plane lässt sich direkt in Kubernetes einbinden, sobald Linkerd auf dem Cluster verfügbar ist.

(ID:47931671)