Kubernetes日志收集方案：EFK架构与DaemonSet/Sidecar模式对比

日志收集

本教程共 65 篇 · 第 62 篇 · 更新于 2026-08-14 · 约 9 分钟阅读

Kubernetes日志EFKFilebeatDaemonSet

本节目标：理解 Kubernetes 里日志的几种来源，知道 kubelet 怎么收集与轮转容器日志，并了解 EFK 这类集中采集方案的基本思路。

容器应用一多，日志就散落在各个 Pod 里。出了问题要翻日志，不能挨个 kubectl logs 上去看。把日志集中起来，是运维的基本功。

62-1 日志分几类

Kubernetes 里的日志大致分三块：

业务容器日志：应用写到标准输出（stdout）和标准错误（stderr）的内容。这是最常见的。
集群组件日志：apiserver、控制器、调度器、kube-proxy 这些，它们以 Pod 形式跑在集群里，日志按普通容器日志处理。
节点上的 kubelet 日志：kubelet 是系统进程，日志通常写在节点的 journald 或 /var/log 下。

Note

业务容器的 stdout/stderr 由 kubelet 收集，临时存在节点的 /var/log/pods 目录。容器一删，对应日志也就没了。所以本地日志只是”临时缓存”，真要留存分析得靠采集系统。

62-2 kubectl logs 与日志轮转

最朴素的看日志方式：

kubectl logs <pod名>
kubectl logs <pod名> -c <容器名>

节点上的 /var/log/pods 是真实文件，/var/log/containers 下是它们的符号链接。kubelet 负责收集，也负责轮转——防止单个容器把磁盘写爆。

轮转由两个参数控制，在节点的 kubelet 配置（/var/lib/kubelet/config.yaml）里设置：

containerLogMaxSize: 10Mi     # 单个日志文件最大 10Mi
containerLogMaxFiles: 5       # 单个容器最多保留 5 个文件

改完重启 kubelet 生效。容器日志输出快时，文件可能略微超过设定值，这是轮转检查频率导致的，属正常。

Tip

集群初期可以先不急着装整套日志系统，把 containerLogMaxSize 调大一点（比如 20Mi），配合默认 5 个文件，一个容器单节点最多也就存 100M，足够临时排查了。

62-3 节点级 kubelet 日志

用 systemd 的节点上，kubelet 和容器运行时默认写进 journald。看日志用 journalctl：

# 看 kubelet 日志
journalctl -u kubelet

# 实时跟踪
journalctl -u kubelet -f

# 按时间范围
journalctl -u kubelet --since "2026-08-01" --until "2026-08-03"

journald 以二进制存日志，支持自动轮转和按级别过滤，比直接翻文本文件省心。

62-4 三种采集模式

Kubernetes 官方没给原生日志方案，但推荐了三种思路：

DaemonSet 模式：每个节点跑一个日志代理（以 DaemonSet 部署），统一收集该节点所有 Pod 的 stdout/stderr。
Sidecar 模式：在业务 Pod 里放一个专门的边车容器，负责读日志并转发到后端。
直推模式：应用代码里直接把日志发到后端存储。

DaemonSet 的优点是省资源、一个节点一份代理，还能继续用 kubectl logs。缺点是业务隔离性差，一个代理挂了影响整节点。Sidecar 则相反，每个 Pod 自管日志，隔离好但资源开销大。大型集群常把两者结合：大部分日志用 DaemonSet 收，少数特殊业务用 Sidecar 收。

Warning

直推模式把日志逻辑写进业务代码，既难维护又受网络波动影响，还不能用 kubectl logs 看。除非有强需求，一般不推荐。

62-5 EFK 架构

最常见的一套日志组合是 EFK，由三个开源组件组成：

Elasticsearch（ES）：存储、索引、检索海量日志。
Filebeat（或传统 EFK 里的 Fluentd）：轻量采集器，跑在节点或 Pod 里，把日志发给 ES。它比 Logstash 轻得多，资源占用小。
Kibana：可视化界面，用来查日志、画仪表盘。

Filebeat 在节点上收集 /var/log/pods 下的日志，过滤后发给 ES，Kibana 再把它呈现出来。这整套用 Helm 就能快速装起来。

除了 EFK，还有 Fluentd、Fluent Bit、Vector、Promtail 等采集器可选。它们的定位类似，按团队熟悉度挑即可。

Note

提醒一句：自己搭建和维护整套日志组件，人力成本不低。如果你的团队还没这能力，或者只是小规模私有环境，直接用云厂商开箱即用的日志产品，往往更划算。

62-6 实践建议

从简单开始：先用 kubectl logs 和节点日志把问题能查了，再按需上 EFK。日志轮转参数先调大，避免排查时日志已经被清掉。等业务规模上来、日志量变大，再上 DaemonSet 采集 + ES 存储的方案。

一句话：日志不是为了好看，是为了出事时能快速定位。先把”能看到”做到，再追求”集中看、长期存”。