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

Short answer

No, --previous is not guaranteed. It reads the log file of the most recently terminated container instance, and that file survives only until kubelet rotation deletes it. In practice, with default rotation settings and typical crash output, it reliably survives at least one restart cycle — often many — but a container that crashes fast and logs heavily can rotate its own previous-instance file away within a few restarts, before you fetch it.

What is confirmed vs. likely

Confirmed mechanics: the kubelet writes each container instance's stdout/stderr to a file under /var/log/pods/<pod_uid>/<container>/, symlinks it from /var/log/containers, and rotates per container log file. kubectl logs --previous maps to the last terminated instance's file via the API server. Rotation is governed by the kubelet's containerLogMaxSize (default 10Mi) and containerLogMaxFiles (default 5).

The likely (not guaranteed) part is the arithmetic: with defaults, roughly 50Mi of total output across restarts can push the oldest file past retention. Exact per-file accounting has varied across releases, so treat byte counts as approximations and verify against your nodes.

When it becomes unreliable

• High output volume per crash. A container that dumps a large stack trace or verbose startup log (say, several MiB) on every attempt fills the 5-file × 10Mi budget quickly. A few rapid restarts can delete the previous instance's file.
• Very fast restart cycles. Before CrashLoopBackOff's backoff stretches out (it caps at 5 minutes), restarts can be seconds apart. Combined with heavy output, this is the danger window. Once backoff lengthens, output per cycle is usually small enough that --previous stays fetchable for a long time.
• Pod deletion or eviction. If the kubelet garbage-collects the pod's log directory, --previous returns nothing regardless of rotation settings.
• Large single files. Even when the file exists, proxying tens of megabytes through the API server is slow and can time out. Bound the read: kubectl logs --previous --tail=200 or --limit-bytes=1Mi.

Practical steps for your case

1. Fetch immediately and bound the read: kubectl logs <pod> -c <container> --previous --tail=500. Repeat right after each restart if the loop is fast.
2. Verify the actual rotation config on the node rather than assuming defaults — many clusters override it. Check /var/lib/kubelet/config.yaml or the kubelet configz endpoint for containerLogMaxSize/containerLogMaxFiles.
3. If --previous comes up empty or truncated, read the rotated files directly on the node: ls -l /var/log/pods/<pod_uid>/<container>/ shows the numbered files; the highest number is the current instance.
4. If this is recurring, deploy a node-level logging agent (Fluent Bit or Fluentd as a DaemonSet) that ships logs off-node before rotation can delete them. That removes the race entirely.

Rule of thumb

Low-output crashers: --previous is effectively reliable; use it. Verbose crashers in a tight loop: treat --previous as best-effort, fetch fast with --tail, and fall back to node-level file access. Anything you need for audit or recurring diagnosis: use a logging agent, because node-local files are ephemeral by design.

One caveat worth flagging: if your cluster sets non-default rotation values, the volume thresholds shift proportionally, so the config check in step 2 is what turns this from a heuristic into a reliable boundary.