本文共 1003 字，大约阅读时间需要 3 分钟。

Kubernetes容器日志处理方案

0 前言

Kubernetes中的容器日志处理与传统对容器生命周期的依赖无关，这种设计确保无论容器、Pod还是Node发生变化，日志依然可以被正常获取。这种机制为日志收集提供了基础，以下将介绍三种主要的日志处理方案。

容器默认的日志输出机制会将stdout和stderr的日志写入宿主机上的文件，可以通过kubectl logs命令查看。这一机制为日志处理的基础，适用于大部分应用。

为了实现cluster-level-logging，在集群部署时需要提前规划日志方案。Kubernetes推荐以下三种日志处理方案。

第一种方案：在Node上部署logging agent

这种方案通过将日志文件转发到远端存储实现日志收集。logging agent以DaemonSet形式在节点上运行，将宿主机的日志目录挂载后转发。Fluentd常作为logging agent使用，可将日志发送至ES进行存储。该方案的优点是部署简单，节点仅运行一个agent，不影响应用和Pod的运行。

第二种方案：使用sidecar容器重新输出日志

当应用的日志输出到文件（如/var/log/1.log和2.log）时，无法直接使用第一种方案。这时可以通过在Pod中添加sidecar容器，将这些文件的日志重新输出至stdout和stderr，以便通过第一种方案处理。这种方法虽然可行，但存在磁盘空间浪费问题，且资源消耗较高。

第三种方案：直接输出至stdout

$(date): $(date) INFO $i

在Pod定义中配置volumeMounts，并在Fluentd配置中引用这些文件。这种方式将logging agent内置于Pod内，虽然可靠性高，但可能导致资源消耗过高。

方案比较总结

综合比较三种方案，推荐第一种方案。这种方案管理简单，可靠性高，并且易于使用kubectl logs检查日志。此外，许多Node环境自带成熟的日志收集组件（如rsyslogd），可无缝切换。

建议在应用开发阶段直接配置日志输出至stdout和stderr，以充分利用Kubernetes提供的日志处理机制。这种方式最大程度上符合预期，且无需额外配置集群。

日志管理建议

确保宿主机上的日志目录大小管理，避免磁盘溢出问题。建议在固定的远程存储中专门规划存储空间，同时注意容器日志的输出方式选择。