How to Retrieve Crash Logs of a Restarted Pod Using kubectl --previous

Scenario

When a pod is in a crash state and the container keeps restarting, using kubelet logs may fail to capture any logs.

Solution

Use the kubectl logs command with the --previous flag, which prints logs for the previous instance of the container in a pod if it exists. kubectl logs pod-name --previous For a multi‑container pod:

kubectl logs pod-name --previous -c container-name

Principle

Kubelet retains the logs of the last few failed containers, which is a prerequisite for using --previous.

Core Mechanism

The --previous option works because kubelet stores pod logs under /var/log/pods/podname as symlinked files that point to Docker container log files. A separate symlink points to the log file of the previously crashed container, and --previous reads that file.

Practice

Example: list pods and view logs.

ubuntu@~$ kubelet get pod
NAME                READY   STATUS    RESTARTS   AGE
busybox             1/1     Running   2394       99d
nginx-deployment    1/1     Running   0          79d
redis               1/1     Running   0          49d

On the node, inspect the log files:

ls /var/log/pods/default_busybox_f72ab71a-5b3b-4ecf-940d-28a5c3b30683/busybox
2393.log  2394.log

The numbers indicate the restart count (e.g., 2393 is the log after the 2393rd restart).

Both files are symlinks to Docker’s JSON log files. Reading logs without --previous accesses the current container’s file; adding --previous reads the previous container’s file.

Verification by editing the log files shows that kubectl logs busybox --previous returns the content of the previous log, while kubectl logs busybox returns the current log.

Conclusion

Kubelet reads log files from /var/log/pods/. The --previous flag also reads from this directory, using a dedicated symlink that points to the log of the last exited container, allowing you to retrieve crash logs of a pod before it restarts.