kubectl logs und describe meistern für effizientes Pod-Debugging
Das Debugging von Anwendungen in einer verteilten Umgebung wie Kubernetes kann eine Herausforderung sein. Wenn ein Pod nicht startet, in eine Neustartschleife gerät oder unerwartetes Verhalten zeigt, sind die beiden wichtigsten Werkzeuge im Arsenal eines Kubernetes-Operators kubectl describe und kubectl logs.
Diese Befehle bieten unterschiedliche, aber sich ergänzende Einblicke in den Status und die Historie eines Kubernetes-Pods. kubectl describe liefert Metadaten, Status, Umgebungsvariablen und, entscheidend, eine Historie von System-Ereignissen des Pods. kubectl logs stellt die Standardausgabe (stdout) und Standardfehlerausgabe (stderr) bereit, die von der containerisierten Anwendung selbst generiert werden.
Die Beherrschung der Flags und Techniken, die mit diesen Befehlen verbunden sind, ist unerlässlich, um Probleme schnell zu diagnostizieren und zu beheben, wodurch die Effizienz Ihrer gesamten Cluster-Fehlerbehebung erheblich verbessert wird.
Der dreistufige Pod-Debugging-Workflow
Bevor wir in die Befehle eintauchen, ist es hilfreich, den typischen Debugging-Workflow zu verstehen:
- Status prüfen: Verwenden Sie
kubectl get pods, um den Fehlerzustand zu identifizieren (Pending,CrashLoopBackOff,ImagePullBackOff, etc.). - Kontext und Ereignisse abrufen: Verwenden Sie
kubectl describe pod, um zu verstehen, warum der Statuswechsel aufgetreten ist (z. B. Scheduler fehlgeschlagen, Liveness-Probe fehlgeschlagen, Volume konnte nicht gemountet werden). - Anwendungsausgabe prüfen: Verwenden Sie
kubectl logs, um das Laufzeitverhalten der Anwendung zu untersuchen (z. B. Konfigurationsfehler, Datenbankverbindungsfehler, Stack-Traces).
1. kubectl describe: Das System-Triage-Tool
kubectl describe ist der erste Befehl, den Sie ausführen sollten, wenn sich ein Pod schlecht verhält. Er zeigt keine Anwendungsausgabe an, liefert aber die entscheidenden Metadaten und die Historie, die Kubernetes selbst über den Pod aufgezeichnet hat.
Grundlegende Verwendung
Die grundlegende Verwendung erfordert lediglich den Pod-Namen:
kubectl describe pod my-failing-app-xyz789
Wichtige Abschnitte der Ausgabe
Konzentrieren Sie sich bei der Überprüfung der describe-Ausgabe auf diese wichtigen Abschnitte:
A. Status und Zustand
Sehen Sie sich das Feld Status oben an und überprüfen Sie dann die einzelnen Containerzustände innerhalb des Pods. Dies sagt Ihnen, ob der Container Running, Waiting oder Terminated ist, und gibt den Grund für diesen Zustand an.
| Feld | Häufiger Status/Grund | Bedeutung |
|---|---|---|
Status |
Pending |
Der Pod wartet auf die Zuweisung oder es fehlen Ressourcen. |
Reason |
ContainerCreating |
Die Container-Laufzeit zieht das Image oder führt die Einrichtung durch. |
State |
Waiting / Reason: CrashLoopBackOff |
Der Container startete und beendete sich wiederholt. |
State |
Terminated / Exit Code |
Der Container hat die Ausführung beendet. Exit-Codes ungleich Null weisen normalerweise auf Fehler hin. |
B. Container-Konfiguration
Dieser Abschnitt überprüft, ob Ihre Umgebungsvariablen, Ressourcenanforderungen/-limits, Volume-Mounts und Liveness-/Readiness-Probes korrekt definiert sind und mit dem von Ihnen angewendeten Manifest übereinstimmen.
C. Der Abschnitt Events (Entscheidend)
Der Events-Abschnitt, der sich am Ende der Ausgabe befindet, ist wohl der wertvollste Teil. Er bietet ein chronologisches Protokoll dessen, was die Kubernetes-Steuerungsebene mit und für den Pod getan hat, einschließlich Warnungen und Fehlern.
Häufige Fehler, die durch Events aufgedeckt werden:
- Planungsprobleme:
Warning FailedScheduling: Zeigt an, dass der Scheduler keinen geeigneten Knoten finden konnte (z. B. aufgrund von Ressourcenbeschränkungen, Node-Taints oder Affinitätsregeln). - Image-Pull-Fehler:
Warning Failed: ImagePullBackOff: Zeigt an, dass der Image-Name falsch ist, das Tag nicht existiert oder Kubernetes keine Anmeldeinformationen zum Pull aus einer privaten Registrierung hat. - Volume-Fehler:
Warning FailedAttachVolume: Zeigt Probleme beim Verbinden von externem Speicher an.
Tipp: Wenn der
Events-Abschnitt sauber ist, liegt das Problem normalerweise an der Anwendung (Laufzeitabsturz, fehlgeschlagene Initialisierung, Konfigurationsfehler) und Sie sollten als Nächsteskubectl logsverwenden.
2. kubectl logs: Anwendungsausgabe inspizieren
Wenn describe anzeigt, dass der Pod erfolgreich geplant wurde und Container versucht haben zu laufen, besteht der nächste Schritt darin, die Standardausgabestreams mit kubectl logs zu überprüfen.
Grundlegender Log-Abruf und Echtzeit-Streaming
Um die aktuellen Logs für den primären Container in einem Pod anzuzeigen:
# Alle Logs bis zum aktuellen Zeitpunkt abrufen
kubectl logs my-failing-app-xyz789
# Logs in Echtzeit streamen (nützlich zur Überwachung des Starts)
kubectl logs -f my-failing-app-xyz789
Umgang mit Multi-Container-Pods
Für Pods, die das Sidecar-Muster oder andere Multi-Container-Designs verwenden, müssen Sie angeben, welche Container-Logs Sie anzeigen möchten, indem Sie das Flag -c oder --container verwenden.
# Logs für den 'sidecar-proxy'-Container innerhalb des Pods anzeigen
kubectl logs my-multi-container-pod -c sidecar-proxy
# Logs für den Hauptanwendungs-Container streamen
kubectl logs -f my-multi-container-pod -c main-app
Debugging von neu startenden Containern (--previous)
Eines der häufigsten Debugging-Szenarien ist der Zustand CrashLoopBackOff. Wenn ein Container neu startet, zeigt kubectl logs nur die Ausgabe des aktuellen (fehlgeschlagenen) Versuchs an, der oft nur die Startnachricht vor dem Absturz enthält.
Um die Logs der vorherigen, beendeten Instanz anzuzeigen – die den tatsächlichen Fehler enthält, der zum Beenden führte – verwenden Sie das Flag --previous (-p):
# Logs der vorherigen, abgestürzten Containerinstanz anzeigen
kubectl logs my-crashloop-pod --previous
# Bei Bedarf mit Container-Spezifikation kombinieren
kubectl logs my-crashloop-pod -c worker --previous
Ausgabe begrenzen
Bei hochvolumigen Logs kann das Abrufen der gesamten Historie langsam oder überwältigend sein. Verwenden Sie --tail, um die Ausgabe auf die letzten N Zeilen zu begrenzen.
# Nur die letzten 50 Zeilen der Container-Logs anzeigen
kubectl logs my-high-traffic-app --tail=50
3. Techniken für die erweiterte Diagnose kombinieren
Effektives Debugging beinhaltet oft den schnellen Wechsel zwischen describe und spezifischen logs-Befehlen.
Fallstudie: Diagnose eines Liveness-Probe-Fehlers
Stellen Sie sich vor, ein Pod steckt im Zustand Running fest, startet aber gelegentlich neu, was zu Störungen führt.
Schritt 1: describe für die Systemansicht überprüfen.
kubectl describe pod web-server-dpl-abc
Die Ausgabe zeigt im Abschnitt Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning Unhealthy 2s kubelet, node-a01 Liveness probe failed: HTTP GET http://10.42.0.5:8080/health failed: 503 Service Unavailable
Fazit aus Schritt 1: Der Container läuft, aber die Liveness-Probe schlägt mit einem 503-Fehler fehl, was Kubernetes dazu veranlasst, den Container neu zu starten.
Schritt 2: logs für den Anwendungskontext überprüfen.
Untersuchen Sie nun, warum die Anwendung einen 503-Status zurückgibt, was ein Fehler auf Anwendungsebene ist.
kubectl logs web-server-dpl-abc --tail=200
Die Log-Ausgabe zeigt:
2023-10-26 14:01:15 ERROR Database connection failure: Timeout connecting to DB instance 192.168.1.10
Endgültiges Fazit: Der Pod startet aufgrund einer fehlgeschlagenen Liveness-Probe neu, und die Probe schlägt fehl, weil die Anwendung keine Verbindung zur Datenbank herstellen kann. Das Problem liegt in der externen Netzwerkkonfiguration oder Datenbankkonfiguration, nicht im Container selbst.
Best Practices und Warnungen
| Praxis | Befehl | Begründung |
|---|---|---|
| Immer vorherige Logs prüfen | kubectl logs --previous |
Notwendig für die Diagnose von CrashLoopBackOff. Der kritische Fehler liegt fast immer im vorherigen Lauf. |
| Container angeben | kubectl logs -c <Name> |
Vermeidet Mehrdeutigkeiten in Multi-Container-Pods und verhindert das Abrufen von Logs von unbeabsichtigten Sidecars. |
| Labels für Massenoperationen verwenden | kubectl logs -l app=frontend -f |
Ermöglicht das gleichzeitige Streamen von Logs von mehreren Pods, die einem Selektor entsprechen (nützlich für Rolling Updates). |
| Warnung: Log-Rotation | N/A | Kubernetes-Knoten führen eine Log-Rotation durch. Logs, die älter als die konfigurierte Aufbewahrungsrichtlinie des Knotens sind (oft ein paar Tage oder basierend auf der Größe), werden gelöscht und sind über kubectl logs nicht verfügbar. Verwenden Sie eine externe zentralisierte Logging-Lösung (z. B. Fluentd, Loki, Elastic Stack) für die langfristige Aufbewahrung. |
Fazit
kubectl describe und kubectl logs sind die unverzichtbaren Kernbefehle für das Debugging in Kubernetes. Indem Sie describe als Systemstatusbericht (mit Fokus auf Konfiguration, Ereignisse und Planungsfehler) und logs als Anwendungs-Ausführungsstream (mit Fokus auf Codefehler und Laufzeitverhalten) behandeln, können Sie die Ursache nahezu jeder Pod-Fehlfunktion systematisch eingrenzen und so die Mean Time To Resolution (MTTR) in Ihrem Cluster erheblich reduzieren.