EFK

概述 线上炸了，你打开 Kibana 搜日志，发现关键 Pod 3 分钟前被 OOM Kill 重启了，旧日志跟着容器一起灰飞烟灭。这种事在 K8s 环境里太常见了——Pod 是短命的，日志不能跟着 Pod 一起消失。 K8s 的日志采集和传统虚拟机完全不是一回事。传统环境日志躺在 /var/log/ 下，SSH 上去就能看。K8s 里 Pod 随时可能被调度到任何节点，随时可能被销毁重建，日志分散在整个集群。如果不做集中采集，故障排查时你根本找不到日志在哪。 这篇文章把 K8s 日志采集的几种方案拆开讲清楚：DaemonSet 模式、Sidecar 模式、以及基于节点 Agent 的方案。每种方案什么场景用、怎么配置、踩什么坑，全部覆盖。最后给出一套生产可用的选型决策框架。 K8s 日志的三种类型 在讲采集方案之前，先搞清楚 K8s 里有哪些日志。不同类型的日志采集策略完全不同。 1. 容器标准输出日志 这是最常见的一类。应用把日志写到 stdout/stderr，容器运行时（containerd 或 Docker）负责把这些日志落盘到节点的 /var/log/containers/ 目录。 # 查看某节点的容器日志文件 ls /var/log/containers/ # 输出示例 # nginx-xxx_default_app-abc123.log # redis-yyy_default_app-def456.log # 这些文件实际是指向 /var/log/pods/ 下的符号链接 ls -l /var/log/containers/nginx-xxx_default_app-abc123.log # lrwxrwxrwx 1 root root 99 ... nginx-xxx_default_app-abc123.log -> /var/log/pods/default_nginx-xxx_abc123/app/0.log 这类日志的好处是采集简单——DaemonSet 模式直接读 /var/log/containers/*....