Check Kubernetes log history beyond the latest rotated file

Bottom line: Define the investigation interval before accepting a successful log query as the required history. Record which container instance and file population the query covers, and preserve any older evidence through the approved logging workflow.

Source fact: documented behavior

The Logging Architecture documentation is the primary reference.

The kubelet manages container-log rotation, with containerLogMaxSize and containerLogMaxFiles controlling file size and file count. The guide says kubectl logs exposes only the latest log file, even when earlier files were created by rotation. By default the kubelet keeps one terminated container and its logs after a container restart; Pod eviction also evicts the corresponding containers and logs. The documented --previous option retrieves logs from a previous container instantiation.

What the source does not establish

This article reviews the ordinary node and container log-access boundaries. It does not establish retention in an external collector, promise recovery of evicted records or approve changing a production rotation setting. Keep the source’s alpha split-stream query section outside this procedure.

Applicability questions

• What time interval must the investigation cover?
• Which Pod and container instance produced the records?
• Did rotation, restart or eviction occur within that interval?
• Where can an authorized operator verify any separately retained older records?

DSE recommendation: label the available record population

DSE recommends a short evidence map for the investigation. Name the workload, Pod, container and observation interval before collecting output. Keep the query invocation with the result so another operator can distinguish current-instance output from an explicitly requested previous instance.

Review the effective rotation settings with the node owner. Compare them with the expected log volume and investigation requirement, but do not interpret a configured file count as a promise that one API query returns all of those files. Identify a required older interval as a collection requirement rather than an unexplained empty search.

Preserve available evidence promptly when a replacement or eviction is planned. Coordinate with the existing cluster logging owner to locate any independently stored records. Keep the external system’s actual retention and coverage observations separate from the kubelet settings; do not fill a missing interval by assuming it was forwarded.

Reconcile the timeline before drawing an incident conclusion. Mark each output with its container instance and observed first and last records. Ask the investigator to identify remaining gaps explicitly. Avoid reducing rotation or forcing workload churn simply to reproduce a missing-history symptom on a valuable service.

Verification and evidence

Proposed verification, not performed: use a disposable Pod that emits a small numbered, nonsensitive sequence under an approved bounded rotation configuration. Observe the current query and the actual node-side file population through authorized tooling. Write the expected query coverage before comparing results.

In a separate controlled case, restart the test container and request its previous output. Treat any eviction exercise as a separately authorized destructive lab step. Retain instance identities, settings, sequence ranges and actual available records, and compare external storage independently. Report observed coverage and gaps without claiming that the proposed exercise has already recovered an incident’s history.

Official references

• Logging Architecture — Kubernetes.

Source review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.