Bottom line: Define the investigation interval before accepting a successful log query as the required history. Record which container instance and file population the query covers, and preserve any older evidence through the approved logging workflow.
\nThe Logging Architecture documentation is the primary reference.
\nThe kubelet manages container-log rotation, with containerLogMaxSize and containerLogMaxFiles controlling file size and file count. The guide says kubectl logs exposes only the latest log file, even when earlier files were created by rotation. By default the kubelet keeps one terminated container and its logs after a container restart; Pod eviction also evicts the corresponding containers and logs. The documented --previous option retrieves logs from a previous container instantiation.
This article reviews the ordinary node and container log-access boundaries. It does not establish retention in an external collector, promise recovery of evicted records or approve changing a production rotation setting. Keep the source’s alpha split-stream query section outside this procedure.
\nDSE recommends a short evidence map for the investigation. Name the workload, Pod, container and observation interval before collecting output. Keep the query invocation with the result so another operator can distinguish current-instance output from an explicitly requested previous instance.
\nReview the effective rotation settings with the node owner. Compare them with the expected log volume and investigation requirement, but do not interpret a configured file count as a promise that one API query returns all of those files. Identify a required older interval as a collection requirement rather than an unexplained empty search.
\nPreserve available evidence promptly when a replacement or eviction is planned. Coordinate with the existing cluster logging owner to locate any independently stored records. Keep the external system’s actual retention and coverage observations separate from the kubelet settings; do not fill a missing interval by assuming it was forwarded.
\nReconcile the timeline before drawing an incident conclusion. Mark each output with its container instance and observed first and last records. Ask the investigator to identify remaining gaps explicitly. Avoid reducing rotation or forcing workload churn simply to reproduce a missing-history symptom on a valuable service.
\nProposed verification, not performed: use a disposable Pod that emits a small numbered, nonsensitive sequence under an approved bounded rotation configuration. Observe the current query and the actual node-side file population through authorized tooling. Write the expected query coverage before comparing results.
\nIn a separate controlled case, restart the test container and request its previous output. Treat any eviction exercise as a separately authorized destructive lab step. Retain instance identities, settings, sequence ranges and actual available records, and compare external storage independently. Report observed coverage and gaps without claiming that the proposed exercise has already recovered an incident’s history.
\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.
\n", "content_text": "Bottom line: Define the investigation interval before accepting a successful log query as the required history. Record which container instance and file population the query covers, and preserve any older evidence through the approved logging workflow.\nSource fact: documented behavior\nThe Logging Architecture documentation is the primary reference.\nThe kubelet manages container-log rotation, with containerLogMaxSize and containerLogMaxFiles controlling file size and file count. The guide says kubectl logs exposes only the latest log file, even when earlier files were created by rotation. By default the kubelet keeps one terminated container and its logs after a container restart; Pod eviction also evicts the corresponding containers and logs. The documented --previous option retrieves logs from a previous container instantiation.\nWhat the source does not establish\nThis article reviews the ordinary node and container log-access boundaries. It does not establish retention in an external collector, promise recovery of evicted records or approve changing a production rotation setting. Keep the source’s alpha split-stream query section outside this procedure.\nApplicability questions\n\nWhat time interval must the investigation cover?\nWhich Pod and container instance produced the records?\nDid rotation, restart or eviction occur within that interval?\nWhere can an authorized operator verify any separately retained older records?\n\nDSE recommendation: label the available record population\nDSE recommends a short evidence map for the investigation. Name the workload, Pod, container and observation interval before collecting output. Keep the query invocation with the result so another operator can distinguish current-instance output from an explicitly requested previous instance.\nReview the effective rotation settings with the node owner. Compare them with the expected log volume and investigation requirement, but do not interpret a configured file count as a promise that one API query returns all of those files. Identify a required older interval as a collection requirement rather than an unexplained empty search.\nPreserve available evidence promptly when a replacement or eviction is planned. Coordinate with the existing cluster logging owner to locate any independently stored records. Keep the external system’s actual retention and coverage observations separate from the kubelet settings; do not fill a missing interval by assuming it was forwarded.\nReconcile the timeline before drawing an incident conclusion. Mark each output with its container instance and observed first and last records. Ask the investigator to identify remaining gaps explicitly. Avoid reducing rotation or forcing workload churn simply to reproduce a missing-history symptom on a valuable service.\nVerification and evidence\nProposed verification, not performed: use a disposable Pod that emits a small numbered, nonsensitive sequence under an approved bounded rotation configuration. Observe the current query and the actual node-side file population through authorized tooling. Write the expected query coverage before comparing results.\nIn a separate controlled case, restart the test container and request its previous output. Treat any eviction exercise as a separately authorized destructive lab step. Retain instance identities, settings, sequence ranges and actual available records, and compare external storage independently. Report observed coverage and gaps without claiming that the proposed exercise has already recovered an incident’s history.\nOfficial references\n\nLogging Architecture — Kubernetes.\n\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "content_markdown": "Bottom line: Define the investigation interval before accepting a successful log query as the required history. Record which container instance and file population the query covers, and preserve any older evidence through the approved logging workflow.\n\n## Source fact: documented behavior\n\nThe [Logging Architecture](https://kubernetes.io/docs/concepts/cluster-administration/logging/) documentation is the primary reference.\n\nThe kubelet manages container-log rotation, with containerLogMaxSize and containerLogMaxFiles controlling file size and file count. The guide says kubectl logs exposes only the latest log file, even when earlier files were created by rotation. By default the kubelet keeps one terminated container and its logs after a container restart; Pod eviction also evicts the corresponding containers and logs. The documented --previous option retrieves logs from a previous container instantiation.\n\n## What the source does not establish\n\nThis article reviews the ordinary node and container log-access boundaries. It does not establish retention in an external collector, promise recovery of evicted records or approve changing a production rotation setting. Keep the source’s alpha split-stream query section outside this procedure.\n\n## Applicability questions\n\n- What time interval must the investigation cover?\n\n- Which Pod and container instance produced the records?\n\n- Did rotation, restart or eviction occur within that interval?\n\n- Where can an authorized operator verify any separately retained older records?\n\n## DSE recommendation: label the available record population\n\nDSE recommends a short evidence map for the investigation. Name the workload, Pod, container and observation interval before collecting output. Keep the query invocation with the result so another operator can distinguish current-instance output from an explicitly requested previous instance.\n\nReview the effective rotation settings with the node owner. Compare them with the expected log volume and investigation requirement, but do not interpret a configured file count as a promise that one API query returns all of those files. Identify a required older interval as a collection requirement rather than an unexplained empty search.\n\nPreserve available evidence promptly when a replacement or eviction is planned. Coordinate with the existing cluster logging owner to locate any independently stored records. Keep the external system’s actual retention and coverage observations separate from the kubelet settings; do not fill a missing interval by assuming it was forwarded.\n\nReconcile the timeline before drawing an incident conclusion. Mark each output with its container instance and observed first and last records. Ask the investigator to identify remaining gaps explicitly. Avoid reducing rotation or forcing workload churn simply to reproduce a missing-history symptom on a valuable service.\n\n## Verification and evidence\n\nProposed verification, not performed: use a disposable Pod that emits a small numbered, nonsensitive sequence under an approved bounded rotation configuration. Observe the current query and the actual node-side file population through authorized tooling. Write the expected query coverage before comparing results.\n\nIn a separate controlled case, restart the test container and request its previous output. Treat any eviction exercise as a separately authorized destructive lab step. Retain instance identities, settings, sequence ranges and actual available records, and compare external storage independently. Report observed coverage and gaps without claiming that the proposed exercise has already recovered an incident’s history.\n\n## Official references\n\n- [Logging Architecture](https://kubernetes.io/docs/concepts/cluster-administration/logging/) — Kubernetes.\n\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/check-kubernetes-log-history-beyond-the-latest-rotated-file/", "url": "https://update.dsesecurity.com/updates/check-kubernetes-log-history-beyond-the-latest-rotated-file/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-29" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/check-kubernetes-log-history-beyond-the-latest-rotated-file/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Business Continuity", "item": "https://update.dsesecurity.com/topic/business-continuity/" }, { "@type": "ListItem", "position": 3, "name": "Check Kubernetes log history beyond the latest rotated file", "item": "https://update.dsesecurity.com/updates/check-kubernetes-log-history-beyond-the-latest-rotated-file/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/check-kubernetes-log-history-beyond-the-latest-rotated-file/#article", "identifier": "https://update.dsesecurity.com/updates/check-kubernetes-log-history-beyond-the-latest-rotated-file/", "url": "https://update.dsesecurity.com/updates/check-kubernetes-log-history-beyond-the-latest-rotated-file/", "headline": "Check Kubernetes log history beyond the latest rotated file", "description": "Kubernetes log rotation and kubectl-readable history have different boundaries.", "abstract": "Kubernetes log rotation and kubectl-readable history have different boundaries. The guide exposes only the latest file through kubectl logs and documents separate restart and eviction behavior.", "articleBody": "Bottom line: Define the investigation interval before accepting a successful log query as the required history. Record which container instance and file population the query covers, and preserve any older evidence through the approved logging workflow.\nSource fact: documented behavior\nThe Logging Architecture documentation is the primary reference.\nThe kubelet manages container-log rotation, with containerLogMaxSize and containerLogMaxFiles controlling file size and file count. The guide says kubectl logs exposes only the latest log file, even when earlier files were created by rotation. By default the kubelet keeps one terminated container and its logs after a container restart; Pod eviction also evicts the corresponding containers and logs. The documented --previous option retrieves logs from a previous container instantiation.\nWhat the source does not establish\nThis article reviews the ordinary node and container log-access boundaries. It does not establish retention in an external collector, promise recovery of evicted records or approve changing a production rotation setting. Keep the source’s alpha split-stream query section outside this procedure.\nApplicability questions\n\nWhat time interval must the investigation cover?\nWhich Pod and container instance produced the records?\nDid rotation, restart or eviction occur within that interval?\nWhere can an authorized operator verify any separately retained older records?\n\nDSE recommendation: label the available record population\nDSE recommends a short evidence map for the investigation. Name the workload, Pod, container and observation interval before collecting output. Keep the query invocation with the result so another operator can distinguish current-instance output from an explicitly requested previous instance.\nReview the effective rotation settings with the node owner. Compare them with the expected log volume and investigation requirement, but do not interpret a configured file count as a promise that one API query returns all of those files. Identify a required older interval as a collection requirement rather than an unexplained empty search.\nPreserve available evidence promptly when a replacement or eviction is planned. Coordinate with the existing cluster logging owner to locate any independently stored records. Keep the external system’s actual retention and coverage observations separate from the kubelet settings; do not fill a missing interval by assuming it was forwarded.\nReconcile the timeline before drawing an incident conclusion. Mark each output with its container instance and observed first and last records. Ask the investigator to identify remaining gaps explicitly. Avoid reducing rotation or forcing workload churn simply to reproduce a missing-history symptom on a valuable service.\nVerification and evidence\nProposed verification, not performed: use a disposable Pod that emits a small numbered, nonsensitive sequence under an approved bounded rotation configuration. Observe the current query and the actual node-side file population through authorized tooling. Write the expected query coverage before comparing results.\nIn a separate controlled case, restart the test container and request its previous output. Treat any eviction exercise as a separately authorized destructive lab step. Retain instance identities, settings, sequence ranges and actual available records, and compare external storage independently. Report observed coverage and gaps without claiming that the proposed exercise has already recovered an incident’s history.\nOfficial references\n\nLogging Architecture — Kubernetes.\n\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "datePublished": "2026-10-29T19:49:28+00:00", "dateModified": "2026-10-29T19:50:09+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/check-kubernetes-log-history-beyond-the-latest-rotated-file/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/check-kubernetes-log-history-beyond-the-latest-rotated-file/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Check Kubernetes log history beyond the latest rotated file" }, "articleSection": [ "Business Continuity", "IT" ], "keywords": [ "Business Continuity", "IT", "Guide", "Advisory priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "@type": "Thing", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "wordCount": 519, "timeRequired": "PT3M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "Kubernetes — Logging Architecture", "url": "https://kubernetes.io/docs/concepts/cluster-administration/logging/" } } ] } }