# kubectl logs --previous is not enough: Pod log rotation and collection

Diagnose kubectl logs --previous is not enough: Pod log rotation and collection. Evidence to collect, a worked operational example and recovery checks.

Author: Retrivium team
Updated: 2026-11-01
Canonical URL: https://retrivium.ai/journal/kubernetes-log-rotation-restarts/
Language: en

Kubectl logs --previous can retrieve a previous container's log, but it is not a durable archive. Rotation, Pod recreation and node loss limit local evidence. Investigations beyond that lifecycle require separate collection and retention.

## Identify the log instance

Record namespace, Pod UID, container name and restartCount. A Pod name is insufficient if the object was deleted and recreated. Ordinary kubectl logs and --previous address different container instances. Select the container explicitly in a multi-container Pod. Capture evidence before repairs that recreate the object. A diagnostic restart can remove the local trail explaining the original failure when no external collection exists.


[Official reference 1](https://kubernetes.io/docs/concepts/cluster-administration/logging/).

## Inspect kubelet rotation

The kubelet manages container-log rotation through CRI and configured size/file-count limits. Kubectl logs should not be treated as an interface to arbitrary rotated history. Application-owned files may also fall outside stdout/stderr collection. Agent paths must match node configuration. If the collector expects a standard directory while kubelet uses another, missing backend events do not establish that the application wrote nothing.


[Official reference 2](https://kubernetes.io/docs/tasks/debug/debug-application/debug-running-pod/).

## Examine replacement-related loss

Suppose a worker crashes, an operator retrieves --previous, and a Deployment later creates a new Pod on another node. Old local history may no longer be accessible through the new Pod. A node agent that delivered records provides a separate copy according to backend retention. This describes responsibility rather than guaranteed completeness: the agent can lag, lose its buffer or read the wrong file.

| Source | Expected history boundary |
| --- | --- |
| Current logs | Available current container |
| Previous | Earlier instance within accessible scope |
| Rotated files | Node-local rotation policy |
| External backend | Collection delivery and retention |

## Choose a collection architecture

Kubernetes describes node agents, logging sidecars and direct application export. Node agents are commonly DaemonSets reading node logs. A sidecar can handle specialized formats but introduces its own lifecycle. Choose according to actual paths, permissions and retention requirements. Avoid granting an application access to all host logs unnecessarily. Define buffering and backend-outage behavior at each transition.

## Exercise the entire lifecycle

Generate synthetic numbered events and test rotation, container restart and Pod replacement in a controlled environment. Compare received ranges without claiming exactly-once delivery. Preserve paths, agent identity, Pod UID and possible gap boundaries. After correction, verify records remain accessible independently of the original Pod. Durable storage needs access and retention policy; a running DaemonSet alone does not prove survival after node loss. Repeat the lifecycle check following collector configuration changes so a healthy agent process is not mistaken for complete incident evidence.

Related operational reading: [gpu owner network outage log](/journal/gpu-owner-network-outage-log/); [gpu maintenance change register](/journal/gpu-maintenance-change-register/).