stern: Logs von mehreren Kubernetes Pods gleichzeitig streamen

Das Problem

Deine Anwendung läuft auf fünf Pods. Irgendetwas stimmt nicht. Du öffnest für jeden Pod ein Terminal:

kubectl logs -f my-app-7d9f8b6c4-xk2p9
kubectl logs -f my-app-7d9f8b6c4-zt7lm
kubectl logs -f my-app-7d9f8b6c4-p9x3k
# ...und so weiter

Fünf Terminals. Fünf Streams. Du wechselst zwischen ihnen und versuchst Events anhand von Timestamps zu korrelieren. Währenddessen loggt genau der Pod, den du gerade nicht beobachtest, den entscheidenden Fehler.

kubectl logs funktioniert für einen Pod. Echte Anwendungen laufen nicht auf einem Pod.

stern

stern ermöglicht das gleichzeitige Tailing von Logs mehrerer Pods – gefiltert nach Name-Pattern oder Label-Selektor. Die Ausgabe ist pro Pod farbkodiert, sodass du sofort siehst, welche Zeile woher kommt.

Ein Befehl. Alle Pods. Ein Stream.

RBAC und Namespace gelten wie bei kubectl – kannst du Pods nicht listen, kann stern sie nicht streamen.

Installation

Via Homebrew (macOS/Linux):

brew install stern

Via krew:

kubectl krew install stern

Via Binary:

Download unter github.com/stern/stern/releases.

Mit kubectx & kubens zum richtigen Cluster; k9s zum Deployment finden, stern für alle Pods auf einmal.

Grundlegende Verwendung

# Alle Pods nach Name-Pattern tailen
stern my-app

# Pods in einem bestimmten Namespace
stern my-app -n production

# Pods in allen Namespaces
stern my-app --all-namespaces

# Pods nach Label-Selektor
stern -l app=my-app

# Nur einen bestimmten Container in Multi-Container Pods
stern my-app -c nginx

# Logs der letzten 10 Minuten anzeigen
stern my-app --since 10m

Die Features die zählen

Farbkodierte Ausgabe: Jeder Pod bekommt seine eigene Farbe. Auf einen Blick erkennst du, welcher Pod was loggt – kein Rätseln über Pod-Name-Prefixe mehr.

Regex Pattern Matching: Das Pod-Name-Argument ist ein regulärer Ausdruck:

# Alle Pods die mit "api" beginnen
stern "api.*"

# Sowohl frontend als auch backend Pods
stern "frontend|backend"

Label-Selektoren: Pods nach Labels statt nach Name ansprechen:

stern -l environment=staging,tier=frontend

Output-Templates: Log-Format mit Go-Templates anpassen:

# Nur die Log-Nachricht ohne Pod-Name-Prefix
stern my-app --template '{{.Message}}'

# Mit Timestamp und Pod-Name
stern my-app --template '{{.PodName}} {{.Message}}'

Filtern mit grep: stern-Output wie jeden Unix-Stream weiterleiten:

# Nur Fehlerzeilen anzeigen
stern my-app | grep -i error

# Zeilen mit einer bestimmten Request-ID
stern my-app | grep "req-id-abc123"

Ein echtes Debugging-Szenario

Du siehst sporadische 500-Fehler. Du weißt nicht, welcher Pod verantwortlich ist. Mit stern:

stern my-app -n production | grep "500"

Ein Befehl. Alle Pods. Fehler werden angezeigt, sobald sie auftreten. Du siehst, dass nur my-app-7d9f8b6c4-zt7lm 500er wirft – dieser Pod läuft auf einem Node mit Memory-Druck. Problem gelöst in zwei Minuten statt zwanzig.

Für Ownership vorher kubectl tree; für einen einzelnen Pod kubectl-Grundlagen.

stern vs kubectl logs

Der letzte Punkt ist wichtig: Wenn ein Pod neustartet oder ein neuer Pod erstellt wird, während stern läuft, erkennt stern ihn automatisch. kubectl logs -f verliert den Stream beim Neustart.

Zusammenfassung

Wer einmal ein Multi-Pod Problem mit stern debuggt hat, dem kommt das Zurückgreifen auf einzelne kubectl logs Befehle vor wie das Lesen eines Buches – eine Seite nach der anderen.