After a city worker node reboots, local container logs that were never shipped elsewhere are gone. What durability lesson should administrators take?
Select an answer to reveal the explanation.
Short Explanation
Local container logs live on the node’s filesystem like sticky notes on a cubicle wall—reboot the desk and they’re gone unless you mailed copies downtown.
Full Explanation
After a city worker node reboots, local container logs that were never shipped elsewhere are gone. The durability lesson is that without centralized log shipping or remote retention, container log history on a node is ephemeral and can disappear with node or runtime lifecycle events—like sticky notes on a cubicle wall that vanish when the desk is moved. kube-apiserver does not permanently store every Pod's stdout in etcd for the life of the cluster; etcd holds API objects, not full application log archives. Service ClusterIP objects do not automatically archive Pod logs for thirty days; Services are networking abstractions. Ingress controllers do not persist application logs into PersistentVolumeClaims by default; that would be a custom design, not a platform guarantee. Exam caveat: Ephemeral also includes kubelet log rotation and disk-pressure eviction of logs. Municipal clusters should treat shipping as mandatory for production. Operational check: Verify whether a log agent DaemonSet exists, restore shipping if missing, and update the city runbook so on-call never assumes reboot-safe local logs. 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.