1. 为什么选择 Fluent-bit 来采集 K8s 日志如果你正在管理一个 Kubernetes 集群那么日志管理绝对是你逃不开的“必修课”。想象一下几十上百个 Pod 在集群里跑着每个都在疯狂输出日志你怎么知道哪个服务出了问题传统的做法可能是登录到每个节点上去tail -f但这在微服务时代简直就是噩梦。我之前也试过不少方案比如早期的fluentd功能确实强大插件也多但用久了就发现它对资源的消耗有点“猛”尤其是在日志量大的时候CPU 和内存的占用率看着就心疼。对于追求极致效率和资源利用率的云原生环境来说我们需要一个更轻量、更专注的“尖兵”。这就是Fluent-bit登场的时候了。你可以把它理解为fluentd的“轻量级兄弟”它用 C 语言编写核心目标就一个高效地收集、解析和转发日志。它没有fluentd那么庞大的插件生态但把最核心的采集和转发功能做到了极致二进制文件只有几百 KB内存占用常常能控制在几十 MB 以内。对于 K8s 日志采集这个特定场景Fluent-bit 内置了对容器日志文件/var/log/containers/*.log和 K8s 元数据Pod 名称、命名空间、标签等的原生支持开箱即用。我实测下来在同样的日志吞吐量下Fluent-bit 的资源消耗通常只有fluentd的 40% 左右这对于大规模集群来说省下的资源可不是一点半点。那么采集到的日志往哪送呢这就引出了我们今天的两位“主角”Kafka和Elasticsearch (ES)。直接把日志写到 ES 是最简单的链路适合中小规模、对实时性要求不是特别极致的场景。但如果你面对的是海量日志、需要缓冲、或者下游有多个消费者比如同时给 ES 做搜索分析、给 Splunk 做审计、再实时告警一下那么Kafka这个高吞吐、可持久化的消息队列就是不可或缺的“中间层”。Fluent-bit 对这两者的支持都非常成熟。所以这套“Fluent-bit Kafka/ES”的组合拳就成了构建生产级 K8s 日志管道的黄金标准。接下来我就带你从零开始一步步搭建并优化这套系统分享我踩过的坑和总结出来的最佳实践。2. 手把手部署与配置 Fluent-bit理论说再多不如动手做一遍。部署 Fluent-bit 到 K8s 集群最省心的方法当然是使用 Helm。这就像有个安装向导帮你把大部分脏活累活都干了。不过直接helm install用默认配置可不行我们得根据自家集群的情况好好调教一番。2.1 准备 Helm Chart 与基础配置首先我们把 Fluent-bit 的官方 Helm 仓库添加进来并获取 Chart 包。这里我建议把 Chart 下载到本地方便我们仔细研究并修改配置。# 添加仓库 helm repo add fluent https://fluent.github.io/helm-charts helm repo update # 拉取 Chart 到本地 helm pull fluent/fluent-bit --untar cd fluent-bit解压后你会看到一个values.yaml文件这就是所有配置的核心。我建议你先备份一份原始文件然后我们基于它创建两个针对不同输出目标的配置文件比如values-es.yaml和values-kafka.yaml。我们先来看看几个关键的全局配置项这些不管你输出到哪都得先设置好。在values.yaml里找到image部分我强烈建议把镜像 tag 固定到一个具体的稳定版本比如2.2.0避免因为使用latest标签导致意外升级。然后重点关注resources部分虽然 Fluent-bit 很轻量但在生产环境不给它设资源限制就是“耍流氓”。根据我的经验一个处理中等日志量的 DaemonSet Pod给 100m CPU 和 200Mi 内存的 request以及 200m CPU 和 400Mi 内存的 limit 是个不错的起点。resources: requests: cpu: 100m memory: 200Mi limits: cpu: 200m memory: 400Mi另一个至关重要的配置是tolerations。默认情况下DaemonSet 不会调度到有污点Taint的节点上比如你的 Master 节点。如果你希望 Master 节点的日志也能被采集这通常很有必要就必须加上容忍所有污点的配置tolerations: - operator: Exists这个配置允许 Fluent-bit Pod 容忍任何污点确保它能部署到集群中的所有节点上。2.2 核心配置解析Input, Filter, OutputFluent-bit 的配置逻辑非常清晰就是一条管道Pipeline数据从 Input 进来经过 Filter 加工最后从 Output 出去。我们主要配置这三块。Input 配置抓取容器日志默认的 Input 配置已经帮我们配好了采集容器标准输出日志。它使用tail插件监控/var/log/containers/*.log这个路径下的所有日志文件。这里有个小技巧Multiline处理。一个 Java 的异常堆栈可能被拆成多行我们需要把它们合并成一个事件。Fluent-bit 内置了docker和cri解析器来处理这种常见格式。inputs: | [INPUT] Name tail Path /var/log/containers/*.log multiline.parser docker, cri Tag kube.* Mem_Buf_Limit 50MB Skip_Long_Lines OnMem_Buf_Limit是内存缓冲区限制防止内存被撑爆。Skip_Long_Lines建议打开避免某一行巨长的日志比如打印了个大 JSON卡住整个流程。Filter 配置丰富日志上下文光有日志内容还不够我们还需要知道这条日志是哪个 Pod、哪个命名空间、哪个容器产生的。这就需要kubernetes过滤器。它会查询 K8s API将 Pod 的元数据如pod_name,namespace_name,labels等作为字段添加到日志记录中。这个过滤器是 K8s 日志采集的灵魂。filters: | [FILTER] Name kubernetes Match kube.* Kube_URL https://kubernetes.default.svc:443 Kube_CA_File /var/run/secrets/kubernetes.io/serviceaccount/ca.crt Kube_Token_File /var/run/secrets/kubernetes.io/serviceaccount/token Merge_Log On K8S-Logging.Parser On这里Kube_URL等参数通常不用改Fluent-bit 会使用 Pod 内的 Service Account 自动连接 APIServer。Merge_Log选项尝试将 JSON 格式的日志消息进行合并处理。默认配置可能会附加上非常多的 Label 和 Annotation如果不需要可以通过Labels Off和Annotations Off来关闭能有效减少每条日志的体积。Output 配置日志的最终目的地这就是决定日志是去 ES 还是 Kafka 的地方了。我们接下来会分别详细配置。3. 方案一将日志直接写入 Elasticsearch这是最直接的集成方式适合日志量不是特别巨大、且希望简化架构的场景。Fluent-bit 通过es输出插件与 Elasticsearch 通信。3.1 配置 Fluent-bit 输出到 ES在你的values-es.yaml文件中找到outputs部分进行配置。关键参数如下outputs: | [OUTPUT] Name es Match kube.* Host 192.168.1.100 # 你的 ES 集群地址 Port 9200 HTTP_User elastic # 如果启用了认证 HTTP_Passwd your_password Logstash_Format Off Retry_Limit False Index fluent-bit-k8s Type _doc Time_Key timestamp我来解释几个容易踩坑的参数Match kube.*这表示所有由 tail input 打上kube.标签的日志事件都会匹配到这个输出。Logstash_Format这个参数非常重要。如果设置为OnFluent-bit 会自动按照logstash-%Y.%m.%d的格式生成索引名。如果你不希望自动按日期分索引或者想使用自己的索引命名规则一定要设为Off。我一开始没注意这个结果索引名不受控制在 Kibana 里管理起来很麻烦。Retry_Limit False意味着无限重试。对于日志这种可容忍少量丢失的数据在生产环境我反而建议设置一个数字比如5。否则一旦 ES 集群长时间不可用Fluent-bit 会堆积大量重试请求可能拖垮自己。Index指定写入的索引名称。当Logstash_Format为Off时生效。Time_Key指定哪个字段作为日志的时间戳。默认 Fluent-bit 会添加一个timestamp字段这里就是告诉 ES 用它作为文档的时间戳。3.2 部署与验证配置好后使用 Helm 进行部署或升级helm upgrade --install fluent-bit -n logging ./fluent-bit -f values-es.yaml部署完成后检查 DaemonSet 和 Pod 是否正常运行kubectl -n logging get ds kubectl -n logging get pods -l app.kubernetes.io/instancefluent-bit等几分钟让 Fluent-bit 开始采集并发送日志。然后你就可以在 Kibana 中连接到你的 ES 集群在索引管理里查看是否出现了名为fluent-bit-k8s或你自定义的名字的索引并且有数据写入。3.3 直接写入 ES 的优缺点与优化优点架构简单链路短延迟低。配置好就能在 Kibana 里直接看了。缺点耦合性高Fluent-bit 直接依赖 ES 的可用性。ES 抖动或升级日志采集可能受影响。缓冲能力弱Fluent-bit 的内存缓冲区有限如果 ES 写入变慢容易导致日志丢失或背压传递到应用。难以复用日志一旦写入 ES如果另一个系统比如安全审计平台也需要这份日志就得从 ES 里再导出一份不方便。优化建议使用 ILM索引生命周期管理在 ES 侧配置 ILM 策略自动管理索引的滚动、冻结和删除避免单个索引过大或磁盘被撑满。启用批量写入在 Output 配置中可以调整Buffer_Size和HTTP_Client_Timeout等参数来优化批量提交行为提升吞吐量。考虑多个 Output可以为不同命名空间或标签的 Pod 日志配置不同的 ES 集群或索引实现日志的物理隔离。4. 方案二通过 Kafka 构建高可靠日志缓冲层当你的集群规模上去或者对日志的可靠性、灵活性有更高要求时引入 Kafka 作为缓冲层是更专业的做法。这相当于在日志生产端Fluent-bit和消费端ES等之间加了一个“蓄水池”解耦双方应对流量洪峰。4.1 配置 Fluent-bit 输出到 Kafka修改values-kafka.yaml中的outputs部分使用kafka插件。outputs: | [OUTPUT] Name kafka Match * Brokers 192.168.2.11:9092,192.168.2.12:9092 # Kafka 集群地址多个用逗号分隔 Topics k8s-log-topic rdkafka.log.connection.close false rdkafka.request.required.acks 1配置看起来比 ES 更简单但有几个细节要注意Brokers建议填写至少两个 Kafka Broker 的地址以实现高可用。Fluent-bit 的 Kafka 插件基于librdkafka会自动处理集群发现。Topics指定日志要发送到的 Kafka Topic 名称。你可以根据日志类型设置多个 Topic比如app-log,system-log。rdkafka.*参数这些是底层的librdkafka客户端配置。request.required.acks1是一个很好的平衡点它要求 Leader 副本写入成功就返回兼顾了性能和可靠性。如果追求更高可靠性可以设为-1所有 ISR 副本确认。4.2 Kafka 侧准备工作在部署 Fluent-bit 之前需要在 Kafka 集群中提前创建好 Topic。这可以通过 Kafka 自带的命令行工具完成# 进入 Kafka 容器或使用有客户端的环境 kafka-topics.sh --create --bootstrap-server 192.168.2.11:9092 \ --topic k8s-log-topic \ --partitions 3 \ --replication-factor 2这里--partitions 3指定了分区数分区数决定了消费的并行度可以根据你的日志吞吐量预估来设置。--replication-factor 2指定了副本因子设置为 2 或 3 可以提高数据的可靠性。4.3 部署与数据验证同样使用 Helm 部署helm upgrade --install fluent-bit -n logging ./fluent-bit -f values-kafka.yaml部署成功后如何验证日志确实到了 Kafka 呢我们可以使用 Kafka 的控制台消费者来“偷看”一下 Topic 里的数据kafka-console-consumer.sh --bootstrap-server 192.168.2.11:9092 \ --topic k8s-log-topic \ --from-beginning如果能看到一串串 JSON 格式的日志输出里面包含了日志内容和丰富的 K8s 元数据那就恭喜你链路打通了4.4 从 Kafka 到 Elasticsearch日志到了 Kafka任务只完成了一半。我们还需要一个消费者把数据从 Kafka 搬到 ES。这里你有两个主流选择Logstash或Fluentd。我个人的经验是如果你已经熟悉 Logstash 的配置用它没问题它的kafkainput 插件和elasticsearchoutput 插件都很成熟。但 Logstash 本身也比较重。这里我想提一个轻量级的选择Fluentd。是的虽然我们采集用了更轻的 Fluent-bit但作为聚合层和转发层Fluentd 丰富的插件生态在处理复杂逻辑时很有优势。你可以部署一个单独的 Fluentd 实例或 StatefulSet来消费 Kafka 并写入 ES这样架构上更加清晰Fluent-bit 只负责最基础的采集和转发脏活累活交给后端的 Fluentd 或 Logstash。一个简单的 Fluentd 配置示例 (fluentd.conf)source type kafka2 brokers 192.168.2.11:9092 topic k8s-log-topic format json security sasl_plain_username your_user sasl_plain_password your_pass /security /source match ** type elasticsearch host 192.168.1.100 port 9200 logstash_format true logstash_prefix fluentd-k8s user elastic password your_es_password /match5. 高级调优与生产环境避坑指南基础搭好了但要稳定高效地跑在生产环境还有很多细节需要打磨。下面是我在实战中总结的几个关键优化点和常见问题的处理方法。5.1 性能调优参数Fluent-bit 的性能很大程度上取决于几个缓冲区参数Mem_Buf_Limit(Input)这是每个输入插件内存缓冲区的上限。如果日志产生速度超过输出速度缓冲区满了之后默认会暂停读取Pause_On_Chunks_Overlimit相关行为。对于高吞吐场景可以适当增大比如100MB但一定要监控内存使用量。storage.total_limit_size(Service)这是 Fluent-bit 持久化队列的总大小如果启用了storage.path。当内存缓冲区不够时数据会写入磁盘。这提供了更强的背压容忍能力但会消耗 IO。建议在磁盘空间充足的节点上开启。flush和retry(Output)Flush参数控制批量写入的频率Retry_Limit控制失败重试次数。对于 Kafka/ES适当增大Flush间隔如从默认的5秒调到10秒可以增加批量大小提升吞吐但会增加延迟。需要根据业务容忍度权衡。5.2 精准控制日志采集范围不是所有日志都需要收集。默认配置会采集所有命名空间的容器日志这可能会包含很多系统组件如kube-system、monitoring的噪音日志或者一些你根本不关心的调试日志。方法一在 Input 阶段排除这是最高效的方式直接在源头不采集。使用Exclude_Path参数inputs: | [INPUT] Name tail Path /var/log/containers/*.log Exclude_Path /var/log/containers/*_kube-system_*.log,/var/log/containers/*_monitoring_*.log ...通过匹配文件路径中的命名空间名来排除。这种方式节省了所有后续处理的开销。方法二在 Filter 阶段过滤如果你需要根据更复杂的条件比如 Pod 的 Label来过滤可以使用grep或nest过滤器。例如只采集带有log-collecttrue标签的 Pod 的日志filters: | [FILTER] Name grep Match kube.* Regex $kubernetes[labels][app] ^(foo|bar).*$这个例子使用了grep过滤器只允许app标签以foo或bar开头的 Pod 日志通过。5.3 日志的富化与切分有时你需要给日志添加一些自定义字段比如集群标识、环境信息等。这可以通过modify过滤器轻松实现filters: | [FILTER] Name modify Match kube.* Add cluster_id prod-cluster-01 Add environment production所有匹配的日志记录都会自动加上cluster_id和environment字段在后续的搜索和统计中会非常方便。另外对于某些将多个日志事件打印在一行的“非标准”应用你可能需要使用parser过滤器配合自定义正则表达式将其切分成独立的事件这里就需要根据你的具体日志格式来定制了。5.4 监控与告警一个健康的日志管道离不开监控。你需要监控两方面Fluent-bit 自身状态通过 Fluent-bit 内置的 HTTP 监控接口在values.yaml中启用metrics部分可以暴露 Prometheus 格式的指标如输入/输出的记录数、字节数、错误数等。将这些指标接入你的 Prometheus Grafana 监控栈。下游健康状态监控 ES 集群的写入延迟、拒绝率或者 Kafka Topic 的堆积 Lag。一旦发现 Fluent-bit 输出错误激增或者 Kafka 消费延迟变大就需要立即触发告警。我在生产环境就遇到过因为 ES 性能瓶颈导致 Fluent-bit 输出队列持续增长最终内存耗尽 Pod 重启的情况。有了完善的监控我们就能在问题影响业务之前及时介入比如扩容 ES 节点或者临时调低 Fluent-bit 的采集速率。说到底日志采集没有一劳永逸的“银弹”配置。最好的方案永远是适合你当前业务规模和技术栈的那一个。从小规模集群的直接写入 ES到引入 Kafka 缓冲再到根据日志等级、业务线进行 Topic 拆分和差异化处理每一步的演进都伴随着对稳定性、成本和效率的重新权衡。建议你先从简单的直接写入 ES 开始随着业务增长逐步引入 Kafka 和解耦的消费层并持续观察监控指标进行调优。