TL;DR

kubectl logs ist der Startpunkt für jede Kubernetes-Fehlersuche. Mit den richtigen Flags (--previous, --since, -c) findest du Probleme schneller. Stern vereinfacht Multi-Pod-Tailing. Strukturiertes Logging in JSON macht Logs maschinell durchsuchbar. Dieser Guide zeigt die wichtigsten Befehle und Patterns für die tägliche Log-Analyse.

Kubernetes-Logs analysieren: Von kubectl bis Stern

Ein Pod crasht. Der erste Reflex: kubectl logs. Aber welcher Container? Welcher Pod in einem ReplicaSet mit 12 Instanzen? Und was, wenn der Pod schon neugestartet wurde?

Log-Analyse in Kubernetes ist kein Hexenwerk, aber es gibt Fallen. Hier sind die Befehle und Patterns, die im Alltag funktionieren.

kubectl logs: Die Grundlagen

# Logs eines Pods anzeigen
kubectl logs my-pod -n production

# Logs in Echtzeit verfolgen
kubectl logs -f my-pod -n production

# Logs des vorherigen Containers (nach Crash/Restart)
kubectl logs --previous my-pod -n production

# Logs der letzten 30 Minuten
kubectl logs --since=30m my-pod -n production

# Letzte 100 Zeilen
kubectl logs --tail=100 my-pod -n production

# Logs eines bestimmten Containers in einem Multi-Container-Pod
kubectl logs my-pod -c sidecar-proxy -n production

# Logs mit Timestamps
kubectl logs --timestamps my-pod -n production

Das --previous Flag ist Gold wert: Es zeigt Logs des letzten Containers, bevor Kubernetes ihn neugestartet hat. Ohne dieses Flag siehst du bei einem CrashLoop nur die Logs des gerade laufenden (und gleich wieder crashenden) Containers.

Multi-Pod Logs mit Labels

Bei Deployments mit mehreren Replicas willst du oft alle Pods gleichzeitig sehen:

# Alle Pods eines Deployments
kubectl logs -l app=api-gateway -n production --tail=50

# Mit Prefix für Pod-Zuordnung
kubectl logs -l app=api-gateway -n production --prefix --tail=20

# Alle Container in allen Pods eines Labels
kubectl logs -l app=api-gateway -n production --all-containers

Das --prefix Flag fügt den Pod-Namen vor jede Zeile — unverzichtbar, wenn du Logs mehrerer Pods mischst.

Einschränkung von kubectl logs

kubectl logs hat ein Limit: Es kann maximal fünf Pods gleichzeitig streamen (bei Label-Selektoren). Für größere Deployments brauchst du ein besseres Tool.

Stern: Multi-Pod-Tailing richtig gemacht

Stern ist kubectl logs auf Steroiden. Es unterstützt Regex-Matching, farbliche Pod-Unterscheidung und hat kein Pod-Limit.

# Installation
# macOS:
brew install stern
# Linux:
curl -LO https://github.com/stern/stern/releases/latest/download/stern_linux_amd64.tar.gz

# Alle Pods die mit "api" beginnen
stern api -n production

# Regex-Matching
stern "api-gateway-[a-z0-9]+" -n production

# Nur Fehler filtern
stern api -n production --include "ERROR|FATAL|panic"

# Bestimmten Container in allen Pods
stern api -n production -c nginx

# Logs seit 10 Minuten, nur Errors
stern api -n production --since 10m --include "ERROR"

# Alle Namespaces
stern api --all-namespaces

Stern färbt jeden Pod in einer anderen Farbe. Bei fünf API-Pods siehst du sofort, welcher Pod das Problem hat.

Strukturiertes Logging

Unstrukturierte Logs wie [2026-03-10 14:23:01] ERROR: Connection refused sind für Menschen lesbar, aber schwer zu filtern. JSON-Logs lösen das:

{
  "timestamp": "2026-03-10T14:23:01Z",
  "level": "error",
  "message": "Connection refused",
  "service": "api-gateway",
  "target_host": "postgres.database.svc",
  "target_port": 5432,
  "retry_count": 3,
  "trace_id": "abc123def456"
}

Mit JSON-Logs kannst du in Tools wie Loki oder Elasticsearch nach einzelnen Feldern filtern: target_host="postgres.database.svc" AND level="error".

Error-Patterns: Wonach du grep solltest

Diese Patterns tauchen in Kubernetes-Logs regelmäßig auf:

# OOMKilled — Container hat Memory-Limit überschritten
kubectl logs --previous my-pod | grep -i "out of memory\|OOMKilled\|killed"

# CrashLoopBackOff — Container startet und crasht sofort
kubectl logs --previous my-pod | grep -i "panic\|fatal\|segfault\|exit code"

# Netzwerk-Probleme
kubectl logs my-pod | grep -i "connection refused\|timeout\|no such host\|dial tcp"

# Permissions
kubectl logs my-pod | grep -i "forbidden\|unauthorized\|permission denied\|RBAC"

# Readiness/Liveness Probe Failures
kubectl describe pod my-pod | grep -A5 "Unhealthy\|probe failed"

Ein häufiger Fehler: Du suchst nach error (case-sensitive), aber die Applikation loggt ERROR oder Error. Nutze immer grep -i.

Zentrales Logging vs. lokales Debugging

Für den Alltag brauchst du beides.

Lokales Debugging (kubectl/stern):

• Schnell, kein Setup nötig
• Direkt am Cluster
• Begrenzte Historie (Container-Logs werden bei Restart gelöscht)
• Kein Cross-Service-Korrelation

Zentrales Logging (Loki, ELK, CloudWatch):

• Langzeit-Speicherung
• Cross-Service-Queries
• Alerts auf Log-Patterns
• Aufwändiges Setup und Wartung

Der pragmatische Ansatz: Starte mit kubectl und stern für tägliches Debugging. Baue zentrales Logging auf, wenn du mehr als drei Services betreibst oder Logs länger als 24 Stunden brauchst.

Loki-Stack als leichtgewichtige Lösung

Wenn du bereits Grafana im Cluster hast, ist Loki die naheliegende Wahl:

helm install loki grafana/loki-stack \
  --namespace monitoring \
  --set promtail.enabled=true \
  --set loki.persistence.enabled=true \
  --set loki.persistence.size=10Gi

Promtail sammelt automatisch alle Container-Logs und schickt sie an Loki. In Grafana kannst du dann mit LogQL filtern — ähnlich wie PromQL für Metriken.

Debugging-Checkliste

Wenn ein Pod nicht startet oder crasht, arbeite diese Schritte ab:

1. kubectl describe pod — Events prüfen (ImagePullBackOff, Insufficient CPU, etc.)
2. kubectl logs --previous — Letzte Logs vor dem Crash
3. kubectl logs -c init-container — Init-Container-Logs prüfen
4. stern pod-name --since 5m — Echtzeit-Logs verfolgen
5. kubectl get events --sort-by='.lastTimestamp' — Cluster-Events prüfen

FAQ

Wie sehe ich Logs eines gelöschten Pods?

Gar nicht — kubectl logs funktioniert nur für existierende Pods. Logs gelöschter Pods sind verloren, es sei denn, du hast zentrales Logging (Loki, ELK) eingerichtet. Deshalb immer --previous nutzen, bevor du einen Pod löschst.

Was ist der Unterschied zwischen kubectl logs und kubectl describe?

kubectl logs zeigt die stdout/stderr-Ausgabe des Containers. kubectl describe pod zeigt Kubernetes-Events wie Scheduling, Image-Pull, Probe-Failures. Beides ergänzt sich beim Debugging.

Wie filtere ich Logs nach Zeitraum?

Mit --since=30m (letzte 30 Minuten) oder --since-time="2026-03-10T14:00:00Z" (ab einem bestimmten Zeitpunkt). Stern unterstützt die gleiche --since Syntax.

Warum sind meine Logs nach einem Pod-Restart weg?

Kubernetes speichert Container-Logs nur auf dem Node im Dateisystem. Bei Pod-Restart wird der alte Container entfernt und damit seine Logs. --previous zeigt nur Logs des letzten Containers — nicht ältere. Für persistente Logs brauchst du zentrales Logging.

Wie viel Speicher verbrauchen Container-Logs?

Kubernetes begrenzt Log-Dateien standardmäßig auf 10 MB pro Container mit maximal 5 rotierten Dateien. Das ist über die kubelet-Konfiguration (containerLogMaxSize, containerLogMaxFiles) anpassbar.