日志采集 Agent 模式

日志采集 Agent 的部署方式直接决定资源占用、隔离性和运维复杂度。本文用一张对比表帮你选对模式，再给出每种模式的典型落地形态。

适用环境

# 查看集群节点，判断用 DaemonSet 还是 Node Agent
kubectl get nodes -o wide

# 查看某命名空间 Pod 是否已注入 sidecar
kubectl get pods -n app -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.containers[*].name}{"\n"}'

操作步骤

1. DaemonSet 模式：在每个节点跑一个 Agent（如 Fluent Bit、Filebeat），读取节点上所有容器日志目录。

# 典型部署：Fluent Bit 以 DaemonSet 跑在每个节点
kubectl apply -f https://raw.githubusercontent.com/fluent/fluent-bit-kubernetes-logging/main/fluent-bit-ds.yaml

2. Sidecar 模式：每个业务 Pod 里附带一个采集容器，与业务容器共享 emptyDir 或日志卷。

# 在 Pod 内增加一个 sidecar 容器
containers:
- name: app
  volumeMounts:
  - name: logs
    mountPath: /var/log/app
- name: log-agent
  image: fluent/fluent-bit:latest
  volumeMounts:
  - name: logs
    mountPath: /var/log/app
volumes:
- name: logs
  emptyDir: {}

3. Node Agent（宿主机进程）：在裸机或虚拟机上直接以 systemd 服务运行 Agent，读取本地日志文件。

# 以 systemd 管理 Filebeat
sudo systemctl enable --now filebeat

验证

# DaemonSet 模式：确认每节点一个 Pod
kubectl -n logging get pods -l app=fluent-bit -o wide

# Node Agent：确认进程存活
systemctl status filebeat --no-pager

常见坑

WARNING

DaemonSet 模式共享节点资源，若某 Pod 日志暴增会挤占同节点其它业务；务必给 Agent 设置 CPU/Memory limit。

DANGER

Sidecar 模式会为每个 Pod 多占用一份内存，实例数上千时成本翻倍，慎用于高密度集群。

参考资料

• Kubernetes Logging Architecture
• Fluent Bit DaemonSet Deployment
• Filebeat Kubernetes Module