Sign In

Curriculum 13: Debugging & Troubleshooting

Kubernetes Events

12 min · 25 XP

Kubernetes Events

Events are short-lived records that describe what is happening inside your cluster. They capture scheduling decisions, image pulls, container starts, failures, and more. Events are often the first place to look when something goes wrong.

Viewing Events

# List all events in the current namespace
kubectl get events

# Sort by creation time to see the most recent events
kubectl get events --sort-by='.lastTimestamp'

# Sort by the metadata creation timestamp
kubectl get events --sort-by='.metadata.creationTimestamp'

# Watch events in real time
kubectl get events --watch

Filtering Events

# Events for a specific pod
kubectl get events --field-selector involvedObject.name=my-pod

# Only warning events
kubectl get events --field-selector type=Warning

# Events across all namespaces
kubectl get events -A --sort-by='.lastTimestamp'

# Combine filters
kubectl get events --field-selector type=Warning,involvedObject.kind=Pod

Normal vs Warning Events

Events have two types:

  • Normal: Routine operations like successful scheduling, image pulls, and container starts.
  • Warning: Problems such as failed scheduling, image pull errors, liveness probe failures, and OOMKills.
# Quick health check: are there any warnings?
kubectl get events --field-selector type=Warning --sort-by='.lastTimestamp'

Event Lifecycle

Events are not permanent. By default, the API server retains events for one hour. After that, they are garbage collected. Key fields include:

  • reason: A short machine-readable cause (e.g., Pulled, FailedScheduling)
  • message: A human-readable description
  • count: How many times this event has occurred
  • firstTimestamp and lastTimestamp: When it first and last occurred

Practical Usage

# Why is my pod stuck in Pending?
kubectl get events --field-selector involvedObject.name=stuck-pod,type=Warning

# Check for scheduling issues cluster-wide
kubectl get events --field-selector reason=FailedScheduling -A

For long-term event storage, export events to an external system since they disappear from the API server after one hour.