4. Fluent Bit 部署模式：DaemonSet、Sidecar、Aggregator 的选择

在多集群与大规模节点场景下，Fluent Bit 的部署模式直接决定了日志采集的可靠性、资源开销与运维复杂度。本章从架构视角对比三种主流部署模式：DaemonSet（节点级代理）、Sidecar（应用级代理）与 Aggregator（集中转发器），并给出选型决策矩阵。

4.1 三种部署模式概述

4.2 DaemonSet：节点级日志代理

DaemonSet 模式在每个 Kubernetes 节点上运行一个 Fluent Bit Pod，通过挂载宿主机 /var/log/containers、/var/log/pods 等路径采集所有容器的标准输出日志。这是 Fluent Bit 官方推荐的生产部署方式。

• 优势：资源开销低（每个节点仅 1 个 Pod）、配置统一、自动扩缩容随节点增减。
• 劣势：无法处理应用侧多行日志（如 Java 堆栈）、日志解析逻辑全局生效，无法按应用定制。
• 适用：集群审计日志、节点 syslog、大部分无状态服务的 stdout 日志。

# DaemonSet 核心配置示例
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluent-bit
  namespace: logging
spec:
  selector:
    matchLabels:
      app: fluent-bit
  template:
    metadata:
      labels:
        app: fluent-bit
    spec:
      containers:
      - name: fluent-bit
        image: cr.fluentbit.io/fluent/fluent-bit:3.1
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        - name: varlibdockercontainers
          mountPath: /var/lib/docker/containers
          readOnly: true
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
      - name: varlibdockercontainers
        hostPath:
          path: /var/lib/docker/containers

4.3 Sidecar：应用级日志代理

Sidecar 模式将 Fluent Bit 作为业务 Pod 内的第二个容器运行，通过 emptyDir 卷共享日志文件。适用于需要应用级定制解析、多行日志合并或日志格式转换的场景。

• 优势：日志解析与应用完全解耦但隔离、支持多行日志、可按应用独立配置。
• 劣势：每个业务 Pod 额外消耗资源（CPU/内存）、运维复杂度高（需注入 Sidecar）。
• 适用：Java 堆栈日志、自定义日志格式、需要应用级标签的场景。

# Sidecar 注入示例（部分 Pod 配置）
apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  containers:
  - name: my-app
    image: my-app:latest
    volumeMounts:
    - name: shared-logs
      mountPath: /var/log/app
  - name: fluent-bit-sidecar
    image: cr.fluentbit.io/fluent/fluent-bit:3.1
    volumeMounts:
    - name: shared-logs
      mountPath: /var/log/app
      readOnly: true
    - name: config
      mountPath: /fluent-bit/etc
  volumes:
  - name: shared-logs
    emptyDir: {}
  - name: config
    configMap:
      name: fluent-bit-sidecar-config

4.4 Aggregator：集中转发器

Aggregator 模式以 Deployment 或 StatefulSet 形式部署独立的 Fluent Bit 集群，专门接收来自多个 DaemonSet 或 Sidecar 实例的转发数据。它是跨集群日志架构的核心组件。

• 优势：集中处理数据过滤、路由、缓冲、重试；支持跨集群、跨区域汇聚；可独立扩缩容。
• 劣势：增加一跳网络延迟；需要额外的负载均衡与服务发现。
• 适用：多集群统一输出、数据脱敏、集中告警、后端存储限流保护。

# Aggregator 转发接收配置（fluent-bit.conf）
[SERVICE]
    flush           1
    log_level       info

[INPUT]
    name            forward
    listen          0.0.0.0
    port            24224
    buffer_chunk_size    1M
    buffer_max_size      10M

[OUTPUT]
    name            es
    match           *
    host            elasticsearch-central.example.com
    port            9200
    index           fluent-bit-%Y.%m.%d
    retry_limit     5

4.5 部署模式对比与选型矩阵

4.6 混合部署架构

生产环境中通常采用 DaemonSet + Aggregator 的混合模式：DaemonSet 负责节点级采集，Aggregator 负责跨集群汇聚与缓冲。Sidecar 仅在需要应用级定制时按需注入。

4.7 选型决策流程

1. 是否仅需采集 stdout/stderr？ → 是 → 使用 DaemonSet。
2. 是否需要应用级多行日志解析？ → 是 → 考虑 Sidecar 注入。
3. 是否需要跨集群汇聚或集中缓冲？ → 是 → 增加 Aggregator 层。
4. 资源预算是否充足？ → 否 → 优先 DaemonSet，减少 Sidecar 使用。
5. 运维团队是否具备 Sidecar 管理能力？ → 否 → 避免大规模 Sidecar 部署。