Viewing pod logs and durable log collection

WHAT THIS TESTS This foundational question checks that you can read logs day to day and understand why those logs are ephemeral, motivating a node-level collection architecture.

A GOOD ANSWER COVERS To view logs you use kubectl logs POD_NAME. Add -c CONTAINER for multi-container pods, --previous to see the logs of the prior crashed container instance, and -f to follow a live stream. Under the hood kubectl reads the container's stdout and stderr, which the container runtime writes to files on the node, typically under /var/log/containers. The problem is durability: those files belong to the node and are rotated and ultimately deleted when the pod is removed or rescheduled, so logs disappear with the pod. The standard pattern is node-level logging with a DaemonSet. You run a lightweight agent such as Fluent Bit, Fluentd, or Vector as a DaemonSet so exactly one instance runs per node, tailing all container log files and forwarding them to a central backend like Elasticsearch, Loki, or a cloud logging service. This decouples log retention from pod lifecycle.

COMMON WRONG ANSWERS Saying kubectl logs is sufficient for retention misses that logs vanish with the pod. Proposing a sidecar per pod when a node DaemonSet is the simpler, standard approach over-engineers it. Forgetting --previous when a pod is crash-looping.

LIKELY FOLLOW-UPS DaemonSet versus sidecar logging tradeoffs. Why apps should log to stdout, not files. How log rotation on the node works.

ONE CONCRETE EXAMPLE A crashing pod's last error is gone after a restart, but Fluent Bit running as a DaemonSet already shipped those lines to Elasticsearch, so you query Kibana and find the stack trace despite the pod being long gone.