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部分。例如
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的值，使用日志记录资源的名称，例如：
apiVersion: logging.banzaicloud.io/v1beta1
kind: FluentbitAgent
metadata:
name: example-logging-resource
- 将Logging 资源中的spec. Fluentbit部分复制到 FluentbitAgent CRD 的spec部分
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阶段对文件进行分开采集。
apiVersion: logging.banzaicloud.io/v1beta1
kind: FluentbitAgent
metadata:
name: fb-1
spec:
inputTail:
Path: /var/log/containers/*[0-7].log
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字段。
apiVersion: logging.banzaicloud.io/v1beta1
kind: FluentbitAgent
metadata:
name: fb-1
spec:
nodeSelector:
nodeGroup: "A"
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一同优化并推动相关的技术的落地。