Kubernetes-Logging: Grundlagen und Herausforderungen

Selbst wenn euer Team viel Erfahrung mit Logs in konventionellen Anwendungs­umgebungen hat, kommt vermutlich noch eine Menge Neues auf euch zu, wenn es um Logs in Kubernetes-Umgebungen geht.

Schließlich ist Kubernetes eine ziemlich einzig­artige Plattform. Sie hat viel mehr bewegliche Teile – und damit auch Logs – als herkömmliche Anwendungs­umgebungen. Diese Logs zu finden, zu analysieren und daraus eine Observability zu schaffen, die verwertbare Erkenntnisse liefert, ist sogar noch deutlich komplexer als das Logging bei anderen Formen verteilter Systeme und Computing-Umgebungen.

Kubernetes-Logging ist kein Hexenwerk. Aber ihr müsst euren Logging-Ansatz weiter­entwickeln, wenn es klappen soll. Hier ist ein Umdenken gefordert, und zwar sowohl bei der Erfassung und der Analyse von Logs als auch hinsichtlich der Rolle, die das Logging in eurer allgemeinen Observability-Strategie spielt.

Dieser Beitrag soll eine Orientierungs­hilfe bieten. Er deckt das Kubernetes-Logging in seinen Grundlagen ab. Es wird erklärt, warum die Erfassung von Kubernetes-Logs so knifflig ist und warum es schwierig ist, verwertbare Erkenntnisse aus all den unter­schiedlichen Typen von Logs zu ziehen, die in einer Kubernetes-Umgebung erzeugt werden. Wir erläutern auch, was ihr tun könnt, damit ihr nicht im Sumpf der Kubernetes-Logs versinkt. Ihr könnt euch nämlich das Log-Management in Kubernetes-Umgebungen leichter machen, ohne dabei die Einblicke zu verlieren, die Kubernetes-Logs in die komplexen, Cloud-nativen Umgebungen dieser Plattform ermöglichen.

Kubernetes-Logging: die Grundlagen

Auf den ersten Blick scheinen sich Kubernetes-Logs nicht groß von anderen Log-Typen zu unterscheiden. Allerdings funktionieren sie in einigen wesentlichen Aspekten anders.

Log-Typen

Zunächst einmal gibt es in Kubernetes zwei grund­legend verschiedene Log-Typen. Container und Pods, in denen Anwendungen bereit­gestellt werden, erzeugen den einen Typ. Diese Logs können euch helfen, die Performance und Zuverlässigkeit einzelner Anwendungen zu bewerten. Kubernetes selbst erzeugt den zweiten Typ. Er gewährt Einblick in den Zustand des Gesamtclusters.

Beide Kategorien umfassen wiederum viele weitere Log-Typen. Eine einzelne Anwendung erzeugt in der Regel mehrere Logs: ein Log für jede Microservice-Instanz, die als Teil der Anwendung ausgeführt wird. Auch die Logs auf Cluster-Ebene lassen sich in mehrere Kategorien unterteilen. Es gibt eigene Logs für den Master-Knoten, die Arbeits­knoten, die Kubernetes-API-Server und verschiedene weitere Kubernetes-Komponenten.

Log-Speicherorte

Da es in Kubernetes zahlreiche Log-Typen gibt, ist es kaum verwunderlich, dass diese Logs an unter­schiedlichen Orten zu finden sind. Einige davon, zum Beispiel die Knoten-Logs, sind auf den jeweiligen Servern, die einen Kubernetes-Cluster bilden, unter /var/log gespeichert und dürften der IT-Technik vertraut sein. Bei anderen, etwa den Logs, die innerhalb von Containern gespeichert sind, kann die Erfassung sich komplizierter gestalten, wenn euch der Umgang mit solchen Log-Daten nicht vertraut ist.

Events und Metriken

Der Fokus dieses Beitrags liegt zwar auf Kubernetes-Logs, allerdings sind Logs nur eine von mehreren Quellen, die in Kubernetes für Transparenz sorgen können. Kubernetes bietet darüber hinaus eine Metrik-API, über die Daten zum Cluster-Zustand und zum Ressourcen­verbrauch erfasst werden können. Sie zeichnet auch bestimmte Event-Typen auf, zum Beispiel das Beenden von Pods. Diese Informationen sind nicht alle in Kubernetes-Logs verfügbar, ihr solltet sie jedoch zusammen mit den Log-Daten erfassen und analysieren, wenn ihr End-to-End-Transparenz in Kubernetes-Umgebungen schaffen wollt.

Kubernetes-Logging: die Herausforderungen

Die soeben beschriebene Logging-Architektur von Kubernetes ist nicht sonderlich kompliziert. Dennoch wird das Logging in Kubernetes zu einer echten Heraus­forderung, weil es sich schwierig gestaltet, die unter­schiedlichen Logs in euren Anwendungen und Clustern zu erfassen und zu analysieren.

Kein zentraler Log-Speicherort

Eine grundlegende Herausforderung liegt darin, dass die Kubernetes-Logs sich auf viele unter­schiedliche Speicher­orte verteilen. Sämtliche Log-Daten eures Clusters abzurufen, indem ihr eine einzelne Log-Datei verfolgt oder einen einzigen Befehl ausführt, ist schlicht nicht möglich.

Wenn ihr die Logs stattdessen manuell erfassen wollt, müsst ihr zwischen einer Vielzahl von Speicher­orten hin- und herwechseln, die sich auf all eure einzelnen Knoten, die einzelnen Pods etc. verteilen. Befehle wie journalctl können diesen Prozess etwas vereinfachen, aber wirklich leicht wird es damit noch lange nicht.

Kein integriertes Log-Management

Noch komplexer wird die Log-Erfassung dadurch, dass Kubernetes selbst kein natives Framework zum Log-Management bietet. Kubernetes erzeugt lediglich Logs. Es bleibt den IT-Teams überlassen, herauszufinden, wie sie damit am besten umgehen.

Zwar löscht Kubernetes beispielsweise Log-Daten aus Containern, sobald die Größe der Logs 10 MB überschreitet, aber das ist eher hinderlich als hilfreich. Denn das bedeutet: Wenn diese Logs für Analysen verfügbar bleiben sollen, dann müsst ihr die Daten anderswo aggregieren, bevor Kubernetes sie überschreibt.

Unterschiedliche, veränderliche Log-Formate

Logs aus Kubernetes-Clustern und Anwendungen weisen viele unter­schiedliche Formate auf. In den meisten Clustern gibt es derzeit keine Standard­struktur oder -methode.

Kubernetes-Entwicklerinnen und -Entwickler haben sich des Problems mittlerweile angenommen und haben das Logging auf Cluster-Ebene per JSON-Formatierung standardisiert. Dies ist jedoch ein neues Feature, das erst ab Kubernetes 1.19 verfügbar ist. Außerdem betrifft es nur Cluster-Logs. Eure Anwendungs­logs kommen noch immer in einer Vielzahl von Formaten daher.

Stand der Dinge auf dieser Baustelle ist also, dass die Kubernetes-Entwicklung zwar einiges unternommen hat, um Logs konsistenter zu gestalten, dass aber der Mangel an einer gemeinsamen Struktur und Formatierung nach wie vor eine Heraus­forderung ist. Allein die Tatsache, dass Kubernetes-Logging-Standards sich immer wieder ändern, erschwert die Entwicklung von Log-Management-Strategien. Ob eine Logging-Methode, die ihr für eine bestimmte Kubernetes-Version anwendet, bei einem späteren Release ebenso gut funktionieren würde, ist schwer zu sagen.

Keine persistente Log-Speicherung

Kubernetes bietet standard­mäßig keine persistente Log-Speicherung für Anwendungs­logs. Stattdessen schreiben Pods und Container ihre Logs in ihre internen Umgebungen. Diese Logs verschwinden endgültig, wenn die Pods oder Container heruntergefahren werden.

Folglich müssen die Log-Daten der Anwendungen an einem externen, persistenten Speicher­ort aggregiert werden, damit sie weiterhin für Analysen verfügbar bleiben. Hierfür gibt es mehrere Verfahren, beispielsweise die Speicherung der Logs mithilfe sogenannter Sidecar-Container oder das direkte Streamen an einen externen Speicher­ort anstelle des lokalen Loggings in euren Containern. Allerdings: Eure Kubernetes-Architektur und die Management-Workflows werden dadurch noch komplexer.

Ein besserer Logging-Ansatz für Kubernetes

Bis hierher lässt sich sagen, dass Kubernetes-Logging eine ziemliche Tortur ist – zumindest wenn ihr versucht, die Logs von Hand zu verwalten.

Daher gehen clevere Teams anders vor. Statt jedes einzelne Log mühsam aus dem jeweiligen Pod oder Cluster zu erfassen, was bei größerer Skalierung eine extrem nervige Aufgabe ist, könnt ihr einfach ein Tool einrichten, das die Logs automatisch für euch erfasst – und zwar unabhängig vom Format und vom Speicherort in der Kubernetes-Umgebung.

Ebenso wichtig ist es, dass ihr zur Log-Analyse eine Lösung nutzt, die eure Log-Daten mit anderen Kubernetes-Observability-Quellen kombiniert, namentlich mit Metriken und Traces. Erst dann bekommt ihr vollständig kontextualisierte Daten zum Zustand eures Clusters und der darin ausgeführten Anwendungen.

Wenn ihr die Erfassung und Analyse von Kubernetes-Logs derart automatisiert, umgeht ihr leicht­füßig die Fallstricke der Log-Komplexität in diesen Umgebungen. Statt mühsam zu ermitteln, wo die einzelnen Logs gespeichert sind und wie ihr sie erfasst, bevor sie gelöscht werden, könnt ihr euch darauf konzentrieren, aus diesen Logs verwertbare Erkenntnisse zu gewinnen.

Eine solche Lösung steht mit Splunk Log Observer zur Verfügung. Splunk Log Observer erfasst automatisch Logs jeder Art von allen Komponenten eurer Kubernetes-Umgebung. Eine manuelle Aggregierung wird damit überflüssig. Durch die Integration in Splunk Infrastructure Monitoring und Kubernetes Navigator ermöglicht Splunk Log Observer außerdem die Analyse von Kubernetes-Log-Daten im Kontext mit anderen wichtigen Quellen der Kubernetes-Transparenz und schafft auf diese Weise vollständige Observability.

Das Log-Management in Kubernetes kann zwar einiges Kopf­zerbrechen bereiten, sollte euch aber nicht davon abhalten, in euren Kubernetes-Clustern für umfassende Observability zu sorgen. Überlasst die mühselige Arbeit der Log-Erfassung und -Korrelation einfach Splunk. Ihr konzentriert euch stattdessen auf die Log-Analyse und nutzt eure Erkenntnisse dazu, die Performance eurer Kubernetes-Umgebung zu optimieren.

Log Observer ist integraler Bestandteil von Splunk Observability Cloud. Damit bekommen SREs, DevOps-Fachleute und Dev-Teams jetzt leistungs­starkes Splunk-Logging mit nahtlosen, optimierten Workflows für IT-Monitoring, Trouble­shooting und Untersuchungen. Dann ist es nur mehr ein Katzen­sprung von der Problem­erkennung zur Problem­lösung. Wie sich das Trouble­shooting auf einer Logging-Oberfläche anfühlt, die all eure Metrik-, Trace- und Log-Daten zentral zusammenfasst, könnt ihr in der Demo zu Splunk Observability Cloud selbst erleben.

Was ist Splunk?

Dieser Blog-Post ist der ganz persönliche Beitrag von Splunker Stephen Watts und spiegelt nicht unbedingt die Positionen, Strategien oder Ansichten von Splunk wider. Er ist eine Neu­fassung eines ursprünglich von Bill Emmett verfassten Beitrags.

_{*Dieser Artikel wurde aus dem Englischen übersetzt und editiert. Den Originalblogpost findet ihr hier.}