Erweiterte Fehlerbehebung: Kubernetes-Logs, Ereignisse und Metriken im Detail

Die Fehlerbehebung in Kubernetes wird einfacher, wenn Sie drei Fragen trennen: Was hat der Container gesagt, was hat die Steuerungsebene getan und was zeigen die Metriken? Logs, Ereignisse und Metriken beantworten verschiedene Teile desselben Vorfalls.

Die folgenden Beispiele zeigen, wie Sie alle drei zusammen verwenden, wenn ein Pod abstürzt, ein Image nicht gezogen werden kann, eine Workload nicht geplant werden kann oder ein Dienst gesund aussieht, aber langsam reagiert.

Kubernetes-Logs: Die Grundlage des Debuggings

Logs sind die detaillierten Aufzeichnungen darüber, was eine Anwendung oder ein Systemprozess tut. In Kubernetes werden Logs von den Containern generiert, die in Ihren Pods laufen. Sie sind oft der erste Ort, an den Sie sich wenden, wenn eine Anwendung nicht wie erwartet funktioniert.

Zugriff auf Container-Logs

Der Befehl kubectl logs ist Ihr primäres Werkzeug zum Abrufen von Logs aus Pods. Er ist vielseitig und bietet mehrere nützliche Optionen.

Logs von einem einzelnen Container in einem Pod abrufen:
```
kubectl logs <pod-name>
```
Wenn ein Pod nur einen Container hat, funktioniert dieser Befehl direkt.
Logs von einem bestimmten Container in einem Pod mit mehreren Containern abrufen:
```
kubectl logs <pod-name> -c <container-name>
```
Logs von einer vorherigen Instanz eines abgestürzten Containers anzeigen: Wenn ein Container aufgrund eines Fehlers neu gestartet wurde, können Sie seine Logs vor dem Neustart mit dem Flag --previous anzeigen:
```
kubectl logs <pod-name> --previous
```
Logs in Echtzeit verfolgen: Ähnlich wie tail -f ermöglicht das Flag -f (oder --follow) das Streamen neuer Logeinträge, sobald sie generiert werden, was für das Debuggen von Live-Problemen unschätzbar ist.
```
kubectl logs -f <pod-name> -c <container-name>
```
Logs nach Zeit filtern: Sie können angeben, wie viele Zeilen vom Ende abgerufen werden sollen (--tail) oder Logs ab einer bestimmten Dauer (--since).
```
kubectl logs <pod-name> --tail=100 # Letzte 100 Zeilen
kubectl logs <pod-name> --since=1h # Logs der letzten Stunde
```

Zentrale Logging-Lösungen

Während kubectl logs hervorragend für das sofortige Debuggen geeignet ist, ist es für die groß angelegte, langfristige Log-Verwaltung nicht praktikabel. Für Produktionsumgebungen sind zentrale Logging-Lösungen unerlässlich. Diese Lösungen umfassen typischerweise:

Log-Agenten: Ausführen eines Agenten (z. B. Fluentd, Fluent Bit, Filebeat) auf jedem Knoten, um Logs von allen Pods zu sammeln.
Log-Speicherung & Indizierung: Speichern von Logs in einem zentralen Repository (z. B. Elasticsearch, Loki, Splunk).
Log-Visualisierung & Analyse: Bereitstellen einer Oberfläche zum Durchsuchen, Filtern und Visualisieren von Logs (z. B. Kibana, Grafana, Splunk UI).

Best Practices für das Logging

Strukturiertes Logging: Geben Sie Logs in einem strukturierten Format (z. B. JSON) aus, damit sie von zentralen Logging-Systemen leicht analysiert und abgefragt werden können.
Angemessene Log-Level: Verwenden Sie verschiedene Log-Level (DEBUG, INFO, WARN, ERROR, FATAL), um Nachrichten zu kategorisieren und die Ausführlichkeit zu steuern.
Vermeiden Sie sensible Informationen: Protokollieren Sie keine sensiblen Daten (Passwörter, PII) direkt.

Kubernetes-Ereignisse: Der Geschichtenerzähler des Clusters

Kubernetes-Ereignisse sind Aufzeichnungen von Zustandsänderungen und Operationen, die innerhalb des Clusters auftreten. Sie bieten entscheidende Einblicke in das, was Kubernetes selbst tut (oder nicht tut) als Reaktion auf Ihren gewünschten Zustand. Ereignisse sind unschätzbar, um zu verstehen, warum Pods nicht geplant werden, Images nicht gezogen werden oder Volumes nicht gemountet werden.

Zugriff auf Kubernetes-Ereignisse

Clusterweite Ereignisse:

kubectl get events

Dieser Befehl zeigt alle aktuellen Ereignisse im aktuellen Namespace an. Sie können --all-namespaces hinzufügen, um Ereignisse im gesamten Cluster zu sehen.

Eine typische Ereignisausgabe sieht so aus:

LAST SEEN   TYPE      REASON      OBJECT                         MESSAGE
3m21s       Normal    Scheduled   pod/my-app-789c6f66-abcde      Successfully assigned default/my-app-789c6f66-abcde to node01
3m20s       Normal    Pulling     pod/my-app-789c6f66-abcde      Pulling image "example/my-app:1.2.3"
2m58s       Warning   BackOff     pod/my-app-789c6f66-abcde      Back-off restarting failed container app

Ereignisse für ein Objekt:
```
kubectl describe pod <pod-name>
```
Der Abschnitt Events am Ende ist oft der schnellste Weg, um Planungs-, Pull-, Mount- und Neustartprobleme für einen einzelnen Pod zu sehen.

Ereignisse nach Erstellungszeit sortieren:

kubectl get events --sort-by=.metadata.creationTimestamp

Was Ereignisse Ihnen normalerweise sagen

Ereignisse sind kurzlebige Aufzeichnungen, daher eignen sie sich am besten für aktuelle Fehler. Achten Sie auf diese häufigen Gründe:

FailedScheduling: Der Scheduler konnte den Pod nicht platzieren. Überprüfen Sie Knotenselektoren, Taints, Toleranzen, Ressourcenanfragen und verfügbare Kapazität.
ImagePullBackOff oder ErrImagePull: Kubernetes konnte das Image nicht ziehen. Überprüfen Sie den Image-Namen, das Tag, den Registry-Zugriff und das Image-Pull-Secret.
FailedMount: Ein Volume konnte nicht gemountet werden. Überprüfen Sie PVC-Bindung, Storage-Klasse, Knotenberechtigungen und CSI-Treiber-Integrität.
BackOff: Ein Container fällt immer wieder aus. Kombinieren Sie das Ereignis mit kubectl logs --previous.

Kubernetes-Metriken: Die Ressourcenansicht

Metriken sagen Ihnen, ob der Cluster genügend CPU, Arbeitsspeicher und Kapazität für die Workload hat. Sie helfen Ihnen auch, Anwendungsfehler von Ressourcendruck zu trennen.

Schnelle Überprüfungen mit metrics-server

Wenn metrics-server installiert ist, verwenden Sie kubectl top:

kubectl top nodes
kubectl top pods
kubectl top pod <pod-name> --containers

Hoher Pod-Speicher nahe dem Container-Limit korreliert oft mit OOMKilled-Neustarts. Hohe Knoten-CPU kann Latenz erklären, selbst wenn die Pod-Logs sauber aussehen.

Tiefere Metriken mit Prometheus

In der Produktion bieten Prometheus und Grafana normalerweise die historische Ansicht, die kubectl top vermissen lässt. Nützliche Signale umfassen:

Container-Neustarts im Zeitverlauf.
CPU-Drosselung für Container mit niedrigen CPU-Limits.
Memory Working Set im Vergleich zu Limits.
Ausstehende Pods nach Namespace.
API-Server-Anforderungslatenz und Fehlerrate.
Knoten-Festplattendruck, Speicherdruck und Netzwerksättigung.

Korrelation von Logs, Ereignissen und Metriken

Verwenden Sie ein Zeitfenster und bewegen Sie sich vom Symptom zur Ursache:

Pod-Status prüfen:

kubectl get pod <pod-name> -o wide
kubectl describe pod <pod-name>

Aktuelle und vorherige Logs lesen:

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

Aktuelle Namespace-Ereignisse prüfen:

kubectl get events --sort-by=.metadata.creationTimestamp

Ressourcennutzung vergleichen:

kubectl top pod <pod-name> --containers
kubectl top node

Zum Beispiel deutet ein Pod mit CrashLoopBackOff, vorherigen Logs, die mit einem Out-of-Memory-Fehler enden, und Metriken, die Speicher nahe dem Limit anzeigen, auf ein Speicherlimit oder ein Anwendungsspeicherproblem hin. Ein Pod, der mit FailedScheduling-Ereignissen und geringer Knotenkapazität in Pending steckt, deutet auf Planungsdruck hin, nicht auf einen Containerfehler.

Fazit

Debuggen Sie Kubernetes nicht mit nur einem Signal. Logs erklären das Anwendungsverhalten, Ereignisse erklären Entscheidungen der Steuerungsebene und Metriken erklären Ressourcendruck. Wenn Sie sie nach Zeit und Objektnamen ausrichten, werden Grundursachen viel leichter von Symptomen zu unterscheiden sein.