Budget analytics Pods restart several times overnight. An engineer needs logs from an earlier crash, not only the latest termination. What limitation of kubectl logs --previous must they understand?
Select an answer to reveal the explanation.
Short Explanation
The --previous switch is a one-slot rewind button—not a DVR with every episode. After multiple restarts, older crash diaries are already gone from that local slot.
Full Explanation
kubectl logs --previous retains only the immediately previous terminated instance's logs, not an unlimited history of every past restart. Budget analytics engineers chasing an earlier overnight crash must understand that after multiple restarts the local previous slot may already point at a later termination, and older diaries are gone without centralized retention. --previous does not always return every historical restart's full logs from etcd indefinitely; etcd is not storing those stdout histories. --previous is not limited to Init containers; it applies to application containers' prior instances as well. --previous does not download node kernel rings instead of container stdout; it reads the prior container log buffer. Exam caveat: For multi-restart incidents, rely on a log backend. On the exam, state the one-slot limitation clearly when asked what --previous can and cannot do. Operational check: Grab --previous immediately after a crash, ship logs centrally going forward, and correlate restart timestamps from describe with retained municipal log storage. In municipal production practice, record the finding in the incident ticket with command output snippets, confirm the fix under change control, and re-validate the user-facing civic service before closing the change window.