當前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

Logging Operator - 优雅的云原生日志管理方案 (一)

發布時間：2024/3/24 编程问答 36 豆豆

生活随笔收集整理的這篇文章主要介紹了 Logging Operator - 优雅的云原生日志管理方案 (一) 小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

Logging Operator是BanzaiCloud下開源的一個云原生場景下的日志采集方案。之前小白轉載過崔大佬介紹的一篇文章，不過由于之前一直認為在單個k8s集群下同時管理Fluent bit和Fluentd兩個服務在架構上比較臃腫，便留下了一個不適用的初步印象。后來小白在一個在多租戶場景下對k8s集群的日志管理做方案時，發現將日志配置統一管理的傳統方式靈活性非常的弱。通常操作者會站在一個全局的角度，盡量的讓日志的配置做成模版來適配業務，久而久之模版就變得非常龐大且臃腫，對后續維護和接任者都帶來了不小挑戰。

直到這段時間研究了Logging Operator之后，發現原來用Kubernetes的方式管理日志是非常愜意的一件事情。在開啟之前我們先來看看它的架構。

可以看到Logging Operator利用CRD的方式介入了日志從采集、路由、輸出這三個階段的配置。它本質上來說還是利用DaemonSet和StatefulSet在集群內分別部署了FluentBit和Fluentd兩個組件，FluentBit將容器日志采集并初步處理后轉發給Fluentd做進一步的解析和路由，最終由Fluentd將日志結果轉發給不同的服務。

所以服務容器化后，日志的輸出標準到底是該打印到標準輸出還是落盤到文件，我們可以討論下。

除了管理日志工作流外，Logging Operator還可以讓管理者開啟TLS來加密日志在集群內部的網絡傳輸，以及默認集成了ServiceMonitor來暴露日志采集端的狀態。當然最重要的還是由于配置CRD化，我們的日志策略終于可以實現在集群內的多租戶管理了。

1.Logging Operator CRD

整個Logging Operator的核心CRD就只有5個，它們分別是

logging：用于定義一個日志采集端(FleuntBit)和傳輸端(Fleuntd)服務的基礎配置；
flow：用于定義一個namespaces級別的日志過濾、解析和路由等規則。
clusterflow：用于定義一個集群級別的日志過濾、解析和路由等規則。
output：用于定義namespace級別的日志的輸出和參數；
clusteroutput：用于定義集群級別的日志輸出和參數，它能把被其他命名空間內的flow關聯；

通過這5個CRD，我們就可以自定義出一個Kubernetes集群內每個命名空間中的容器日志流向

2.Logging Operator 安裝

Logging Operator 依賴Kuberentes1.14之后的版本，可以分別用helm和mainfest兩種方式安裝。

Helm(v3.21.0+)安裝

$ helm repo add banzaicloud-stable https://kubernetes-charts.banzaicloud.com$ helm repo update$ helm upgrade --install --wait --create-namespace --namespace logging logging-operator banzaicloud-stable/logging-operator \--set createCustomResource=false"

Mainfest安裝

$ kubectl create ns logging# RBAC $ kubectl -n logging create -f https://raw.githubusercontent.com/banzaicloud/logging-operator-docs/master/docs/install/manifests/rbac.yaml# CRD $ kubectl -n logging create -f https://raw.githubusercontent.com/banzaicloud/logging-operator/master/config/crd/bases/logging.banzaicloud.io_clusterflows.yaml $ kubectl -n logging create -f https://raw.githubusercontent.com/banzaicloud/logging-operator/master/config/crd/bases/logging.banzaicloud.io_clusteroutputs.yaml $ kubectl -n logging create -f https://raw.githubusercontent.com/banzaicloud/logging-operator/master/config/crd/bases/logging.banzaicloud.io_flows.yaml $ kubectl -n logging create -f https://raw.githubusercontent.com/banzaicloud/logging-operator/master/config/crd/bases/logging.banzaicloud.io_loggings.yaml $ kubectl -n logging create -f https://raw.githubusercontent.com/banzaicloud/logging-operator/master/config/crd/bases/logging.banzaicloud.io_outputs.yaml# Operator $ kubectl -n logging create -f https://raw.githubusercontent.com/banzaicloud/logging-operator-docs/master/docs/install/manifests/deployment.yaml

當安裝完成后，我們需要驗證下服務的狀態

# Operator狀態 $ kubectl -n logging get pods NAME READY STATUS RESTARTS AGE logging-logging-operator-599c9cf846-5nw2n 1/1 Running 0 52s# CRD狀態 $ kubectl get crd |grep banzaicloud.io NAME CREATED AT clusterflows.logging.banzaicloud.io 2021-03-25T08:49:30Z clusteroutputs.logging.banzaicloud.io 2021-03-25T08:49:30Z flows.logging.banzaicloud.io 2021-03-25T08:49:30Z loggings.logging.banzaicloud.io 2021-03-25T08:49:30Z outputs.logging.banzaicloud.io 2021-03-25T08:49:30Z

3.Logging Operator 配置

3.1 logging

LoggingSpec

LoggingSpec定義了收集和傳輸日志消息的日志基礎架構服務，其中包含Fluentd和Fluent-bit的配置。它們都部署在controlNamespace指定的命名空間內。一個簡單的樣例如下：

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

這份樣例告訴了Operator在logging命名空間內創建一個默認配置的日志服務，其中包含FluentBit和Fluentd兩個服務

當然實際上我們在生產環境上部署FluentBit和Fluentd不會只用默認的配置，通常我們要考慮很多方面，比如：

自定義鏡像
日志采集位點文件的數據持久化
Buffer數據持久化
CPU/內存資源限制
狀態監控
Fluentd副本數以及負載均衡
網絡參數優化
容器運行安全

好在Loggingspec里對上述支持得都比較全面，我們可以參考文檔來個性化定制自己的服務

小白挑幾個重要的字段說明下用途：

watchNamespaces

制定讓Operator監聽Flow和OutPut資源的命名空間，如果你是多租戶場景，且每個租戶都用logging定義了日志架構化，可以用watchNamespaces來關聯租戶的命名空間來縮小資源過濾范圍

allowClusterResourcesFromAllNamespaces

ClusterOutput和ClusterFlow這樣的全局資源默認只在controlNamespace關聯的命名空間中生效，如果在其他命名空間中定義都會被忽略，除非將allowClusterResourcesFromAllNamespaces設置為true

LoggingSpec描述文檔：https://banzaicloud.com/docs/one-eye/logging-operator/configuration/crds/v1beta1/logging_types/

FluentbitSpec

filterKubernetes

用來獲取日志的Kubernetes元數據的插件，使用樣例如下：

apiVersion: logging.banzaicloud.io/v1beta1 kind: Logging metadata:name: default-logging-simple spec:fluentd: {}fluentbit:filterKubernetes:Kube_URL: "https://kubernetes.default.svc:443"Match: "kube.*"controlNamespace: logging

也可以用disableKubernetesFilter將該功能禁止，樣例如下：

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

filterKubernetes描述文檔: https://banzaicloud.com/docs/one-eye/logging-operator/configuration/crds/v1beta1/fluentbit_types/#filterkubernetes

inputTail

定義FluentBit的日志tail采集配置，這里面有很多細節的參數來控制，小白直接貼現在在用的配置樣例：

apiVersion: logging.banzaicloud.io/v1beta1 kind: Logging metadata:name: default-logging-simple spec:fluentbit:inputTail:Skip_Long_Lines: "true"#Parser: dockerParser: criRefresh_Interval: "60"Rotate_Wait: "5"Mem_Buf_Limit: "128M"#Docker_Mode: "true"Docker_Mode: "false

如果Kubernetes集群的容器運行時是Containerd或這其他CRI，就需要把Parser改成cri，同時禁用Docker_Mode

inputTail描述文檔: https://banzaicloud.com/docs/one-eye/logging-operator/configuration/crds/v1beta1/fluentbit_types/#inputtail

buffers

定義了FluentBit的緩沖區設置，這個比較重要。由于FluentBit是以DaemonSet的方式部署在Kubernetes集群中，所以我們可以直接采用hostPath的卷掛載方式來給它提供數據持久化的配置，樣例如下：

apiVersion: logging.banzaicloud.io/v1beta1 kind: Logging metadata:name: default-logging-simple spec:fluentbit:bufferStorage:storage.backlog.mem_limit: 10Mstorage.path: /var/log/log-bufferbufferStorageVolume:hostPath:path: "/var/log/log-buffer"

bufferStorage描述文檔: https://banzaicloud.com/docs/one-eye/logging-operator/configuration/crds/v1beta1/fluentbit_types/#bufferstorage

positiondb

定義了FluentBit采集日志的文件位點信息，同理我們可以用hostPath方式支持，樣例如下：

apiVersion: logging.banzaicloud.io/v1beta1 kind: Logging metadata:name: default-logging-simple spec:fluentbit:positiondb:hostPath:path: "/var/log/positiondb"

image

提供自定義的FluentBit的鏡像信息，這里我強烈推薦使用FluentBit-1.7.3之后的鏡像，它修復了采集端眾多網絡連接超時的問題,它的樣例如下：

apiVersion: logging.banzaicloud.io/v1beta1 kind: Logging metadata:name: default-logging-simple spec:fluentbit:image:repository: fluent/fluent-bittag: 1.7.3pullPolicy: IfNotPresent

metrics

定義了FluentBit的監控暴露端口，以及集成的ServiceMonitor采集定義，它的樣例如下：

apiVersion: logging.banzaicloud.io/v1beta1 kind: Logging metadata:name: default-logging-simple spec:fluentbit:metrics:interval: 60spath: /api/v1/metrics/prometheusport: 2020serviceMonitor: true

resources

定義了FluentBit的資源分配和限制信息，樣例如下：

apiVersion: logging.banzaicloud.io/v1beta1 kind: Logging metadata:name: default-logging-simple spec:fluentbit:resources:limits:cpu: "1"memory: 512Mirequests:cpu: 200mmemory: 128Mi

security

定義了FluentBit運行期間的安全設置，其中包含了PSP、RBAC、securityContext和podSecurityContext。他們共同組成控制了FluentBit容器內的權限，它們的樣例如下：

apiVersion: logging.banzaicloud.io/v1beta1 kind: Logging metadata:name: default-logging-simple spec:fluentbit:security:podSecurityPolicyCreate: trueroleBasedAccessControlCreate: truesecurityContext:allowPrivilegeEscalation: falsereadOnlyRootFilesystem: truepodSecurityContext:fsGroup: 101

性能參數

這里面定義了FluentBit的一些運行性能方面的參數，其中包含：

1.開啟forward轉發上游應答相應

apiVersion: logging.banzaicloud.io/v1beta1 kind: Logging metadata:name: default-logging-simple spec:fluentbit:forwardOptions:Require_ack_response: true

2.TCP連接參數

apiVersion: logging.banzaicloud.io/v1beta1 kind: Logging metadata:name: default-logging-simple spec:fluentbit:network:connectTimeout: 30keepaliveIdleTimeout: 60

3.開啟負載均衡模式

apiVersion: logging.banzaicloud.io/v1beta1 kind: Logging metadata:name: default-logging-simple spec:fluentbit:enableUpstream: true

4.調度污點容忍

apiVersion: logging.banzaicloud.io/v1beta1 kind: Logging metadata:name: default-logging-simple spec:fluentbit:tolerations:- effect: NoSchedulekey: node-role.kubernetes.io/master

FluentdSpec

buffers

這里主要定義Fluentd的buffer數據持久化配置，由于Fluentd是以StatefulSet的方式部署的，所以我們用hostPath就不太合適，這里我們應該用PersistentVolumeCliamTemplate的方式為每一個fluentd實例創建一塊專門的buffer數據卷，樣例如下：

apiVersion: logging.banzaicloud.io/v1beta1 kind: Logging metadata:name: default-logging-simple spec:fluentd:bufferStorageVolume:pvc:spec:accessModes:- ReadWriteOnceresources:requests:storage: 50GistorageClassName: csi-rbdvolumeMode: Filesystem

這里如果不指定storageClassName的話，Operator將通過StorageClass為default的存儲插件創建pvc

FluentOutLogrotate

定義了Fluentd的標準輸出重定向到文件配置，這主要是為了避免在出現錯誤時Fluentd產生連鎖反應，并且錯誤消息作為日志消息返回系統生成另一個錯誤，樣例如下：

apiVersion: logging.banzaicloud.io/v1beta1 kind: Logging metadata:name: default-logging-simple spec:fluentd:fluentOutLogrotate:enabled: truepath: /fluentd/log/outage: 10size: 10485760

這里表達的意思就是將fluentd日志重定向到/fluentd/log/out目錄，同時保留10天，文件最大不超過10M

FluentOutLogrotate描述文檔：https://banzaicloud.com/docs/one-eye/logging-operator/configuration/crds/v1beta1/fluentd_types/#fluentoutlogrotate

Scaling

這里主要定義fluentd的副本數，如果FluentBit開啟UpStraem的支持，調整Fluentd的副本數會導致FluentBit滾動更新，它的樣例如下：

apiVersion: logging.banzaicloud.io/v1beta1 kind: Logging metadata:name: default-logging-simple spec:fluentd:scaling:replicas: 4

scaling描述文檔： https://banzaicloud.com/docs/one-eye/logging-operator/configuration/crds/v1beta1/fluentd_types/#fluentdscaling

Worker

這里定義了Fluentd內部的Worker數量，由于Fluentd受限于ruby，它還是以單進程的方式處理日志工作流，增加worker數可以顯著提高Fluentd的并發，樣例如下：

apiVersion: logging.banzaicloud.io/v1beta1 kind: Logging metadata:name: default-logging-simple spec:fluentd:workers: 2

當Worker數大于1時，Operator-3.9.2之前的版本，對Fluentd的buffer數據持久化存儲不夠友好，可能會造成Fluentd容器Crash

image

定義了Fluentd的鏡像信息，這里必須要用Logging Operator定制的鏡像，可以自定義鏡像版本，結構和FluetnBit類似。

security

定義了Fluentd運行期間的安全設置，其中包含了PSP、RBAC、securityContext和podSecurityContext，結構和FluentBit類似。

metrics

定義了Fluentd的監控暴露端口，以及集成的ServiceMonitor采集定義，結構和FluentBit類似。

resources

定義了Fluentd的資源分配和限制信息，結構和FluentBit類似。

階段性總結

本文介紹了Logging Operator的架構、部署和CRD的相關內容，同時詳細描述了logging的定義和重要參數。當我們要將Operator用于生產環境采集日志時，它們會變得非常重要，請讀者在使用前一定好好參考文檔。

由于Logging Opeator的內容非常多，我將在后面幾期更新Flow、ClusterFlow、Output、ClusterOutput以及各種Plugins的使用，請大家持續關注

微信關注公眾號「云原生小白」，回復【入群】進入Loki學習群

總結

以上是生活随笔為你收集整理的Logging Operator - 优雅的云原生日志管理方案 (一)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。