Logging Operator项目的一些新变化

开始正文之前先给大家分享一个好消息，经过一段时间的沟通我们产品（KubeGems）的日志解决方案终于得到 Logging Operator 社区的认可，并在首页得到展示支持。再次感谢大家对KubeGems项目的关注与支持！

本次推文主要内容是为用户介绍Logging Operator产品在4.2版本之后的一个重大的更新，一句话总结就是，Logging operator在之后的版本中，逐渐将Logging 对象中的fluentbit剥离出来。考虑到目前的用户至少存在两种不同的使用场景中，可能需要运行具有不同配置的多套采集，并使用同一个聚合器负责日志转发。

场景一

一个特定的例子是当需要以滚动升级的方式进行配置更改时。随着新节点的上线，它们需要运行新的配置，而旧节点使用之前的配置

场景二

当K8S集群中存在不同的节点组（例如多租户的场景）可能需要在不同的节点组上运行不同的 FluentBit 配置

从 Logging operator 4.2 版本开始，我们可以通过使用 FluentbitAgent CRD 来实现上述场景。

在过往版本的Logging Operator中，对 FluentBit的声明是在logging对象中完成，使用FluentbitAgent首先需要进行一次迁移操作。

从spec.fluentbit迁移到FluentbitAgent

独立的 FluentbitAgent CRD 仅在 Logging 操作符版本 4.2 及更高版本中可用。

FluentbitAgent其规范和逻辑与spec. Fluentbit配置方法相同，允许我们从 Logging CRD 中删除spec.fluentbit部分，并将这部分的配置迁移到单独的 FluentbitAgent CRD，完成上述过程大改需要执行以下几步

打开logging对象并找到spec.fluentbit部分。例如

代码语言：javascript复制

apiVersion: logging.banzaicloud.io/v1beta1
kind: Logging
metadata:
  name: example-logging-resource
spec:
  fluentd: {}
  fluentbit:
    positiondb:
      hostPath:
        path: ""
    bufferStorageVolume:
      hostPath:
        path: ""
  controlNamespace: default

创建一个新的 FluentbitAgent CRD。对于metadata.name的值，使用日志记录资源的名称，例如：

代码语言：javascript复制

apiVersion: logging.banzaicloud.io/v1beta1
kind: FluentbitAgent
metadata:
  name: example-logging-resource

将Logging 资源中的spec. Fluentbit部分复制到 FluentbitAgent CRD 的spec部分

代码语言：javascript复制

apiVersion: logging.banzaicloud.io/v1beta1
kind: FluentbitAgent
metadata:
  name: example-logging-resource
spec:
  positiondb:
    hostPath:
      path: ""
  bufferStorageVolume:
    hostPath:
      path: ""

指定新的fluentbit配置的positiondb 和bufferStorageVolume 路径。

迁移时务必注意agent的buffer路径，并沿用配置。以免发生数据丢失。

删除logging对象中的spec.fluentbit部分，然后应用日志记录和FluentbitAgent CRD。

根据容器日志文件名称进行分片采集

有时候当集群的某些节点的FluentBit采集端出现瓶颈时，我们可以针对主机上的容器日志文件名称进行分片采集。例如创建两个FluentbitAgent对象，并在INPUT阶段对文件进行分开采集。

代码语言：javascript复制

apiVersion: logging.banzaicloud.io/v1beta1
kind: FluentbitAgent
metadata:
  name: fb-1
spec:
  inputTail:
    Path: /var/log/containers/*[0-7].log

代码语言：javascript复制

apiVersion: logging.banzaicloud.io/v1beta1
kind: FluentbitAgent
metadata:
  name: fb-2
spec:
  inputTail:
    Path: /var/log/containers/*[8-f].log

根据上述即在主机上运行了两个fluentbit实例，同时采集/var/log/containers/下的容器日志。

根据主机组创建客户端

编辑现有的 FluentbitAgent CRD，并设置spec.nodeSelector字段。

代码语言：javascript复制

apiVersion: logging.banzaicloud.io/v1beta1
kind: FluentbitAgent
metadata:
  name: fb-1
spec:
  nodeSelector:
    nodeGroup: "A"

代码语言：javascript复制

apiVersion: logging.banzaicloud.io/v1beta1
kind: FluentbitAgent
metadata:
  name: fb-2
spec:
  nodeSelector:
    nodeGroup: "B"

其它新功能

在4.0之后，Logging Operato内部集成了新的syslog-ng采集工具。Syslog-ng是一款成熟的开源日志管理工具，已被大型企业使用了二十多年，具有广泛的功能集和出色的性能。

为什么要开始关注新的采集端？

Logging Operator 的最初的设计是为 Kubernetes 创建独立于收集器的解决方案。一开始选择 Fluent Bit 和 Fluentd 方案，是因为当时这些是使用最广泛的工具，并且团队在这方面拥有丰富的经验。随着Logging Operator的发展和覆盖越来越多的用户。这里面就出现了一些新的问题，

例如，当我们拥有相对较大的集群，应用程序设置需要大约 100-150 个flow来处理不同类型的应用的日志规则。而这通过Fluentd 的label-router实现有其局限性：

label-router是一个单线程 Ruby 插件，无法进行批处理。导致每条传入消息，都会多次评估日志流的计算密集型正则表达式匹配过滤器。

所以当前Logging Operator的设计必须跳出现有的条条框框重新思考，并解决大规模集群下的海量日志路由和日志流的新解决方案。

总结

最后我们很高兴看到Logging Opeator社区开始关注大规模k8s集群下日志采集方案的性能问题，KubeGems社区也会紧跟Logging Operator一同优化并推动相关的技术的落地。

logging 对象集群配置日志

0 人点赞