EKS集群日志存于主机时，为何需用Filebeat DaemonSet而非主机进程？

为什么不建议在主机上以普通进程运行Filebeat？ #

• 运维一致性缺失：Kubernetes的DaemonSet是原生的节点级 workload 管理方式，能通过kubectl统一完成所有节点上Filebeat的配置更新、版本升级、状态监控。而主机进程只能依赖节点本地的systemd或脚本维护，节点数量多了之后，很容易出现配置不一致、版本不统一的情况，运维成本指数级上升。
• 安全风险更高：直接在主机运行Filebeat需要赋予它主机级别的权限（比如读取/var/log/containers、访问主机文件系统），一旦Filebeat存在漏洞被利用，攻击者能直接获取主机控制权，远不如容器化环境的隔离性安全。
• 日志元数据获取困难：容器化的Filebeat（DaemonSet模式）可以通过K8s模块自动抓取Pod的命名空间、Pod名称、标签等关键元数据，方便后续日志的关联分析和过滤。而主机进程需要手动解析日志文件名里的Pod信息，一旦K8s日志格式（比如容器运行时切换）变动，就得手动修改解析规则，适配成本极高。
• 资源无管控：K8s会给DaemonSet的Pod设置CPU、内存资源限制，避免日志采集进程抢占业务Pod的资源。主机进程没有这种K8s原生的资源调度管控，一旦Filebeat异常占用高资源，只能靠主机监控告警，处理效率低。

通过userdata配置节点扩容启动Filebeat的潜在问题 #

• 配置同步混乱：后续修改Filebeat配置（比如输出地址、过滤规则）时，已运行的节点需要逐个手动更新，而新节点用最新userdata启动，很容易出现新旧配置不一致，排查日志问题时会非常棘手。
• 版本迭代麻烦：升级Filebeat版本时，要么修改userdata让新节点用新版本，要么手动登录所有旧节点升级，无法做到批量统一管理，长期运维成本极高。
• 故障排查效率低：主机进程的运行状态只能靠本地systemd日志、主机监控查看，无法用K8s的kubectl logs、kubectl describe等原生工具统一排查，某个节点的Filebeat挂了，得单独登录节点排查，效率低下。
• 依赖环境兼容性问题：不同节点的OS版本（比如Amazon Linux 2 vs 2023）、依赖库可能有差异，userdata里的安装脚本可能在部分节点执行失败，导致新节点Filebeat无法启动，而容器化的DaemonSet自带所有依赖，不会出现这类问题。
• 弹性伸缩可靠性差：如果节点通过Auto Scaling Group（ASG）扩容，userdata里的Filebeat启动脚本可能和ASG的其他初始化逻辑冲突，或者因网络、权限问题启动失败。而DaemonSet是K8s管控的，节点就绪后会自动调度启动，可靠性更高。

总结 #

从技术实现上，在主机上跑Filebeat采集/var/log/containers的日志是可行的，但这种方式违背了Kubernetes的设计理念，会带来运维一致性、安全、可靠性等多方面的问题，这也是社区普遍推荐DaemonSet或Sidecar模式的核心原因。

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