kubectl get events --sort-by='.lastTimestamp' setzt das neueste Cluster-Event ans Ende, statt sie in der Reihenfolge auszugeben, die die API zufällig liefert. Events sind der erste Ort, an dem man nachschaut, noch vor den Logs — Logs sagen, was die Anwendung getan hat, Events sagen, was der Cluster mit ihr gemacht hat. Die Hälfte der Ausfälle, die wirklich zählen (kein Speicherplatz, ein Image, das sich nicht pullen lässt, fehlende Ressourcen, ein Volume, das nie gemountet wurde), taucht in keinem Log auf.
1. Wie sortiert man kubectl-Events nach Zeit?
$ clai zeig cluster-events, die neuesten unten→ kubectl get events --sort-by='.lastTimestamp'
Ohne Sortierung kommen die Events in der Reihenfolge zurück, in der die API sie zufällig ablegt, was sie zum Durchsehen unbrauchbar macht. Der Sortierschlüssel beginnt mit einem Punkt, weil es ein JSONPath in das Event-Objekt ist.
2. Wie zeigt man nur Warnungen in einem Namespace?
$ clai zeig warnungen im namespace production von zuletzt→ kubectl get events -n production --field-selector type=Warning --sort-by='.lastTimestamp'
Events gibt es in zwei Typen, Normal und Warning. Normal fügt beim Analysieren eines Vorfalls nur Rauschen hinzu. --field-selector filtert serverseitig, bleibt also auch bei einem großen Cluster schnell.
3. Wie zeigt man die Events eines einzelnen Pods?
$ clai zeig was mit diesem pod passiert ist→ kubectl describe pod my-app-7d9f8 -n production
describe gibt die Events am Ende der Ausgabe aus, schon dem Objekt zugeordnet — meist schneller, als die gesamte Event-Liste zu filtern. Dort siehst du Gründe wie FailedScheduling, ImagePullBackOff oder OOMKilled.
4. Wie bekommt man die Logs eines abgestürzten Containers?
$ clai zeig logs vom vorherigen lauf dieses containers→ kubectl logs my-app-7d9f8 -n production --previous
Startet ein Container neu, werden seine Logs durch die der neuen Instanz ersetzt. --previous holt die Logs der vorherigen Instanz — genau die, in denen der Absturzgrund steht. Ohne das Flag schaust du auf einen gerade gestarteten Prozess, der noch nichts zu sagen hat.
5. Wie verfolgt man Events live?
$ clai verfolge events in diesem namespace gerade jetzt→ kubectl get events -n production --watch
Praktisch während eines Rollouts: Du siehst live, wie der Scheduler Pods platziert, Images gepullt werden und Readiness-Checks durchlaufen. Ctrl+C zum Beenden.
6. Warum startet ein Pod nicht?
$ clai zeig pods die nicht running sind, und ihre events→ kubectl get pods -n production --field-selector status.phase!=Running
Erst auf die kaputten Pods eingrenzen, dann jeden einzeln mit describe prüfen. Pending bedeutet fast immer, dass der Scheduler keinen Platz für den Pod findet — zu wenig Ressourcen, nicht passende Placement-Constraints, oder ein Volume, das nicht gefunden wurde.
Fallstricke
- Events leben ungefähr eine Stunde.
--event-ttlsteht standardmäßig auf 1 Stunde, danach ist das Event weg. Für den gestrigen Vorfall bleibt anhand von Events nichts mehr übrig — dafür braucht es einen externen Collector. --sort-bybraucht einen JSONPath mit führendem Punkt.--sort-by='.lastTimestamp', nichtlastTimestamp. Ohne den Punkt liefert der Befehl stillschweigend eine unsortierte Liste.- Events sind an einen Namespace gebunden. Ohne
-nschaust du in den Default-Namespace und siehst nichts aus production. Für den vollen Überblick--all-namespaces.
Verwandte Fragen
Logs oder Events — womit fängt man an? Mit Events. Sie sagen, ob die Anwendung überhaupt zum Start gekommen ist. Logs zählen erst, sobald der Container tatsächlich läuft.
Warum ist kubectl logs leer? Entweder ist der Container nie gestartet, er schreibt nicht auf stdout, oder er ist schon neu gestartet. Events beantworten die ersten beiden Fälle, das Flag --previous den dritten.
Was unterscheidet kubectl events von kubectl get events? Der eigenständige Befehl kubectl events kam später dazu und sortiert standardmäßig nach Zeit. get events funktioniert überall, auch auf älteren Clustern.
Siehe auch
- Docker und Kubernetes: Muskelgedächtnis, ersetzt
- Docker hat deine Festplatte gefressen: Platz zurückholen
- Die Logs eines Dienstes mit journalctl lesen
CliAI verwandelt eine Frage in normaler Sprache über einen Pod in den richtigen kubectl-Befehl, ohne dass du dir Field-Selektoren oder JSONPath-Syntax merken musst. In einer Zeile installieren.