Event inspection for diagnostics in Kubernetes - Practice Problems & Coding Challenges

Challenge - 5 Problems

💻 Command Output

intermediate

What is the output of this command?

You run the command kubectl get events --field-selector involvedObject.kind=Pod,involvedObject.name=myapp-pod. What does this command show?

Kubernetes

kubectl get events --field-selector involvedObject.kind=Pod,involvedObject.name=myapp-pod

A An error message saying the field-selector is invalid.

B A list of all events in the cluster, including nodes, services, and pods.

C A list of events related only to the Pod named 'myapp-pod', showing recent warnings and normal messages.

D No output because the command filters out all events.

💡 Hint

Field selectors filter events by object kind and name.

The command filters events to show only those related to the Pod named 'myapp-pod'. It helps diagnose issues specific to that pod.

❓ Troubleshoot

intermediate

Why does this event inspection command return no events?

You run kubectl get events --namespace=production --field-selector reason=FailedScheduling but get no events. What is the most likely reason?

Kubernetes

kubectl get events --namespace=production --field-selector reason=FailedScheduling

A There are no scheduling failures in the 'production' namespace currently.

B The 'reason' field selector is not supported by kubectl.

C You must add <code>--all-namespaces</code> to see events across namespaces.

D The command syntax is incorrect; 'reason' should be 'type'.

💡 Hint

Field selectors only show matching events if they exist.

If no events match the filter, kubectl returns no output. The command is correct but no FailedScheduling events exist now.

❓ Configuration

advanced

How to configure event retention duration in Kubernetes?

You want to increase how long Kubernetes keeps events before deleting them. Which configuration change achieves this?

A Change the <code>kube-controller-manager</code> config to increase event storage size.

B Modify the pod spec to include <code>eventRetention: 48h</code> under metadata.

C Add an annotation <code>event.kubernetes.io/ttl=48h</code> to each event manually.

D Set the <code>--event-ttl</code> flag on the kube-apiserver to a longer duration like '48h'.

💡 Hint

Event TTL is controlled by the API server flag.

The --event-ttl flag on kube-apiserver sets how long events are kept before automatic deletion.

🔀 Workflow

advanced

What is the correct workflow to diagnose a pod crash using events?

You notice a pod is crashing repeatedly. Which sequence of commands helps diagnose the issue using events?

A 1, 4, 3, 2

B 4, 1, 2, 3

C 4, 2, 1, 3

D 2, 4, 1, 3

💡 Hint

Start by listing pods, then describe, then check events and logs.

First list pods to confirm status, then describe pod for details, then get related events, finally check logs for errors.

✅ Best Practice

expert

Which practice best improves event inspection for long-term diagnostics?

You want to keep Kubernetes events for weeks to analyze intermittent issues. What is the best approach?

A Integrate Kubernetes events with an external logging system like Elasticsearch or Loki.

B Manually export events daily using <code>kubectl get events</code> and save to files.

C Increase the <code>--event-ttl</code> flag on kube-apiserver to several weeks.

D Annotate each event with a timestamp to prevent deletion.

💡 Hint

Kubernetes events are ephemeral; external storage is recommended.

Events are short-lived in Kubernetes. Exporting them to external systems allows long-term storage and analysis.