搭建java框架写CRD_Logging Operator——用 CRD 来控制 Kubernetes 日志流

概述

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

...

labels app.kubernetes.io/name:log-generator

namespaces logging

...

@type tag_normaliser

@id loki-flow_0_tag_normaliser

format ${namespace_name}.${pod_name}.${container_name}

@type parser

@id loki-flow_1_parser

...

@type nginx

...

@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 比较严重，不要问我是怎么知道的。