Kubernetes叢集日誌詳解

導讀	伺服器和應用程式日誌記錄是開發人員、運維人員和安全團隊瞭解應用程式在其生產環境中執行狀態的重要工具。日誌記錄使運維人員能夠確定應用程式和所需元件是否執行平穩，並檢測是否發生了異常情況，以便他們能夠對這種情況做出反應。

對於開發人員，日誌記錄提供了在開發期間和之後對程式碼進行故障排除的可見性。在生產環境中，開發人員通常依賴於沒有除錯工具的日誌記錄工具。在加上系統的日誌記錄，開發人員可以與運維人員攜手合作，有效地解決問題。

日誌記錄工具最重要的受益者是安全團隊，尤其是在雲原生的環境中。能夠從應用程式和系統日誌中收集資訊使得安全團隊能夠分析來自身份驗證、應用程式訪問惡意軟體活動的資料，並在需要時進行響應。

Kubernetes是領先的容器平臺，越來越多的應用程式透過 Kubernetes 部署到生產環境。我相信瞭解 Kubernetes 的日誌架構是一項非常重要的工作，每個開發、運維和安全團隊都需要認真對待。

在本文中，小編將討論 Kubernetes 中不同容器日誌記錄模式的工作原理。

在深入研究 Kubernetes 日誌記錄架構之前，我想探索不同的日誌記錄方法以及這兩種功能如何成為 Kubernetes 日誌記錄的關鍵特性。

有兩種型別的系統元件：在容器中執行的元件和不在容器中執行的元件。例如：

1. Kubernetes 排程者和 kube-proxy 執行在容器中。

1. kubelet 和容器執行時不在容器中執行。

與容器日誌類似，系統容器日誌儲存在 /var/log 目錄中，你應該定期輪換它們。

在這裡，我研究的是容器日誌記錄。首先，我看一下叢集級別的日誌記錄以及為什麼它對叢集運維人員很重要。叢集日誌提供有關叢集如何執行的資訊。諸如為什麼 吊艙Pod 被下線或節點死亡之類的資訊。叢集日誌記錄還可以捕獲諸如叢集和應用程式訪問以及應用程式如何利用計算資源等資訊。總體而言，叢集日誌記錄工具為叢集運維人員提供操作叢集和安全有用的資訊。

捕獲容器日誌的另一種方法是透過應用程式的本機日誌記錄工具。現代應用程式設計很可能具有日誌記錄機制，可幫助開發人員透過標準輸出 (stdout) 和錯誤流 (stderr) 解決應用程式效能問題。

為了擁有有效的日誌記錄工具，Kubernetes 實現需要應用程式和系統日誌記錄元件。

如今，在大多數的 Kubernetes 實現中，你可以看到三種主要的叢集級日誌記錄方法。

1. 節點級日誌代理

1. 用於日誌記錄的挎鬥Sidecar容器應用程式

1. 將應用程式日誌直接暴露給日誌後端

我想考慮節點級日誌代理。你通常使用 DaemonSet 作為部署策略來實現這些，以便在所有 Kubernetes 節點中部署一個吊艙(充當日誌代理)。然後，該日誌代理被配置為從所有Kubernetes節點讀取日誌。你通常將代理配置為讀取節點 /var/logs 目錄捕獲 stdout/stderr 流並將其傳送到日誌記錄後端儲存。

下圖顯示了在所有節點中作為代理執行的節點級日誌記錄。

以使用 fluentd 方法為例設定節點級日誌記錄，你需要執行以下操作：

(1) 首先，你需要建立一個名為 fluentdd 的服務賬戶。Fluentd 吊艙使用此服務賬戶來訪問 Kubernetes API，你需要在日誌名稱空間中使用標籤 app: fluentd 建立它們：

#fluentd-SA.yaml 
apiVersion: v1 
kind: ServiceAccount 
metadata: 
  name: fluentd 
  namespace: logging 
  labels: 
    app: fluentd

你可以在此 倉庫 中檢視完整示例。

(2) 接著，你需要建立一個名稱為 fluentd-configmap 的 ConfigMap。這為 fluentd daemonset 提供了一個配置檔案，其中包含所有必需的屬性。

#fluentd-daemonset.yaml 
apiVersion: extensions/v1beta1 
kind: DaemonSet 
metadata: 
  name: fluentd 
  namespace: logging 
  labels: 
    app: fluentd 
    kubernetes.io/cluster-service: "true" 
spec: 
  selector: 
    matchLabels: 
      app: fluentd 
      kubernetes.io/cluster-service: "true" 
  template: 
    metadata: 
      labels: 
        app: fluentd 
        kubernetes.io/cluster-service: "true" 
    spec: 
      serviceAccount: fluentd 
      containers: 
      - name: fluentd 
        image: fluent/fluentd-kubernetes-daemonset:v1.7.3-debian-elasticsearch7-1.0 
        env: 
          - name: FLUENT_ELASTICSEARCH_HOST 
            value: "elasticsearch.logging.svc.cluster.local" 
          - name: FLUENT_ELASTICSEARCH_PORT 
            value: "9200" 
          - name: FLUENT_ELASTICSEARCH_SCHEME 
            value: "http" 
          - name: FLUENT_ELASTICSEARCH_USER 
            value: "elastic" 
          - name: FLUENT_ELASTICSEARCH_PASSWORD 
            valueFrom: 
              secretKeyRef: 
                name: efk-pw-elastic 
                key: password 
          - name: FLUENT_ELASTICSEARCH_SED_DISABLE 
            value: "true" 
        resources: 
          limits: 
            memory: 512Mi 
          requests: 
            cpu: 100m 
            memory: 200Mi 
        volumeMounts: 
        - name: varlog 
          mountPath: /var/log 
        - name: varlibdockercontainers 
          mountPath: /var/lib/docker/containers 
          readOnly: true 
        - name: fluentconfig 
          mountPath: /fluentd/etc/fluent.conf 
          subPath: fluent.conf 
      terminationGracePeriodSeconds: 30 
      volumes: 
      - name: varlog 
        hostPath: 
          path: /var/log 
      - name: varlibdockercontainers 
        hostPath: 
          path: /var/lib/docker/containers 
      - name: fluentconfig 
        configMap: 
          name: fluentdconf

你可以在此 倉庫 中檢視完整示例。

現在，我們來看看如何將 fluentd daemonset 部署為日誌代理的程式碼。

#fluentd-daemonset.yaml 
apiVersion: extensions/v1beta1 
kind: DaemonSet 
metadata: 
  name: fluentd 
  namespace: logging 
  labels: 
    app: fluentd 
    kubernetes.io/cluster-service: "true" 
spec: 
  selector: 
    matchLabels: 
      app: fluentd 
      kubernetes.io/cluster-service: "true" 
  template: 
    metadata: 
      labels: 
        app: fluentd 
        kubernetes.io/cluster-service: "true" 
    spec: 
      serviceAccount: fluentd 
      containers: 
      - name: fluentd 
        image: fluent/fluentd-kubernetes-daemonset:v1.7.3-debian-elasticsearch7-1.0 
        env: 
          - name: FLUENT_ELASTICSEARCH_HOST 
            value: "elasticsearch.logging.svc.cluster.local" 
          - name: FLUENT_ELASTICSEARCH_PORT 
            value: "9200" 
          - name: FLUENT_ELASTICSEARCH_SCHEME 
            value: "http" 
          - name: FLUENT_ELASTICSEARCH_USER 
            value: "elastic" 
          - name: FLUENT_ELASTICSEARCH_PASSWORD 
            valueFrom: 
              secretKeyRef: 
                name: efk-pw-elastic 
                key: password 
          - name: FLUENT_ELASTICSEARCH_SED_DISABLE 
            value: "true" 
        resources: 
          limits: 
            memory: 512Mi 
          requests: 
            cpu: 100m 
            memory: 200Mi 
        volumeMounts: 
        - name: varlog 
          mountPath: /var/log 
        - name: varlibdockercontainers 
          mountPath: /var/lib/docker/containers 
          readOnly: true 
        - name: fluentconfig 
          mountPath: /fluentd/etc/fluent.conf 
          subPath: fluent.conf 
      terminationGracePeriodSeconds: 30 
      volumes: 
      - name: varlog 
        hostPath: 
          path: /var/log 
      - name: varlibdockercontainers 
        hostPath: 
          path: /var/lib/docker/containers 
      - name: fluentconfig 
        configMap: 
          name: fluentdconf

將這些放在一起執行：

kubectl apply -f fluentd-SA.yaml \ 
              -f fluentd-configmap.yaml \ 
              -f fluentd-daemonset.yaml

另一種方法是使用帶有日誌代理的專用挎鬥容器。容器最常見的實現是使用 Fluentd 作為日誌收集器。在企業部署中(你無需擔心一點計算資源開銷)，使用 fluentd(或類似)實現的挎鬥容器提供了叢集級日誌記錄的靈活性。這是因為你可以根據需要捕獲的日誌型別、頻率和其它可能的調整來調整和配置收集器代理。

下圖展示了作為日誌代理的挎鬥容器。

Sidecar container as logging agent例如，一個吊艙執行單個容器，容器使用兩種不同的格式寫入兩個不同的日誌檔案。吊艙的配置檔案如下：

#log-sidecar.yaml 
apiVersion: v1 
kind: Pod 
metadata: 
  name: counter 
spec: 
  containers: 
  - name: count 
    image: busybox 
    args: 
   - /bin/sh 
    - -c 
    - > 
     i=0; 
      while true; 
      do 
        echo "$i: $(date)" >> /var/log/1.log; 
        echo "$(date) INFO $i" >> /var/log/2.log; 
        i=$((i+1)); 
        sleep 1; 
      done 
    volumeMounts: 
    - name: varlog 
      mountPath: /var/log 
  - name: count-log 
    image: busybox 
    args: [/bin/sh, -c, 'tail -n+1 -f /var/log/1.log'] 
    volumeMounts: 
    - name: varlog 
      mountPath: /var/log 
  volumes: 
  - name: varlog 
    emptyDir: {}

把它們放在一起，你可以執行這個吊艙：

$ kubectl apply -f log-sidecar.yaml

要驗證挎鬥容器是否用作日誌代理，你可以執行以下操作：

$ kubectl logs counter count-log

預期的輸出如下所示：

$ kubectl logs counter count-log-1 
Thu 04 Nov 2021 09:23:21 NZDT 
Thu 04 Nov 2021 09:23:22 NZDT 
Thu 04 Nov 2021 09:23:23 NZDT 
Thu 04 Nov 2021 09:23:24 NZDT

第三種方法(在我看來)是 Kubernetes 容器和應用程式日誌最靈活的日誌記錄解決方案，是將日誌直接推送到日誌記錄後端解決方案。儘管此模式不依賴於原生 Kubernetes 功能，但它提供了大多數企業需要的靈活性，例如：

1. 擴充套件對網路協議和輸出格式的更廣泛支援。

1. 提供負載均衡能力並提高效能。

1. 可配置為透過上游聚合接受複雜的日誌記錄要求。

因為這第三種方法透過直接從每個應用程式推送日誌來依賴非 Kubernetes 功能，所以它超出了 Kubernetes 的範圍。

Kubernetes 日誌記錄工具是企業部署 Kubernetes 叢集的一個非常重要的元件。我討論了三種可能的可用模式。你需要找到適合你需求的模式。

如上所述，使用 daemonset 的節點級日誌記錄是最容易使用的部署模式，但它也有一些限制，可能不適合你的組織的需要。另一方面，挎鬥 模式提供了靈活性和自定義，允許你自定義要捕獲的日誌型別，但是會提高計算機的資源開銷。最後，將應用程式日誌直接暴露給後端日誌工具是另一種允許進一步定製的誘人方法。

原文來自：