Kubernetes Logs: Typen, Befehle & 6 Best Practices

Was ist Kubernetes-Logging?

In Kubernetes sind Logs das wichtigste Mittel, um Anwendungsverhalten zu beobachten und Cluster-Probleme zu analysieren. Da Pods kurzlebig sind, erfasst Kubernetes die stdout- und stderr-Streams der Container und legt sie als temporäre Dateien auf dem Node ab.

Logging-Architektur:

Kubernetes bietet keine native Lösung für die persistente Speicherung von Logs, sondern stützt sich auf drei zentrale Architekturmuster:

• Node-Level-Logging: Die Container-Runtime erfasst die Standardausgabe und speichert sie unter /var/log/pods/ auf dem Host-Node.
• Sidecar-Container für Log-Forwarding: Ein zweiter Container innerhalb des Pods sammelt die Logs der Anwendung und leitet sie an seinen eigenen stdout-Stream oder direkt an ein Logging-Backend weiter.
• Cluster-Level-Logging: Ein spezialisierter Agent (z. B. Fluentd, Fluent Bit oder Filebeat) läuft als DaemonSet auf jedem Node. Er sammelt lokale Logdateien und leitet sie an ein zentrales Speichersystem wie Elasticsearch, Grafana Loki oder cloud-spezifische Dienste wie AWS CloudWatch, Google Cloud Logging (von GKE genutzt) oder Azure Monitor weiter.

Arten von Kubernetes-Logs – jede wird weiter unten ausführlich erläutert:

• Application Logs: Der häufigste Typ, erzeugt vom Code, der in Ihren Pods läuft.
• System Component Logs: Werden von zentralen Kubernetes-Diensten wie API-Server, Scheduler und Kubelet erzeugt.
• Audit Logs: Aufzeichnungen jedes Aufrufs an den Kubernetes-API-Server, primär für Sicherheit und Compliance.
• Events: Streng genommen keine Logs, sondern Aufzeichnungen mit Zeitstempel zu Statusänderungen im Cluster (z. B. ein Pod, der nicht startet), abrufbar über kubectl get events.

In diesem Artikel:

• Die Kubernetes-Logging-Architektur verstehen
• Arten von Kubernetes-Logs
• Wichtige kubectl-logs-Befehle
• Gängige Anwendungsfälle für Kubernetes-Logging
• Best Practices für Kubernetes-Logging

Die Kubernetes-Logging-Architektur verstehen

Node-Level-Logging

Node-Level-Logging in Kubernetes bezeichnet die Erfassung von Logs direkt auf der Host-Maschine, auf der die Container-Runtime die Logs aller dort laufenden Container ablegt. Standardmäßig nutzen Kubernetes-Nodes den Logging-Mechanismus der Container-Runtime, etwa den JSON-Logging-Driver von Docker. Dieser schreibt die stdout- und stderr-Streams jedes Containers in Logdateien an einem Standardpfad, beispielsweise /var/log/containers/.

Vorteile:

• Dieser Ansatz stellt sicher, dass Logs auch dann auf dem Node erhalten bleiben, wenn ein Container nur kurz lebt oder abstürzt.
• Er bietet eine lokale Quelle für die Fehleranalyse.

Einschränkungen:

• Sich ausschließlich auf Node-Level-Logging zu verlassen, ist nicht ratsam.
• Werden Nodes gelöscht oder Logs rotiert bzw. bereinigt, können Daten verloren gehen.
• Node-Level-Logs bleiben isoliert, was es erschwert, Ereignisse über mehrere Nodes hinweg zu korrelieren oder Logs zentral auszuwerten.
• Node-Level-Logging bietet keine Sichtbarkeit über einen einzelnen Node hinaus – es beantwortet weder Fragen zum Gesundheitszustand von Workloads im gesamten Cluster, noch zeigt es Ressourcentrends über die Zeit oder den Zusammenhang zwischen einem Log-Ereignis und einem CPU-Peak auf einem anderen Node.

In Produktionsumgebungen ergänzen Unternehmen Node-Level-Logging in der Regel durch clusterweite Lösungen, die Logs einsammeln und zur Aufbewahrung, Suche und Analyse an externe Systeme exportieren.

Sidecar-Container für Log-Forwarding

Sidecar-Container sind ein Architekturmuster in Kubernetes, bei dem ein zusätzlicher Container neben dem eigentlichen Anwendungscontainer im selben Pod läuft. Im Logging-Kontext ist die Aufgabe des Sidecars konkret das Log-Forwarding: Er liest Logdateien oder Streams, die der Hauptcontainer der Anwendung erzeugt, und sendet sie an ein externes Logging-Backend. Das ist etwas anderes, als Logs einfach aus einem Sidecar-Container heraus zu schreiben – das könnte schließlich jeder beliebige Container. Dieses Design trennt die Logging-Logik vom Anwendungscode und erlaubt Teams, die Logsammlung über Workloads hinweg zu standardisieren.

Vorteile:

• Sidecar-Container für Logging bieten Flexibilität und Konsistenz.
• Der Sidecar kann Aufgaben wie Logrotation, Formatierung, Anreicherung mit Metadaten und die sichere Übertragung an einen zentralen Logspeicher übernehmen.
• Dieser Ansatz ist nützlich, wenn Anwendungen kein strukturiertes Logging nativ unterstützen oder wenn Logs an mehrere Ziele gesendet werden sollen.

Einschränkungen:

• Es entsteht zusätzlicher Ressourcen- und Betriebsaufwand.
• Jeder Pod muss mit seinen Sidecar-Containern konfiguriert und deren Lebenszyklus verwaltet werden.
• Das Sidecar-Muster adressiert die Logsammlung, nicht die Loganalyse. Selbst bei perfekt weitergeleiteten Logs braucht es weiterhin zusätzliches Tooling, um das Geschehen in einem Container mit Ereignissen auf Clusterebene – Scheduling-Entscheidungen, Ressourcendruck, Node-Zuständen – in Bezug zu setzen.

Cluster-Level-Logging

Cluster-Level-Logging aggregiert Logs aller Nodes, Pods und Komponenten eines Kubernetes-Clusters und exportiert sie in ein zentrales System. Üblicherweise werden dafür Log-Sammel-Agents wie Fluentd, Logstash oder Filebeat als DaemonSets ausgerollt, die auf jedem Node laufen und Logs aus Container-Logdateien oder dem journald-System einsammeln. Die gesammelten Logs werden anschließend an externe Plattformen wie Elasticsearch, Splunk oder cloudbasierte Logging-Dienste zur Speicherung, Indexierung und Abfrage weitergeleitet.

Dieses Muster setzen managed Kubernetes-Dienste standardmäßig um. Auf GKE ist Google Cloud Logging (ehemals Stackdriver) ab Werk aktiv und stellt einen auf Fluent Bit basierenden Agent als DaemonSet bereit, der Logs an Cloud Logging sendet. Auf EKS bietet AWS ein ähnliches Setup über das Add-on "AWS for Fluent Bit", das an CloudWatch Logs weiterleitet. Wenn Sie einen managed Kubernetes-Dienst nutzen, setzen Sie mit ziemlicher Sicherheit bereits Cluster-Level-Logging ein – die Frage ist, wie konsequent Sie es nutzen.

Vorteile:

• Cluster-Level-Logging adressiert die Herausforderungen kurzlebiger Nodes und Pods, indem Logs auch bei Reschedulings von Workloads oder Infrastrukturänderungen erhalten bleiben.
• Es ermöglicht Suche, Korrelation und Analysen über alle Cluster-Komponenten hinweg und erleichtert so das Monitoring der Anwendungsgesundheit, das Debugging von Incidents und die Erfüllung von Compliance-Anforderungen.
• Cluster-Level-Logging gilt als Best Practice für produktive Kubernetes-Umgebungen, weil es eine skalierbare Grundlage für Observability schafft.

Einschränkungen:

• Auch mit Cluster-Level-Logging erzählen Logs allein nicht die ganze Geschichte. Sie erfassen, was eine Anwendung gemeldet hat – aber nicht, warum ein Pod neu eingeplant wurde, ob ein Node unter Memory-Druck stand oder wie sich der Ressourcenverbrauch über die Zeit entwickelt hat. Die Korrelation von Log-Ereignissen mit Infrastrukturmetriken erfordert in der Regel zusätzliches Tooling, das über eine reine Log-Aggregationspipeline hinausgeht.

Arten von Kubernetes-Logs

1. Application Logs

Application Logs werden vom Code erzeugt, der in Containern läuft. Sie erfassen die Ausgaben von Anwendungsprozessen, etwa Informationsmeldungen, Fehler, Warnungen und Debug-Ausgaben. Entwickler greifen auf Application Logs zurück, um das Laufzeitverhalten zu verstehen, Requests nachzuverfolgen und Probleme in der Geschäftslogik oder bei Drittanbieter-Abhängigkeiten zu diagnostizieren. Application Logs werden typischerweise nach stdout und stderr geschrieben und sind dadurch für die Logging-Mechanismen von Kubernetes zugänglich.

Zu beachten:

• Das Management von Application Logs in Kubernetes bringt aufgrund der dynamischen Natur von Containern Herausforderungen mit sich. Werden Logs nicht außerhalb des Containers gesammelt und persistiert, gehen Informationen verloren, sobald Pods beendet oder neu eingeplant werden.
• Unternehmen sollten Logs in einem strukturierten Format wie JSON ausgeben und keine Logdateien innerhalb von Containern schreiben.
• Zentralisierte Logging-Lösungen können Logs zur Fehleranalyse und zum Monitoring vorhalten und durchsuchbar machen.
• Application Logs zeigen, was Ihr Code getan hat – aber nicht, warum Kubernetes den Pod beendet hat, ob der Node unter Ressourcendruck stand oder was sich zum selben Zeitpunkt im Cluster verändert hat. Für eine Root-Cause-Analyse sind Application Logs ein Ausgangspunkt, nicht das vollständige Bild.

2. System Component Logs

System Component Logs werden von der Kerninfrastruktur eines Kubernetes-Clusters erzeugt. Dazu zählen Logs von kubelet, kube-apiserver, kube-controller-manager, kube-scheduler und der Container-Runtime. Sie geben Einblick in den Betrieb der Kubernetes-Control-Plane und der Node-Agents und erfassen Ereignisse wie Scheduling-Entscheidungen, Health-Checks, Authentifizierungsversuche und Fehlerzustände innerhalb der Plattform.

Zu beachten:

• Zugriff auf und Analyse von System Component Logs sind für Cluster-Betreiber und Administratoren entscheidend.
• Diese Logs liegen je nach Cluster-Setup häufig auf dem Host-Dateisystem oder werden über systemd journald abgerufen.
• Werden System Component Logs gemeinsam mit Application Logs zentralisiert, lassen sich Ereignisse auf Infrastrukturebene mit Anwendungsproblemen in Bezug setzen – die Basis für Root-Cause-Analysen und proaktives Monitoring der Kubernetes-Umgebung.
• Bei managed Services wie GKE und EKS sind die meisten Logs der Control-Plane-Komponenten über die Logging-Plattform des Cloud-Anbieters verfügbar – GKE liefert kube-apiserver-, kube-scheduler- und controller-manager-Logs direkt in Cloud Logging. Damit entfällt der direkte Dateisystemzugriff als Sorge, nicht aber die Notwendigkeit, diese Logs aktiv zu überwachen und auszuwerten.

3. Audit Logs

Audit Logs in Kubernetes protokollieren alle Anfragen an den API-Server und halten fest, wer wann und von wo aus welche Aktion ausgeführt hat. Sie unterstützen Sicherheit, Compliance und forensische Untersuchungen, da sie einen manipulationssicheren Nachweis von Benutzer- und Systemaktivitäten liefern. Audit-Logging ist in Kubernetes konfigurierbar, sodass Administratoren über Policies festlegen können, welche Ereignisse in welchem Detailgrad protokolliert und wie lange Audit-Daten aufbewahrt werden.

Zu beachten:

• Audit Logs unterscheiden sich von Application und System Logs dadurch, dass sie sich auf API-Interaktionen und Zugriffskontroll-Ereignisse konzentrieren.
• Sie helfen, unautorisierte Zugriffe zu erkennen, sensible Vorgänge zu überwachen und regulatorische Compliance nachzuweisen.
• Empfohlene Praxis ist, Audit Logs in sicherem, unveränderlichem Speicher aufzubewahren und in SIEM- oder Security-Analytics-Plattformen zu integrieren, um die Sicherheit in Kubernetes-Umgebungen zu gewährleisten.
• Auf GKE werden Audit Logs über Cloud Audit Logs verwaltet und sind für Admin-Aktivitäten standardmäßig aktiv. Auf EKS erfasst CloudTrail die Aktivitäten des API-Servers. In beiden Fällen übernimmt der Anbieter die Sammlung – Analyse, Alerting und Aufbewahrungsrichtlinien erfordern jedoch weiterhin eine bewusste Konfiguration.

Events

Kubernetes-Events sind Aufzeichnungen mit Zeitstempel zu relevanten Vorgängen innerhalb des Clusters, etwa Pod-Erstellungen, Scheduling-Fehlern, Neustarts oder Verstößen gegen Ressourcenquoten. Events sind keine klassischen Logs, sondern dienen als Benachrichtigungen, die helfen, Statusübergänge und Lebenszyklusänderungen von Kubernetes-Objekten zu verstehen. Sie lassen sich über kubectl get events einsehen und sind nützlich für Echtzeit-Debugging und operative Sichtbarkeit.

Zu beachten:

• Events sind kurzlebig und werden im Kubernetes-API-Server typischerweise nur kurz vorgehalten; der Standardwert liegt bei einer Stunde.
• Sie liefern zwar Kontext für die Fehleranalyse, sollten aber nicht als alleinige Quelle für Audit- oder Diagnoseinformationen dienen.
• Für umfassendere Sichtbarkeit sollten Events gesammelt und in externe Monitoring- oder Logging-Systeme exportiert werden, wo sie sich mit Application und System Logs in Beziehung setzen lassen.

Wichtige kubectl-logs-Befehle

Der Befehl kubectl logs ist das Standardwerkzeug, um Containerlogs aus dem Terminal abzurufen.

Pod-Logs anzeigen

Der Befehl kubectl logs ist die primäre Methode, um Logs eines Pods in Kubernetes anzuzeigen. Er ruft die Logs aus den stdout- und stderr-Streams des Containers ab und erlaubt Betreibern und Entwicklern, das Anwendungsverhalten über die Kommandozeile zu prüfen. Die einfachste Verwendung lautet:

kubectl logs <pod-name>

Dieser Befehl zeigt die Logs des Standardcontainers im angegebenen Pod an. Enthält der Pod nur einen Container, wählt Kubernetes ihn automatisch aus. Pod-Logs einzusehen ist hilfreich, um Anwendungsfehler, Startprobleme oder unerwartetes Verhalten zu untersuchen, ohne direkten Zugriff auf den Node zu benötigen, auf dem der Container läuft.

Logs verfolgen/streamen

Kubernetes unterstützt das Live-Streaming von Logs über das Flag -f bzw. --follow. Das Verhalten entspricht dem Linux-Befehl tail -f und gibt neue Logeinträge kontinuierlich aus, sobald der Container sie erzeugt.

kubectl logs -f <pod-name>

Log-Streaming ist nützlich bei Debugging-Sessions oder beim Beobachten von Deployments und Anwendungsstarts. Es erlaubt Betreibern, Live-Ereignisse mitzuverfolgen, Fehler zu erkennen und zu prüfen, ob Anwendungen nach Konfigurations- oder Codeänderungen korrekt arbeiten.

Logs eines bestimmten Containers

Enthält ein Pod mehrere Container, verlangt Kubernetes den Containernamen, um die richtigen Logs anzeigen zu können. Das ist häufig bei Pods mit Sidecar-Containern für Logging, Proxies oder Monitoring-Agents der Fall.

kubectl logs <pod-name> -c <container-name>

Das Flag -c gibt den Zielcontainer innerhalb des Pods an. Ohne diese Option kann Kubernetes einen Fehler zurückgeben, sobald mehrere Container existieren. Dieser Befehl hilft, die Logs einer bestimmten Komponente in Multi-Container-Pod-Architekturen zu isolieren.

Logs eines abgestürzten/vorherigen Pods

Kubernetes kann Logs eines zuvor beendeten Containers über das Flag --previous abrufen. Das ist nützlich, wenn Container abstürzen und neu starten, bevor Administratoren die ursprünglichen Logs einsehen konnten.

kubectl logs --previous <pod-name>

Bei Pods mit mehreren Containern lässt sich der Containername zusätzlich mit -c angeben. Der Zugriff auf vorherige Logs hilft, Crash-Loops, Startfehler und temporäre Anwendungsfehler zu diagnostizieren, die in der aktuellen Containerinstanz möglicherweise nicht mehr sichtbar sind.

Ausgabe begrenzen

Große Logdateien sind schwer zu analysieren – daher bietet Kubernetes Optionen, um die Menge der zurückgegebenen Ausgabe zu begrenzen. Das Flag --tail zeigt nur die jüngsten Logzeilen an.

kubectl logs --tail=100 <pod-name>

Dieser Befehl gibt die letzten 100 Logzeilen zurück und hilft, sich auf aktuelle Ereignisse zu konzentrieren, ohne durch eine übermäßige Ausgabe scrollen zu müssen.

Nach Zeit filtern

Kubernetes erlaubt das Filtern von Logs nach Zeit über die Flags --since und --since-time. Diese Optionen helfen, die Logausgabe bei Incident-Analysen auf ein relevantes Zeitfenster einzugrenzen.

kubectl logs --since=1h <pod-name>

Das Beispiel oben liefert Logs der letzten Stunde. Kubernetes unterstützt auch exakte Zeitstempel:

kubectl logs --since-time=2026-05-28T10:00:00Z <pod-name>

Die zeitbasierte Filterung ist nützlich, um Logs mit Deployments, Ausfällen oder Alerts in Beziehung zu setzen.