K8s Pod内使用Filebeat/Logstash/Fluentd采集容器stdout/stderr日志

组件选型参考 #

结合你提到的三个可选组件，从资源占用、适配性角度做直接对比：

• 优先选择Fluentd：内存占用稳定在80-120MB区间，相比Logstash资源开销降低70%以上，对容器运行时生成的stdout/stderr日志有原生解析能力，不需要手动写大量正则匹配规则，作为第三个容器的采集载体性价比最高
• 可适配选择Filebeat：整体资源占用比Fluentd稍低，适合团队已经搭建了全链路Filebeat采集体系的场景，缺点是需要手动配置不同容器运行时的日志路径匹配规则，对日志轮转异常的容错性弱于Fluentd
• 不推荐Logstash：单实例最低内存占用通常在300MB以上，本来Pod的资源配额大多优先留给业务容器，跑它当采集载体太浪费资源，投入产出比极低

无业务侧改造的实现路径 #

全程不需要业务容器做任何日志落盘改造，完全依托K8s原生的卷共享能力实现采集：

• 卷配置：在Pod spec中声明一个emptyDir类型的临时卷，将该卷以相同挂载路径同时关联到三个容器
  • 两个业务容器不需要调整任何日志输出逻辑，保持默认向stdout/stderr输出日志的行为即可，容器运行时会自动将这两个容器的标准输出写入共享卷对应的固定路径
  • 第三个采集容器仅需挂载该共享卷，不需要通过exec进入业务容器文件系统，也不依赖业务容器开放任何端口做日志抓取
• 采集规则配置要点：
  • 采集路径仅匹配共享卷下两个目标业务容器对应的stdout/stderr日志软链，避免抓取到采集容器自身的无效日志
  • 日志采集后直接通过内存队列转发到后端存储（Loki、Elasticsearch等），不需要在采集容器内设置本地日志缓存落盘规则，节省临时存储资源
  • 给采集到的日志补充对应源容器的元数据标签，绑定容器名称、容器ID信息，避免两个业务容器的日志混合后无法溯源

落地避坑提示 #

• 不要绑定节点宿主机的日志目录做采集，不然跨节点调度的时候采集容器会找不到日志路径，全程使用Pod内共享卷的路径做匹配，还不会受集群版本、容器运行时类型（containerd、CRI-O）的路径差异影响
• 采集容器仅分配共享卷的读取权限即可，不要额外申请宿主机目录的挂载权限，降低安全风险
• 关闭采集容器自身的日志轮转配置，避免未采集完成的运行时日志被提前截断

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