如何让Kubernetes在Pod被删除或驱逐后保留节点上的日志文件（支持指定TTL）

好问题！这确实是node-logging-agent方案里的典型痛点——Pod被删除或驱逐后，对应的日志文件会被立即清理，完全没法追溯历史日志。针对你的需求，我整理了几个成熟可行的方案，既能保留已删除Pod的日志，还能配置TTL（存活时间），你可以根据集群情况选择：

从Kubernetes 1.23版本开始，Kubelet新增了两个核心参数来控制容器日志的保留策略，即使Pod被删除，日志文件也会保留到指定的TTL或达到最大文件数才会被清理。

具体配置步骤： #

1. 编辑Kubelet的配置文件（通常路径为/var/lib/kubelet/config.yaml），添加以下配置：

# 日志保留时长，支持h（小时）、d（天）等单位，示例为3天
containerLogRetentionDuration: 72h
# 每个容器保留的最大日志文件数，超过则自动删除最旧的
containerLogRetentionMaxFiles: 5

2. 重启Kubelet服务使配置生效：

systemctl restart kubelet

这个方案的优势是完全原生支持，不需要额外部署工具，配置简单，适合集群版本较新的场景。

如果你的集群版本低于1.23，没法用Kubelet的原生配置，可以通过Logrotate做本地日志归档 + Filebeat调整采集策略的组合来实现需求。

步骤1：配置Logrotate归档日志 #

在每个节点上创建Logrotate规则文件/etc/logrotate.d/kubernetes-pods，内容如下：

/var/log/pods/**/*.log {
    daily          # 每天轮转一次日志
    rotate 7       # 保留最近7天的归档日志
    compress       # 对归档日志进行压缩
    delaycompress  # 延迟压缩，避免影响当前日志写入
    missingok      # 忽略不存在的日志文件
    notifempty     # 空文件不轮转
    copytruncate   # 复制当前日志内容后截断原文件，不影响日志写入
}

Logrotate会自动定期归档/var/log/pods下的日志，即使Pod被删除，归档后的日志文件依然会保留。

步骤2：调整Filebeat采集配置 #

修改Filebeat的配置文件，确保能采集归档后的压缩日志，并设置忽略过旧的日志：

filebeat.inputs:
- type: filestream
  enabled: true
  paths:
    - /var/log/pods/**/*.log
    - /var/log/pods/**/*.log.gz  # 包含归档后的压缩日志
  ignore_older: 72h  # 忽略72小时之前的日志，配合TTL需求
  clean_removed: false  # 即使原日志文件被删除，仍继续跟踪直到读取完成

重启Filebeat后，就能完整采集所有归档日志，且自动忽略超过TTL的旧日志。

如果你的集群需要长期保留大量日志，可以将节点的/var/log/pods/目录挂载到持久化存储（比如本地PV、NAS或云存储），这样即使Pod被删除，日志文件也不会被Kubelet清理。

实现要点： #

1. 为每个节点创建本地PV或挂载共享存储，将/var/log/pods/目录挂载到持久化存储路径。
2. 部署定时清理任务（比如节点上的Cron Job），定期删除超过TTL的日志文件：

# 每天执行一次，删除3天前的日志文件
0 0 * * * find /var/log/pods -name "*.log" -mtime +3 -delete

这个方案的优势是日志存储独立于节点生命周期，适合需要长期归档日志的场景，但要注意监控存储容量，避免磁盘耗尽。

额外注意事项： #

• 无论采用哪种方案，都要监控节点的磁盘使用情况，避免日志占用过多空间导致节点被驱逐。
• 如果使用方案一，要确认集群Kubelet版本≥1.23，低版本不支持相关参数。

内容的提问来源于stack exchange，提问作者updogliu