CrashLoopBackOff logs disappear after pod deletion in Kubernetes

The goal is to understand whether Kubernetes retains container logs for a pod that has exited due to a CrashLoopBackOff event after the pod itself is deleted or evicted. Currently, logs are stored only on the node’s filesystem and are removed according to the node’s log‑rotation policy, with no built‑in API to access them once the pod is gone.

This leaves an unresolved decision about providing a native, API‑accessible log persistence layer for terminated pods. Users must decide whether to rely on external log‑aggregation tools or accept the risk of losing diagnostic data.

Is there a plan to add API‑accessible log persistence for terminated pods? What are the trade‑offs of implementing node‑level log aggregation versus a cluster‑wide solution? How can users reliably retain logs without external tooling?