kubectl logs "previous terminated container not found" explained

TL;DR

--previous only works if the kubelet still has the terminated container's logs: the container must have restarted (not been deleted and recreated), and kubelet log rotation must not have cleaned them up. If the pod was deleted, evicted, or the node rotated logs, the previous logs are gone from the kubelet. For reliable crash forensics, ship logs to a central store instead of relying on --previous.

The query

kubectl logs "previous terminated container not found" explained

Use this when

• Debugging a crashed pod but previous logs are missing
• Understanding kubelet log retention
• Deciding whether to rely on --previous
• Setting up crash log persistence

Not for when

• Reading logs of running containers
• Centralized logging setup (the real fix)
• Application-level log formatting

Steps

Step 1: Check whether the container actually restarted

--previous shows the last terminated instance of a container in a still-existing pod. If the pod was deleted and recreated (by a deployment, or manually), there is no previous container in this pod object. Describe the pod and check restart counts. Expected output: restart count greater than zero means --previous should work; zero means there is no previous instance.

Step 2: Check kubelet log rotation settings

The kubelet rotates container logs by size and file count. A crash-looping container that logs verbosely can rotate away its own previous logs before you ask for them. Check the rotation configuration on the node. Expected output: rotation settings understood; aggressive rotation identified as the log eater if so.

Step 3: Check for eviction or node pressure

Evicted pods are deleted; their containers' logs go with the node cleanup. If the pod was evicted for disk or memory pressure, --previous cannot help because the pod object is gone. Expected output: eviction ruled in or out as the cause of missing logs.

Step 4: Look at the node's remaining log files directly

If the pod still exists on the node, the terminated container's log file may still be on disk even if the API reports it missing. SSH to the node and check the container log directory as a last resort. Expected output: logs recovered from disk, or confirmation they are gone.

Step 5: Ship logs centrally so this stops mattering

Deploy a log shipper (DaemonSet) that forwards container logs off the node in real time. Then crash forensics never depend on kubelet retention again. Expected output: previous-crash logs available in the central store regardless of pod lifecycle.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_POlygj9EOzmzOSsLMbi4Pg