Event inspection for diagnostics in Kubernetes - Commands & Configuration

Introduction

Sometimes things go wrong in Kubernetes, like pods not starting or crashing. Event inspection helps you see messages about what happened, so you can find and fix problems quickly.

When a pod is stuck in Pending or CrashLoopBackOff state and you want to know why.

When a deployment is not creating pods as expected and you need to check errors.

When you want to verify if a service or ingress has any warnings or issues.

When troubleshooting node problems that affect workloads.

When you want to audit recent changes or actions in your Kubernetes cluster.

Commands

This command lists recent events in the cluster, showing what happened and when. It helps you see warnings or errors quickly.

Terminal

kubectl get events

Expected Output

LAST SEEN   TYPE      REASON             OBJECT                  MESSAGE

2m          Warning   FailedScheduling   pod/my-pod              0/3 nodes are available: 3 Insufficient cpu.

1m          Normal    Pulled             pod/my-pod              Container image "nginx" already present on machine

30s         Normal    Created            pod/my-pod              Created container my-container

This command shows detailed information about the pod named 'my-pod', including events related to it at the bottom. It helps diagnose pod-specific issues.

Terminal

kubectl describe pod my-pod

Expected Output

Name:         my-pod

Namespace:    default

Status:       Pending

Containers:

  my-container:

    Image:      nginx

    State:      Waiting

      Reason:   Unschedulable

Events:

  Type     Reason            Age   From               Message

  ----     ------            ----  ----               -------

  Warning  FailedScheduling  2m    default-scheduler  0/3 nodes are available: 3 Insufficient cpu.

This command lists all events sorted by the time they were created, so you can see the order of events and find the latest issues easily.

Terminal

kubectl get events --sort-by='.metadata.creationTimestamp'

Expected Output

LAST SEEN   TYPE      REASON             OBJECT                  MESSAGE

5m          Normal    Scheduled          pod/my-pod              Successfully assigned default/my-pod to node-1

3m          Warning   FailedScheduling   pod/my-pod              0/3 nodes are available: 3 Insufficient cpu.

1m          Normal    Pulled             pod/my-pod              Container image "nginx" already present on machine

→

--sort-by - Sorts events by the specified field, here by creation time.

Key Concept

If you remember nothing else from this pattern, remember: Kubernetes events tell you what happened and why, so always check them first when diagnosing problems.

Common Mistakes

Only running 'kubectl get pods' and not checking events.

Pods may show errors or pending states without explaining why, so you miss the root cause.

Always run 'kubectl get events' or 'kubectl describe pod <pod-name>' to see detailed event messages.

Ignoring the timestamps and reading old events.

Old events may confuse you because they are not related to the current problem.

Use '--sort-by=.metadata.creationTimestamp' to see the latest events last.

Summary

Use 'kubectl get events' to see recent cluster events and spot warnings or errors.

Use 'kubectl describe pod <pod-name>' to get detailed pod info including related events.

Sort events by creation time with '--sort-by=.metadata.creationTimestamp' to focus on recent issues.

Practice

1. What is the primary purpose of Kubernetes events when diagnosing cluster issues?

easy

A. To deploy new applications to the cluster

B. To permanently store all logs from containers

C. To configure network policies automatically

D. To show what is happening inside the cluster in real-time

Solution

1. Step 1: Understand Kubernetes events role

   Kubernetes events provide information about actions and changes happening inside the cluster, like pod starts or errors.

2. Step 2: Differentiate from other cluster functions

   Events are not for storing logs, configuring policies, or deploying apps; they are for showing cluster activity.

3. Final Answer:

   To show what is happening inside the cluster in real-time -> Option D

4. Quick Check:

   Events = cluster activity info [OK]

Hint: Events show cluster actions and changes live [OK]

Common Mistakes:

• Confusing events with logs storage
• Thinking events deploy apps
• Assuming events configure network

2. Which of the following commands correctly lists recent Kubernetes events sorted by timestamp?

easy

A. kubectl get events --sort-by=.metadata.creationTimestamp

B. kubectl describe events --sort=timestamp

C. kubectl events list --order=asc

D. kubectl get pods --events

Solution

1. Step 1: Identify correct kubectl syntax for events

   The command to list events is 'kubectl get events'. To sort by timestamp, use '--sort-by=.metadata.creationTimestamp'.

2. Step 2: Check other options for syntax errors

   'kubectl describe events' does not support '--sort', 'kubectl events list' is invalid, and 'kubectl get pods --events' is not a valid flag.

3. Final Answer:

   kubectl get events --sort-by=.metadata.creationTimestamp -> Option A

4. Quick Check:

   Correct command = kubectl get events --sort-by=.metadata.creationTimestamp [OK]

Hint: Use --sort-by=.metadata.creationTimestamp with kubectl get events [OK]

Common Mistakes:

• Using invalid flags like --sort or --order
• Trying to list events with kubectl describe
• Confusing pods command with events

3. Given the command kubectl get events --field-selector involvedObject.kind=Pod --sort-by=.lastTimestamp, what is the expected output?

medium

A. A list of all Pods sorted by creation time

B. A list of all events related to Pods sorted by the last event time

C. An error because --field-selector is invalid with events

D. A list of all nodes with their event counts

Solution

1. Step 1: Understand the command filters and sorting

   The command filters events to only those involving Pods using '--field-selector involvedObject.kind=Pod' and sorts them by '.lastTimestamp'.

2. Step 2: Interpret the output type

   The output will be events related to Pods, not Pods themselves or nodes, and no syntax error occurs.

3. Final Answer:

   A list of all events related to Pods sorted by the last event time -> Option B

4. Quick Check:

   Field selector filters events by Pod, sorted by lastTimestamp [OK]

Hint: Field selector filters events; sort-by orders by timestamp [OK]

Common Mistakes:

• Thinking it lists Pods instead of events
• Assuming syntax error with field-selector
• Confusing nodes with Pods

4. You run kubectl get events --sort-by=.metadata.lastTimestamp but get an error: "error: unknown field selector: .metadata.lastTimestamp". What is the likely cause?

medium

A. Mixing --sort-by with an invalid field selector syntax

B. Trying to sort by a field not supported for sorting events

C. Using --sort-by with an incorrect field path for events

D. Using --sort-by with a field selector syntax instead of sorting

Solution

1. Step 1: Analyze the error message

   The error says "unknown field selector" which suggests the field path used with --sort-by is incorrect for events.

2. Step 2: Verify correct field path for sorting events

   The correct field path for sorting events by last occurrence time is '.lastTimestamp' (root level field). '.metadata.lastTimestamp' does not exist, causing the unknown field error.

3. Step 3: Identify the most accurate cause

   Using --sort-by with an incorrect field path for events correctly states the issue is an incorrect field path for sorting events, causing the error.

4. Final Answer:

   Using --sort-by with an incorrect field path for events -> Option C

5. Quick Check:

   Incorrect field path in --sort-by causes error [OK]

Hint: Check field path spelling and validity for --sort-by [OK]

Common Mistakes:

• Confusing --sort-by with --field-selector
• Assuming syntax error in command structure
• Ignoring field path case sensitivity

5. You want to monitor only warning events related to Pods in the default namespace and see the newest events first. Which command achieves this?

hard

A. kubectl get events -n default --field-selector type=Warning,involvedObject.kind=Pod --sort-by=.lastTimestamp

B. kubectl get events -n default --field-selector type=Warning,involvedObject.kind=Pod --sort-by=.metadata.creationTimestamp

C. kubectl get events --field-selector type=Warning,involvedObject.kind=Pod -n default --sort-by=.metadata.lastTimestamp

D. kubectl get pods -n default --filter type=Warning --sort-by=.lastTimestamp

Solution

1. Step 1: Filter events by type and involved object

   Use '--field-selector type=Warning,involvedObject.kind=Pod' to get warning events related to Pods.

2. Step 2: Specify namespace and sort order

   Use '-n default' for the default namespace and '--sort-by=.lastTimestamp' to sort newest events first.

3. Step 3: Evaluate options

   kubectl get events -n default --field-selector type=Warning,involvedObject.kind=Pod --sort-by=.lastTimestamp correctly combines all requirements. kubectl get events --field-selector type=Warning,involvedObject.kind=Pod -n default --sort-by=.metadata.lastTimestamp has wrong sort field, B uses creationTimestamp which sorts oldest first, D is invalid as it targets pods, not events.

4. Final Answer:

   kubectl get events -n default --field-selector type=Warning,involvedObject.kind=Pod --sort-by=.lastTimestamp -> Option A

5. Quick Check:

   Filter warnings on Pods, default namespace, sort by lastTimestamp [OK]

Hint: Filter warnings on Pods, sort by lastTimestamp for newest first [OK]

Common Mistakes:

• Using wrong sort field for newest events
• Filtering pods instead of events
• Omitting namespace or using wrong flags