4. Fluent Bit 轻量采集:架构、对比与 DaemonSet 部署
Fluent Bit 是云原生生态中性能最突出的轻量级日志采集器,专为容器化与边缘场景设计。本章深入拆解其内部架构、与 Fluentd 的选型差异,以及如何在 Kubernetes 中以 DaemonSet 模式完成日志采集部署。
4.1 Fluent Bit 核心架构
Fluent Bit 采用插件化流水线架构,所有数据流经 Input → Parser → Filter → Buffer → Router → Output 六个阶段。每个阶段均可通过配置文件热插拔插件,实现极低资源占用下的高吞吐采集。
架构要点: 单进程多线程模型,主线程负责事件循环与调度,插件线程独立处理 I/O,避免日志积压阻塞核心链路。
4.2 Fluent Bit vs Fluentd:选型对比
Fluent Bit 与 Fluentd 同属 Fluent 生态,但定位截然不同。Fluent Bit 主打轻量嵌入,Fluentd 侧重复杂路由与高可用集群。以下从 7 个维度进行对比:
| 对比维度 | Fluent Bit | Fluentd |
|---|---|---|
| 开发语言 | C / Rust | Ruby + C 扩展 |
| 内存占用 | 2~10 MB | 30~150 MB |
| 启动时间 | < 1 秒 | 3~10 秒 |
| 插件数量 | ~70 个(核心 + 社区) | ~1000+ 个(丰富生态) |
| 数据路由 | 基于 tag 的简单匹配 | 支持 label、tag、copy、route 等复杂拓扑 |
| 高可用/故障转移 | 依赖外部负载均衡 | 内置 in_forward 心跳 + 自动故障转移 |
| 适用场景 | Sidecar / DaemonSet / 边缘设备 | 集中式日志网关 / 大规模集群汇聚 |
选型建议: 在 Kubernetes 节点级采集场景中,Fluent Bit 是事实标准。只有当需要复杂的数据流复制、多级路由或 Ruby 生态插件时,才考虑引入 Fluentd 作为上游汇聚层。
4.3 Kubernetes DaemonSet 部署模式
在 Kubernetes 中,Fluent Bit 最推荐的部署模式是 DaemonSet:每个 Node 上运行一个 Fluent Bit Pod,采集该节点上所有容器的标准输出日志(stdout/stderr)。
部署流程分为三步:
- 创建 ConfigMap:定义 Fluent Bit 主配置与解析规则。
- 创建 DaemonSet:挂载宿主机日志目录与 ConfigMap。
- 配置 RBAC:允许 Fluent Bit 通过 Kubernetes API 获取 Pod 元数据。
4.3.1 核心 ConfigMap 示例
apiVersion: v1
kind: ConfigMap
metadata:
name: fluent-bit-config
namespace: logging
data:
fluent-bit.conf: |
[SERVICE]
Flush 1
Log_Level info
Parsers_File parsers.conf
[INPUT]
Name tail
Path /var/log/containers/*.log
Parser docker
Tag kube.<namespace_name>.<pod_name>.<container_name>
Mem_Buf_Limit 5MB
Skip_Long_Lines On
[FILTER]
Name kubernetes
Match kube.*
Kube_URL https://kubernetes.default.svc:443
Kube_Tag_Prefix kube.
Merge_Log On
Merge_Log_Key log_parsed
K8S-Logging.Parser On
[OUTPUT]
Name es
Match *
Host elasticsearch.logging.svc.cluster.local
Port 9200
Logstash_Format On
Retry_Limit False
parsers.conf: |
[PARSER]
Name docker
Format json
Time_Key time
Time_Format %Y-%m-%dT%H:%M:%S.%L
4.3.2 DaemonSet 部署清单
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: fluent-bit
namespace: logging
labels:
app: fluent-bit
spec:
selector:
matchLabels:
app: fluent-bit
template:
metadata:
labels:
app: fluent-bit
spec:
serviceAccountName: fluent-bit
containers:
- name: fluent-bit
image: cr.fluentbit.io/fluent/fluent-bit:2.1.10
volumeMounts:
- name: varlog
mountPath: /var/log
- name: varlibdockercontainers
mountPath: /var/lib/docker/containers
readOnly: true
- name: fluent-bit-config
mountPath: /fluent-bit/etc/
volumes:
- name: varlog
hostPath:
path: /var/log
- name: varlibdockercontainers
hostPath:
path: /var/lib/docker/containers
- name: fluent-bit-config
configMap:
name: fluent-bit-config
关键挂载说明:
/var/log/containers 是 symlink 目录,实际指向 /var/lib/docker/containers。建议同时挂载两个路径,避免因 symlink 解析失败导致日志遗漏。
4.4 生产部署关键参数
以下参数直接影响采集稳定性与资源开销,建议在部署前逐项确认:
| 参数 | 推荐值 | 说明 |
|---|---|---|
Mem_Buf_Limit |
5~10 MB | 每个 Input 实例的内存缓冲区上限,超过后启用 filesystem 缓冲 |
Storage.total_limit_size |
1~5 GB | filesystem 缓冲总大小,防止磁盘写满 |
storage.sync |
normal | filesystem 写入模式,normal 为异步批量,full 为同步(更安全但更慢) |
Retry_Limit |
False 或 3 | False 表示无限重试(推荐),数值限制可防止死循环 |
resources.requests.memory |
50~100 Mi | DaemonSet 容器内存请求,保障调度稳定性 |
生产最佳实践: 始终开启
storage.type filesystem 并设置 storage.total_limit_size,确保 Output 后端短暂不可用时日志不丢失。同时配合 Pod 的 priorityClassName: system-node-critical 避免被驱逐。