Can kubectl logs --previous reliably capture output from a CrashLoopBackOff container before rotation?

I am troubleshooting a Deployment whose Pods enter CrashLoopBackOff shortly after starting. I know the kubelet writes container stdout and stderr to files under /var/log/pods on the node, and that kubectl logs proxies those files through the API server, with --previous exposing the last terminated container instance.

What I cannot pin down is the reliability boundary. The kubelet rotates logs based on containerLogMaxSize and containerLogMaxFiles settings, and if the container restarts rapidly, the previous instance's file may be rotated away or overwritten before I can fetch it. I am also unsure whether rotation behavior differs when the failing container produces very large output, since proxying big files through the API server is known to be slow.

Assume a recent Kubernetes version (1.28+) with default kubelet log rotation settings and no external log aggregator.

Does --previous always survive at least one restart cycle, or can rotation delete it before retrieval? At what log volume or restart frequency does this become unreliable? When should I switch to node-level file access or a logging agent instead?