Skip to main content

Command Palette

Search for a command to run...

用 CRD 来控制 Kubernetes 日志流

Published
•2 min read•View as Markdown

概述

Banzai logging operator 已经出到了 v3 版本。这个项目以 Fluentd 为基础,使用 Operator 的实现模式,在 Kubernetes 上用 CRD 的形式,对日志的采集行为进行定制,并进行过滤、路由等操作,最终可以将日志输出到 Elasticsearch、Loki、S3、Kafka 等多种后端。

图中可见,Logging 把日志分为了采集、路由和输出三个阶段。这三个阶段对应三种不同的 CRD:

  • 采集:使用 fluentbit 对日志进行采集

  • 路由:在 fluentd 中使用多种条件对日志条目进行过滤,并将结果发往目标

  • 输出:可以定义各种后端用于接收存储日志。

安装

可以使用 Helm 进行安装:


$ kubectl create ns logging
namespace/logging created

$ helm repo add banzaicloud-stable \
    https://kubernetes-charts.banzaicloud.com
"banzaicloud-stable" has been added to your repositories

$ helm install --namespace logging \
    logging banzaicloud-stable/logging-operator \
    --set createCustomResource=false

...

安装之后,会看到 logging 命名空间中的 Pod:


$ kubectl get po -n logging
NAME                                         READY   STATUS      RESTARTS   AGE
...
logging-logging-operator-7b4f9987f9-86clp    1/1     Running     0          120m

Logging

首先可以定义一个新的 Logging 对象:

apiVersion: logging.banzaicloud.io/v1beta1
kind: Logging
metadata:
  name: default-logging-simple
spec:
  fluentd: {}
  fluentbit: {}
  controlNamespace: logging

提交到集群:

$ kubectl apply -f empty-logging.yaml
logging.logging.banzaicloud.io/empty-logging created
$ kubectl get pods
NAME                                         READY   STATUS              RESTARTS   AGE
empty-logging-fluentbit-2pghs                0/1     ContainerCreating   0          0s
empty-logging-fluentbit-cc4r4                0/1     ContainerCreating   0          0s
empty-logging-fluentbit-jzkpr                0/1     ContainerCreating   0          0s
empty-logging-fluentd-0                      0/2     Pending
...

Describe 新生成的 Pod,会发现它们加载了几个 Secret 作为配置文件。例如 fluentbit 的内容:

$ kubectl view-secret empty-logging-fluentbit
Choosing key: fluent-bit.conf
...
[OUTPUT]
    Name          forward
    Match         *
    Host          empty-logging-fluentd.logging.svc
    Port          24240

    Retry_Limit   False

这里的配置表明,采集器收集到的日志会输出到 empty-logging-fluentd 的服务之中。

追查一下 fluentd 的配置内容,发现其输出配置为空,也就是说,没有提供输出能力。

查看 operator 的日志:

$ kubectl logs -f -l app.kubernetes.io/name=logging-operator
...
{"level":"info","ts":1583835777.4591844,"logger":"controllers.Logging","msg":"resource created","name":"empty-logging-fluentbit","namespace":"logging","apiVersion":"apps/v1","kind":"DaemonSet"}
...
{"level":"info","ts":1583835834.1114376,"logger":"controllers.Logging","msg":"no flows found, generating empty model"}

输出日志中表示,缺乏 flow 定义。

Output

先使用 Helm 安装 Loki,然后定义一个 output:

apiVersion: logging.banzaicloud.io/v1beta1
kind: Output
metadata:
 name: loki-output
spec:
 loki:
   url: http://loki-1583844504.loki:3100
   configure_kubernetes_labels: true
   buffer:
     timekey: 1m
     timekey_wait: 30s
     timekey_use_utc: true

创建这个资源之后,Secret 和 Pod 都没发生什么变化,甚至 Operator Pod 的日志都没有输出内容,看来还是需要创建 Flow 将日志输出过去。

Flow

创建如下的 Flow 对象:

apiVersion: logging.banzaicloud.io/v1beta1
kind: Flow
metadata:
  name: loki-flow
spec:
  filters:
    - tag_normaliser: {}
    - parser:
        remove_key_name_field: true
        reserve_data: true
        parse:
          type: nginx
  match:
    - select:
        labels:
          app.kubernetes.io/name: log-generator
  outputRefs:
    - loki-output

其中 filters 成员中标识了我们要对应用进行的处理,使用 tag_normaliser 加入 Kubernetes 标签。

在 match 中使用标签加入过滤功能,这里选择了 app.kubernetes.io/name: log-generator 的标签对

outputRefs 指定输出到前面创建的 loki-output。

CRD 创建之后

进入 fluentd Pod 的 Shell,会发现配置发生变化:

$ cat fluentd/app-config/fluentd.conf

<match **>
...
    <match>
      labels app.kubernetes.io/name:log-generator
      namespaces logging
...
  <match kubernetes.**>
    @type tag_normaliser
    @id loki-flow_0_tag_normaliser
    format ${namespace_name}.${pod_name}.${container_name}
  </match>
  <filter **>
    @type parser
    @id loki-flow_1_parser
...
    <parse>
      @type nginx
...
  <match **>
    @type loki

部署一个应用:

apiVersion: apps/v1
kind: Deployment
metadata:
 name: log-generator
spec:
 selector:
   matchLabels:
     app.kubernetes.io/name: log-generator
 replicas: 1
 template:
   metadata:
     labels:
       app.kubernetes.io/name: log-generator
   spec:
     containers:
     - name: nginx
       image: banzaicloud/log-generator:0.3.2

此时打开 Loki 的 Grafana,就能对日志进行查询了:

结语

这个产品很好的展示了 Operator 固化运维技能的特征。化繁为简,将日志集采过程中所需的复杂知识,精选为一系列的配置组合,以 CRD 的形式呈现给非专家型客户,开箱即用。

kubectl 的 view-secret 插件,Bug 比较严重,不要问我是怎么知道的。

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