Every chapter so far ended a kubectl describe with an Events: block. Those lines are not part of the object; they are Event objects of their own, written by the components that acted: the scheduler when it placed a Pod, the kubelet when it pulled an image or killed a container, a controller when it created or refused something.

Listing them

kubectl get events -n wastes --sort-by=.lastTimestamp

LAST SEEN   TYPE      REASON              OBJECT                      MESSAGE
3m          Normal    Scheduled           pod/market-api-7b6-x2k4p    Successfully assigned wastes/market-api-7b6-x2k4p to shallows-node-1
3m          Normal    Pulled              pod/market-api-7b6-x2k4p    Container image "stackmonsters/monster-market-api" already present on machine
2m (x4 over 3m)  Warning   BackOff        pod/market-api-7b6-x2k4p    Back-off restarting failed container api in pod market-api-7b6-x2k4p

Without --sort-by the list is in name order, which hides the sequence. Sorted, it reads as a timeline: scheduled, pulled, started, failed, backing off.

Two types

Normal is the cluster doing its job. Warning is something it could not do: FailedScheduling, Unhealthy, BackOff, FailedCreate, FailedMount. Filter to them when the list is long:

kubectl events -n wastes --types=Warning
kubectl events -n wastes --for deploy/market-api

kubectl events is the newer command: it sorts by time on its own and --for narrows to one object and its children.

Repeats and expiry

Identical events are collapsed into one line with a count: (x12 over 20m). A count that keeps rising is a problem that keeps happening.

Events live for about an hour, then they are gone. They are the cluster's short-term memory, good for "what just happened", useless for "what happened last night". That is what a logging stack is for.