Seite 4: Observability

Inhaltsverzeichnis

Wie oben beschrieben, erfolgt nun die Kommunikation über die Proxies. Diese können nun mitloggen, wie viele Requests über sie erfolgen, welche Latenz vorliegt und wie viele Bytes transferiert werden. Diese Daten liefern die Proxies an den Mixer, der sie in einer Prometheus-Datenbank speichert. Istio bietet einige Grafana-Dashboards an, die einen Überblick über den Traffic geben können.

Ebenso ermöglicht es die Nachverfolgung der Aufrufe durch das Mesh. In einem Monolithen nimmt man dafür gerne einen Profiler und lässt sich den Call-Graph anzeigen. Die Funktionen in Istio entsprechen einem verteilten Profiler, auch bekannt als Distributed Tracing. Schön ist dabei, dass die Plattform das Tracing fast direkt bereitstellt. Damit ist es nicht notwendig, die Anwendung zu modifizieren. Die Runtime muss allerdings, wie im Artikel beschrieben, die Tracing-Header weiterleiten, damit das Tracing von Ende zu Ende funktioniert. Es ist aber möglich, in der Anwendung zusätzliche Trace-Informationen zur Verfügung zu stellen, die man in die Traces von Istio einbaut.

Da Routinginformationen dynamisch sein können, lässt sich allein durch die Konfiguration nicht immer nachvollziehen, welchen Weg ein Aufruf genommen hat, und wo welche Latenz aufgetreten ist. Istio bietet, wie auch bei den Metriken, keinen eigenen Server für die Verarbeitung der Tracing-Daten, sondern erlaubt es, Daten im Zipkin- oder Jaeger-Format an die entsprechenden Systeme zu senden.

Und was tut nun das Mesh?

Die Stärke eines Service-Mesh ist zugleich seine größte Schwachstelle: Die hohe Flexibilität und Fülle an Aufgaben führt zu einer erhöhten Komplexität in der Konfiguration. Probleme lassen sich nicht mehr einfach in einem einzelnen Logfile finden, sondern die verteilte Natur macht es notwendig, mehrere Stellen zu observieren, um Probleme oder Flaschenhälse zu erkennen. Das bereits genannte Tracing und die Metriken können helfen, allerdings ist das nicht genug. Ein Werkzeug wie Kiali kann weiterhelfen, da es die vorhandenen Daten zusammenfasst, die Topolologie des Meshes visualisiert und Fehler direkt in der Topologie darstellt.

Wo Sonne ist, ist auch Schatten

Istio 1.0 wurde am 31. Juli 2018 freigegeben. Das Entwicklerteam bezeichnet die Version als "reif für die Produktion". Jakub Pavlik hat diese Aussage einem Härtetest unterzogen und listet einige Probleme auf. Manche davon sind sicherlich für viele Anwendungsfälle weniger problematisch (zum Beispiel dass die Möglichkeit, mehrere Kubernetes-Cluster zu überspannen, eher rudimentär ist).

Andere Kritikpunkte sind schwerwiegender, allen voran die 51 neuen API-Objekte, die für die Konfiguration zur Verfügung stehen. Natürlich erlauben sie eine ungeahnte Flexibilität, aber zum Preis einer hohen Komplexität und initial hohen Lernaufwands. Es steht zu erwarten, dass Werkzeuge wie Kiali in Zukunft mit Wizards und anderen grafischen Elementen beim Erstellen und der Pflege der Konfigurationen helfen werden.

Auch ist man gewohnt, dass Kubernetes-Health-Checks via HTTP auf spezielle Endpunkte im (Applikations-)Container zugreifen, um zu überprüfen, ob die Anwendung gesund ist oder neu gestartet werden muss. Nutzt man Istio mit TLS zwischen den Pods, funktioniert das nicht mehr, da das Kubelet, das diese Checks durchführt, nicht Teil des Meshes ist und damit auch nicht am mTLS teilnimmt.

Ein Health Check via TCP/http ist nicht möglich. Kubernetes kann auch Skripte ausführen und deren Return-Code auswerten. Dafür muss man aktuell auf einen anderen Mechanismus zurückgreifen. Der Container muss ein Skript/Programm zur Verfügung stellen, dessen Aufruf die Information über den Gesundheitszustand der eigentlichen Applikation im Container gibt. Kubernetes ruft dann regelmäßig das Programm im Ziel-Container auf und wertet den Exit-Code aus. Das zieht leider eine erhöhte Last im Anwendungscontainern nach sich.

Und zu guter Letzt erkauft man sich die Leistungsfähigkeit von Istio durch einen erhöhten Einsatz von Ressourcen. Zum einen fügt jeder Proxy in der Kette etwas Latenz hinzu. Zum Anderen benötigt er zusätzliche CPUs und Speicherplatz. In der Praxis werden die letzten Punkte sicherlich davon aufgewogen, dass die Applikation die von Istio mitgebrachten Funktionen nicht benötigt und dadurch schlanker wird.