For a container incident, ask which record would answer the question: application output, container-runtime information, node activity, or Kubernetes API auditing. These sources describe different layers. A line in a workload log does not independently prove a cluster administration action, and an API audit record need not contain the application's internal activity.
Draw the actual collection path
Kubernetes logging architecture describes container output, kubelet-managed log rotation, and common approaches to cluster-level collection. Kubernetes does not supply one universal durable logging backend. Record the cluster version, runtime, node operating system, logging agents, sidecars, destinations, and retention policy that actually applied.
A dashboard may query a backend with a different retention period than the node. A container restart, Pod replacement, or node departure can change what is locally available. Preserve surviving records promptly within scope, but do not assume a command returning current output has collected the entire historical log set.
Use identities that survive a friendly-name collision
Record cluster identity, namespace, Pod UID, container name, container identifier, node identity, and the relevant restart or lifecycle context. A deployment name describes an arrangement that can span multiple Pod instances. Keep these identifiers in exported tables so similarly named replacements are not merged into one continuous process.
Capture the exact query and time interval for every backend export. Keep original structured fields, timestamps, and multiline boundaries when available. A collector can attach useful context, but determine whether it describes the source instance or a later lookup of the same name. This distinction matters when resources have been replaced.
Audit policy determines the API evidence
Kubernetes auditing documentation describes policy levels that range from no matching event to metadata, request, and request-response detail. A metadata-only event cannot supply a missing request body merely because an analysis tool offers a field for it. Preserve the applicable policy, backend configuration, relevant stages, and source records.
Managed control planes may expose a provider-specific subset or separate export path. Describe that service and the permissions used for collection. Do not infer unavailable control-plane records from the behavior of a self-managed example cluster.
Compare layers with one bounded question
| Question | Useful source | Remaining limit |
|---|---|---|
| What did the application report? | Preserved workload output. | The message may be incomplete or application supplied. |
| Which instance produced it? | Runtime and workload identifiers. | A friendly name alone is insufficient. |
| Was an API request recorded? | Applicable API audit backend. | Policy and stage determine detail. |
| Who controlled the credential? | Authentication and external identity records. | An account label does not identify a person by itself. |
Routine rotation, restarts, backend delays, and collection exclusions are competing explanations for gaps. Corroborate them with lifecycle records and configuration. Keep conflicting observations visible instead of forcing node and backend times into an unsupported exact sequence.