How to check Kubernetes events

Kubernetes Events record short status reports from the scheduler, controllers, kubelet, and other cluster components while they act on objects. They are often the quickest place to see why a pod stayed Pending, why an image pull failed, why a probe restarted a container, or which object changed during a rollout.

kubectl events prints a recent event table that can be narrowed by namespace, event type, or object. kubectl describe shows the same event stream beside the object status, conditions, owner, selectors, and other context that usually decides the next command.

Events have limited retention and can be repeated into a single row, so treat them as a current triage signal rather than a complete audit log. Start with the affected namespace, narrow the table to Warning rows or one object, and compare the newest reason and message with the object's current state before changing manifests.

1. List recent events in the affected namespace.

   $ kubectl events --namespace app-prod
   LAST SEEN   TYPE      REASON             OBJECT          MESSAGE
   71s         Warning   FailedScheduling   Pod/web-check   0/1 nodes are available: 1 node(s) didn't match Pod's node affinity/selector. no new claims to deallocate, preemption: 0/1 nodes are available: 1 Preemption is not helpful for scheduling.

   Use --all-namespaces only when the affected namespace is unknown or the same incident crosses namespaces.

2. Show only warning events when the namespace has routine progress rows.

   $ kubectl events --namespace app-prod --types=Warning
   LAST SEEN   TYPE      REASON             OBJECT          MESSAGE
   71s         Warning   FailedScheduling   Pod/web-check   0/1 nodes are available: 1 node(s) didn't match Pod's node affinity/selector. no new claims to deallocate, preemption: 0/1 nodes are available: 1 Preemption is not helpful for scheduling.

   Tool: Kubernetes Events Timeline Analyzer

3. Filter the event table to one object.

   $ kubectl events --namespace app-prod --for pod/web-check --types=Warning
   LAST SEEN   TYPE      REASON             OBJECT          MESSAGE
   71s         Warning   FailedScheduling   Pod/web-check   0/1 nodes are available: 1 node(s) didn't match Pod's node affinity/selector. no new claims to deallocate, preemption: 0/1 nodes are available: 1 Preemption is not helpful for scheduling.

   Use the object reference shape accepted by kubectl, such as pod/web-check, deployment/web, job/report-date, or ingress/web.

4. Describe the object when the event message needs surrounding status details.

   $ kubectl describe pod --namespace app-prod web-check
   Name:             web-check
   Namespace:        app-prod
   Node:             <none>
   Status:           Pending
   ##### snipped #####
   Conditions:
     Type           Status
     PodScheduled   False
   Node-Selectors:              disk=ssd
   Events:
     Type     Reason            Age   From               Message
     ----     ------            ----  ----               -------
     Warning  FailedScheduling  71s   default-scheduler  0/1 nodes are available: 1 node(s) didn't match Pod's node affinity/selector. no new claims to deallocate, preemption: 0/1 nodes are available: 1 Preemption is not helpful for scheduling.

   The Events section is most useful when read with the current conditions, node assignment, owner, selectors, volumes, image state, or probe state shown above it.

5. Use a field selector when a stable event list is needed for one object.

   $ kubectl get events --namespace app-prod --field-selector involvedObject.kind=Pod,involvedObject.name=web-check --sort-by=.metadata.creationTimestamp
   LAST SEEN   TYPE      REASON             OBJECT          MESSAGE
   104s        Warning   FailedScheduling   pod/web-check   0/1 nodes are available: 1 node(s) didn't match Pod's node affinity/selector. no new claims to deallocate, preemption: 0/1 nodes are available: 1 Preemption is not helpful for scheduling.

   --field-selector with involvedObject fields works with the event list returned by kubectl get events. --sort-by keeps older and newer rows in timestamp order for review or handoff.

6. Compare the newest event with the object's current state.

   $ kubectl get pod --namespace app-prod web-check
   NAME        READY   STATUS    RESTARTS   AGE
   web-check   0/1     Pending   0          104s

   A current Pending pod plus a newest FailedScheduling event means the scheduler blocker is still active. If the pod is now Running and no newer warnings appear, treat the older event as historical context.