Skip to main content

Command Palette

Search for a command to run...

在 Kubernetes 中使用 Fluent Bit 进行日志采集

Published
•2 min read•View as Markdown

Fluent Bit 和 Fluentd 一样,是 Treasure Data 资助的采集工具,二者对比如下:

FluentdFluentBit
范围服务器嵌入设备和 IoT 设备
内存约 20 MB约 150 KB
语言C 和 RubyC
性能高高
依赖以 Ruby Gem 构建,依赖一系列的 Gem零依赖,可能有些插件会有依赖。
插件超过三百个目前15个左右
授权Apache License v2.0Apache License v2.0

从上表可以看出,Fluentd 具有众多插件,随之而来的是很好的弹性。而 Fluent Bit 则更适用于嵌入设备等资源受限的场景。另外二者并非互斥关系,Fluent Bit 提供了输出插件,可以把数据发给 Fluentd,因此他们可以在系统中作为独立服务互相协作。

Fluent Bit 也提供了 Kubernetes Filter 插件,用于将采集到的日志结合对 Kubernetes API 的查询,为日志加入 Kubernetes 的相关数据,例如 Pod 信息、容器信息、命名空间以及标签和注解等内容。

仅就此来说,Fluent Bit 是可以替代 Kubernetes 缺省推荐的 Fluentd 进行日志采集工作的,经过笔者测试,可以直接使用他替代原有的 Fluentd,使用 DaemonSet 运行,结合 Elastic Search 进行日志归集工作。

详情参见:http://fluentbit.io/documentation/0.11/filter/kubernetes.html

简单的使用如下命令就可以运行:

kubectl create -f https://raw.githubusercontent.com/fluent/fluent-bit-kubernetes-daemonset/master/fluent-bit-daemonset-elasticsearch.yaml

这一 YAML 文件中的镜像版本为 0.11,具体版本更新可以到 Docker Hub 进行查询,其中包含的缺省 elasticsearch 地址为 elasticsearch-logging,端口为 9200,如上配置如果不符,可以下载文件自行修改运行。

另外目前 RBAC 的访问控制模式已经成为缺省,在启用了 RBAC 模式的集群中,该 Pod 的运行是无法成功的,具体表现是日志中出现无法获取 Pod 元数据的信息,这是因为缺省情况下,这一 YAML 中使用的是 kube-system 中的 default Service Account,这一服务账号并不具备获取 Pod 信息的授权,要成功运行,就必须按照 RBAC 的规矩,让 Fluent Bit 的 Service Account 能够获取 Pod 信息,可以用如下方式来解决:

首先为 Fluent bit 创建专门的 Service Account:

kubectl create sa logging -n kube-system

然后为日志收集器创建角色,让该角色可以读取 Pod 信息。

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

接下来创建 ClusterRoleBinding,把新建的角色和 Service Account 绑定在一起:

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: read-pods-global
subjects:
- kind: ServiceAccount
  name: logging
  namespace: kube-system
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

最后在 Fluent Bit 的 yaml 中加入 Service Account 的指派:

# 省略若干
spec:
  template:
    metadata:
      labels:
        k8s-app: fluent-bit-logging
        version: v1
        kubernetes.io/cluster-service: "true"
    spec:
      serviceAccountName: logging
# 省略若干

经过这一番折腾之后,Fluent Bit 就可以在开启 RBAC 的 1.6/1.7 集群上运行了。打开相应的 Kibana 页面,会看到和标配 Fluentd 一致的日志搜集结果。

好吧,今天讲的其实是 RBAC。

More from this blog

AI Agent 的“莫兰迪时刻”

一个新范式真正走向大众,往往不是从所有人都正确理解它开始,而是从它开始被反复引用、简化、误读,甚至滥用开始。 今天的 AI Agent,可能正走到这样一个时刻。 这篇文章的念头,来自我最近收听《大内密谈》vol.1434《审美升级or消费主义?从莫兰迪在中国聊起》时的一些联想。节目从莫兰迪色在中国的走红,谈到作品价格、知识产权、商业流量与消费主义。[9] 我听着听着想到另一个熟悉的技术史问题:为

Oct 5, 20263 min read

FDE 是传统运维产品厂商的出路吗?

很多传统运维产品厂商,已经不缺产品了。 从 ITSM、CMDB、监控、自动化,到 IAM、数据中心管理和各类大屏,一个成熟厂商往往都能拿出一张很完整的产品地图。销售材料上看,客户运维部门的日常工作几乎都被覆盖了。 但项目一落地,味道就变了。 产品越多,集成越重;模块越全,边界越模糊;客户越大,定制越深。到了后期,项目成功本身也会变成麻烦:现场改出来的东西回不到主干,配置越来越像黑箱,谁都不敢轻易升

Jun 29, 20263 min read

绵里藏针才是 AIOps 的本质?

Agent 让运维编排变得柔性、可变、甚至自演进;但真正敢进入生产环境的 AIOps,仍然离不开坚实、受控、可审计、可回退的自动化底座。 从 Gartner 提出 AIOps 概念到现在,也大概有十年了。这么多年来,这个领域好像发生了很多变化,又好像没什么“本质”的变化。技术上,我们经历了传统机器学习、深度学习和神经网络、以及大模型和智能体这样“翻天覆地”的变化;业务上,我们面对的是更多品种、更大

May 31, 20263 min read

龙虾恐慌:AIOps 又要改名了?

ChatGPT 开始,把 AI 拉近到普罗大众的面前,让无数人感受到 AI 的亲民魅力。而龙虾,则把大模型驱动的自动化能力,突然间变得水灵灵、活泼泼地走进千家万户。它不只是“风口上的猪”,而是风口本身。热度高到让 Mac mini 一度断货,不知道这在不在库克的预料之内。 每代人都有每代人的鸡蛋,春节期间,我就领了我的鸡蛋。翻出古老的 MacBook Air M1,充值各种大模型。当然了,这个工具

Mar 9, 20261 min read
【

【伪】架构师

346 posts