Logs, Events, Describe, Metrics

You've already been using these tools since Module 2, one at a time, as each lab needed them. This lesson is the explicit reference: what each one is actually for, so you reach for the right one first instead of guessing.

The four tools

• kubectl logs <pod> — stdout/stderr from a container. Add -c <name> for a specific container in a multi-container pod, and --previous to read the last container's logs after it's already been restarted — without --previous, you're reading the new container's (probably empty) logs, not the one that crashed.
• kubectl describe <kind> <name> — the object's full status plus a chronological Events list at the bottom. For pods specifically, the Last State block (with a Reason like OOMKilled, Error, or Completed, and an Exit Code) is often the single fastest way to know what actually happened.
• kubectl get events --sort-by=.lastTimestamp — the same events describe shows for one object, but cluster- or namespace-wide and in order. Useful when you don't yet know which object to describe.
• kubectl top nodes / kubectl top pods — live CPU/memory usage, sourced from the metrics-server add-on running in this cluster (not part of the Kubernetes API server itself — if top ever errors out, that's a metrics-server problem, not a sign anything else is broken).

A new failure mode: OOMKilled

This lesson's lab introduces one you haven't hit yet: OOMKilled. Every container has a memory limit (Module 6); exceed it even briefly and the Linux kernel's out-of-memory killer ends the process immediately — there's no graceful warning, no SIGTERM first, just gone, then restarted by the kubelet per the pod's restart policy. kubectl describe pod shows this unambiguously: Last State: Terminated, Reason: OOMKilled. This is different from a crash (the app itself exiting) or a failed probe (the app is fine, kubelet thinks otherwise) — the kernel intervened because of a hard resource ceiling, which is why the fix lives in the resources block, not the code.

Reading the chain, not just the symptom

None of these four tools replace understanding what you're looking at. describe's Events are chronological but not always causally obvious — "Scheduled" then "Pulled" then "Created" then "Started" then, seconds later, "Killing" tells a story, but you have to read it as one. The next lesson turns this into an explicit method instead of a vague instinct.

In the lab, a Deployment is unhealthy and restarting. You'll use exactly these four tools — no new YAML, just investigation — to find out why.