Events, describe and kubectl top

Observability and Maintenance / Guide 43 of 44 / Beginner

• Kubernetes1.36.4
• Cluster4 nodes
• Runtimecontainerd 2.2.6
• CNICalico v3.32.1
• TimeAbout 15 min

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.

This guide includes

Use this when something will not run and you need the reason quickly. This matters because events explain decisions while top reports consumption - they answer completely different questions, and only one of the two expires.

• creating two Pods that fail for two entirely different reasons
• sorting and filtering events, which come back in no useful order by default
• using describe to get one object's events already gathered into one place
• reading kubectl top for the thing events never tell you
• finding the default event TTL, and why the evidence disappears

Before you start

• A cluster with metrics-server for the top step.
• The session creates namespace ckad-ev with a Pod requesting 40 CPUs and 200Gi of memory, a Pod with an image tag that does not exist, and a small Deployment to measure.

1. 1

   Two Pods that will not run

2. 2

   Events, sorted and filtered

3. 3

   describe puts it in one place

4. 4

   top, for what events never tell you

5. 5

   Events do not last

Official sources

• Debug Pods
• Field selectors
• Resource metrics pipeline