Container Logs and --previous

Observability and Maintenance / Guide 41 of 44 / Beginner

• Kubernetes1.36.4
• Cluster4 nodes
• Runtimecontainerd 2.2.6
• CNICalico v3.32.1
• TimeAbout 14 min

--previous reads the log of the last terminated container, which the kubelet keeps only until that container is garbage-collected. A container that exits instantly and restarts in a tight loop may already have lost it - the failure reads unable to retrieve container logs for containerd://..., which was produced twice while capturing this guide.

This guide includes

Use this when a container restarted and the error is nowhere in the logs. This matters because kubectl logs shows you the container running now, which has not failed yet - the evidence is in the one that died.

• watching a container fail, and finding its error absent from the current logs
• using --previous to read the container that actually died
• combining -l, --tail, --prefix and --since across a whole Deployment
• naming a container when the Pod has more than one
• finding out what you cannot get back at all once the Pod is deleted

Before you start

• A cluster and kubectl.
• The session creates namespace ckad-logs, a Pod that runs for 25 seconds and then exits 3, a Deployment with three replicas, and a two-container Pod.

1. 1

   The error that is not in the logs

2. 2

   The flags worth knowing

3. 3

   A multi-container Pod needs a name

4. 4

   What you cannot get back

Official sources

• kubectl logs
• Logging Architecture
• Debug Running Pods