CertGrid CertGrid
Troubleshooting·Certified Kubernetes Application Developer

Events, describe and kubectl top

Almost every "why is this broken" question is answered by events, and almost everyone reads them the slow way. This creates two Pods that fail differently - one unschedulable, one unpullable - and works through sorting and filtering events, reading describe's own Events section, and using top for the numbers that events never contain.

Observability and Maintenance Guide 43 of 44 Beginner

Written against the versions above. Events expire. The API server's `--event-ttl` defaults to one hour, so an event from this morning is simply gone - which is why `kubectl get events` on a Pod that has been failing all night is often empty while the Pod's status still shows the problem.

Four nodes, which is why the FailedScheduling message below counts `0/4` and explains each node's refusal separately.
Server NameIP AddressOSRolesCPURAMHDD
CKA1001192.168.0.175Ubuntu 26.04 LTSControl Plane Node2 Core4 GB50 GB
CKA1001-NODE01192.168.0.176Ubuntu 26.04 LTSWorker Node2 Core4 GB50 GB
CKA1001-NODE02192.168.0.177Ubuntu 26.04 LTSWorker Node2 Core4 GB50 GB
CKA1001-NODE03192.168.0.178Ubuntu 26.04 LTSWorker Node2 Core4 GB50 GB

Before you start

  1. Two Pods that will not run

  2. Events, sorted and filtered

  3. describe puts it in one place

  4. top, for what events never tell you

  5. Events do not last

Official sources

← All CKAD guides