Service Mesh - Eine kleine Einführung

In einer normalen Infrastruktur mit mehreren (Micro-) Services läuft die gesamte Netzwerk-Kommunikation in der Regel direkt über die einzelnen Applikationen. Die hat zur folge, dass ein genauer Einblick in den Traffic nicht möglich ist. Hierzu müsste man jede einzelne Anwendung in seiner Infrastruktur anpassen und mit Monitoringlösungen ausstatten.

Bei dem Einsatz eines Service Meshes ist dieses nicht mehr erforderlich. Hierbei wird für jede laufende Applikation ein eigener Proxy gestartet. Der gesamte Traffic läuft nun über diesen Proxy und kann so analysiert werden. 

Diese Daten (Request Volumen, Timings, Success/Error Rates, etc.) landen nun in einem zentralen Monitoring. Bei Linkerd ist dies das Linkerd Dashboard sowie Grafana+Prometheus. 

Weiterhin ist es möglich, innerhalb des Proxys den Traffic umzuleiten. Somit ergeben sich viele weitere Funktionen für ein Service Mesh. Schauen wir uns daher die Funktionen einmal genauer an.

Ein Service Mesh besteht generell aus unterschiedlichen Komponenten. Im Vergleich zu z.B. Istio und Envoy ist Linkerd eher schlank. Trotzdem haben wir innerhalb von Linkerd alle Funktionen, die man im täglichen Einsatz benötigt:

Retries und Timeouts
Hierbei geht es primär um die Funktion, einen fehlgeschlagenen Request "intern erneut auszuführen". Besonders in einer Microservice Architektur, in der ein Request potenziell über viele verschiedene Services und Komponenten geht, kann solch eine Funktion Sinnvoll sein. Sollte also eine dieser Komponenten einen temporären 500er Fehler o.Ä. erzeugen, so wird dieser Request neu versucht, ohne das gleich die ganze Anfrage fehlschlägt.

Automatic mTLS
Im Standard wird für den gesamten HTTP-Traffic mutual Transport Layer Security (mTLS) aktiviert. Somit ist die interne Kommunikation innerhalb eines Clusters verschlüsselt. Das auslesen/mitschneiden der Kommunikation ist somit nicht mehr möglich.

Telemetry und Monitoring
Durch den Einsatz von Linkerd lässt sich der gesamte Traffic bis ins kleinste Detail monitoren und überwachen. Welcher Request kommt von welcher Komponente, wie lange hat diese zum Antworten benötigt und in welche Komponente wurde der Request als nächstes gesendet? Alle diese Metriken lassen sich überwachen. Im Standard erfasst Linkerd folgende Kernmetriken:

• Messen der "Golden-Metrics" (Request Volume, Success Rate, Latency) bei HTTP-Traffic

• Bytes In / Bytes Out bei TCP-Traffic

• Auflistung der Metriken per (Kubernetes-) Service, Sender, Empfänger oder pro Route

• Erzeugung eines Topology Graphens

• Live Request Sampling

Load Balancing
Auch wenn wir innerhalb von Kubernetes bereits ein Round-Robin Loadbalancing haben, kann der Einsatz von Linkerd sinnvoll sein. Hierbei wird nicht nach Round-Robin, sondern über EWMA (exponentially weighted moving average) verteilt. Es wird also das Backend ausgewählt, welches aktuell am schnellsten ist. Somit kann sich die gesamte End-to-End Performance verbessern.

Dashboard und Grafana
Über das Linkerd Dashboard können alle Metriken und Details eingesehen werden. Zusätzlich zum momentanen Status bietet die Integration von Prometheus und Grafana eine History über die Metriken.

Distributed Tracing
Gerade in einer Microservice Architektur kann der Einsatz von Tracing Sinnvoll werden. Hierbei kann ein Request über einzelne Services und Komponenten hinweg verfolgt und getracked werden. Man erhält also eine detaillierten Einblick in den Traffic Flow.

Fault Injection
Zum testen der eigenen Infrastruktur und Services kann Linkerd so Konfiguriert werden, dass z.B. jeder zehnte Request "fehlschlägt". Die Stabilität bei Ausfall einzelner Komponenten kann so Effektiv getestet werden.

Weitere Funktionen
Neben den zuvor genannten Funktionen gibt es noch einige mehr, die aber in der Regel in jedem Service Mesh vorhanden sind. Dazu zählen z.B. High Availability, Automativ Sidecar (Proxy) Injection über die Kubernetes Admission Webhooks, Ingress Integration sowie Traffic Splitting. Alle Funktionen sind in der offiziellen Dokumentation zu finden.

Die Installation der CLI für Linkerd kann über ein einfaches Script gestartet werden:

curl -sL https://run.linkerd.io/install | sh

Anschließend kann über folgendes Kommando getestet werden, ob die Installation erfolgreich war:

linkerd version

Um nun die Installation von Linkerd innerhalb des Clusters zu starten, kann der linkerd install Command verwendet werden:

linkerd install | kubectl apply -f -

Da hierbei einige Deployments angelegt werden, kann die Installation durchaus ein paar Minuten in Ansrpuch nehmen. In meinem Minikube Testcluster war diese nach ca. 10 Minuten fertig. Alle Komponenten werden im Namespace linkerd Installiert.

Hinweis zu Minikube
Solltet ihr das ganze über Minikube testen wollen, so achtet darauf, zuvor Minikube nicht mit den Standard 2 GB Memory zu starten, sondern wählt idealerweise 4 oder mehr GB. Durch die Installation der einzelner Komponenten, gerade Prometheus, kann schnell das Memory Limit des Minikube-Clusters erreicht werden. Um Minikube mit mehr Memory zu starten, gebt beim starten den Parameter 
--memory='4000mb' mit an.

Nachdem alles fertig installiert ist, lässt sich das Linkerd Dashboard über den folgenden Befehl starten:

linkerd dashboard &

Nachdem ihr euch einen Überblick über das Dashboard gemacht habt, könnt ihr sehen, dass alle internen Linkerd Komponenten bereits über das Service Mesh verfügen. Sofern ihr eure eigenen Deployments nun auch über Linkerd verwalten wollt, müssen diese nun mit dem Sidecar Proxy ausgestattet werden. Dieses kann entweder über die Konfigurierte Proxy Injection oder manuell geschehen:

cat deployment.yml | linkerd inject - | kubectl apply -f -

Damit wird euer Deployment mit dem Sidecar Proxy gestartet und ist somit komplett innerhalb von Linkerd nutzbar.

Sollte das Thema generell für euch Interessant sein, solltet ihr unbedingt das offizielle Tutorial auf der Website testen. Hierbei ist vor allem Interessant, dass ihr mit der Demo-Applikation alle Features von Linkerd testen könnt, ohne erst eure eigenen Anwendungen umbauen zu müssen. Das Tutorial und die Tasks findet ihr hier.

Über Linkerd könnt ihr das komplette Networking in eurem Cluster bis ins kleinste Detail an eure Wünsche ausrichten. Ihr bekommt ein detailliertes Monitoring und zahlreiche weitere mehr oder weniger relevante Funktionen für eure Applikationen und Komponenten.

Ich persönlich würde ein Service Mesh aber nicht in jedem Fall einsetzen, sodern immer auch die eigene Applikation betrachten. Brauche ich detailliertes Monitoring? Habe ich "einfache" Request-Response Anwendungen (bei denen das normale Prometheus/Grafana Monitoring ausreichen würde) mit einem Deployment oder komplexe Ketten von mehreren Services, die ineinander greifen (Thema Microservices)? Benötige ich eine interne mTLS Verschlüsselung des Traffics? Alle diese Punkte sollten betrachtet und bewertet werden.

 Habt ihr Fragen zum Thema Service Mesh? Meldet euch gerne bei mir.