4. Fluent Bit 轻量采集:架构、对比与 DaemonSet 部署

Fluent Bit 是云原生生态中性能最突出的轻量级日志采集器,专为容器化与边缘场景设计。本章深入拆解其内部架构、与 Fluentd 的选型差异,以及如何在 Kubernetes 中以 DaemonSet 模式完成日志采集部署。

4.1 Fluent Bit 核心架构

Fluent Bit 采用插件化流水线架构,所有数据流经 Input → Parser → Filter → Buffer → Router → Output 六个阶段。每个阶段均可通过配置文件热插拔插件,实现极低资源占用下的高吞吐采集。

架构要点: 单进程多线程模型,主线程负责事件循环与调度,插件线程独立处理 I/O,避免日志积压阻塞核心链路。
Fluent Bit 内部流水线架构图 Fluent Bit 内部流水线架构 Input tail / k8s / syslog Parser regex / json / ltsv Filter grep / modify / throttle Buffer memory / filesystem Router tag match / wildcard Output ES / Kafka / S3 关键设计:Buffer 阶段支持 memory + filesystem 两级缓冲 当 Output 不可用时,数据先写入内存环形队列,溢出后落盘 filesystem,保证不丢日志 典型资源占用 内存:2~10 MB CPU:单核 5%~15% 吞吐:单实例 10~50 MB/s

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)。

部署流程分为三步:

  1. 创建 ConfigMap:定义 Fluent Bit 主配置与解析规则。
  2. 创建 DaemonSet:挂载宿主机日志目录与 ConfigMap。
  3. 配置 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 解析失败导致日志遗漏。
Fluent Bit DaemonSet 部署拓扑 Fluent Bit DaemonSet 部署拓扑 Kubernetes 集群 Node 1 (worker-1) Pod A (app) Pod B (app) Fluent Bit /var/log/containers Node 2 (worker-2) Pod C (app) Pod D (app) Fluent Bit /var/log/containers Elasticsearch 每个 Node 独立运行 Fluent Bit,通过 hostPath 读取本地容器日志,统一写入后端存储

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 避免被驱逐。