Kubernetes 容器日誌記錄和監控與 Sematext

在容器中管理微服務通常是使用叢集管理器和編排工具完成的。每個容器平台都有一組略有不同的選項，可以在每個叢集節點上部署容器或排程任務。由於我們在 Sematext 進行 容器監控和日誌記錄，因此我們的工作之一是分享我們對這些工具的知識，特別是關於容器可觀察性和開發運維方面的知識。今天，我們將展示一個關於 Kubernetes 上的容器監控和日誌收集的教學。

動態部署需要動態監控

容器和微服務生命週期的高度自動化使得 Kubernetes 的監控比更傳統、更靜態的部署更具挑戰性。任何監控特定應用程式容器的靜態設定都將無法運作，因為 Kubernetes 會根據定義的部署規則做出自己的決策。不僅需要監控已部署的微服務。同樣重要的是監看 Kubernetes 核心服務本身的指標和日誌，例如運行 etcd、controller-manager、scheduler 和 apiserver 的 Kubernetes Master，以及運行 kubelet 和代理服務的 Kubernetes Worker (以前稱為 minions)。有一個集中的地方可以關注所有這些服務、它們的指標和日誌，這有助於發現叢集基礎架構中的問題。Kubernetes 核心服務可以安裝在裸機、虛擬機器中，或作為使用 Docker 的容器。在容器中部署 Kubernetes 核心服務可能有助於部署和監控操作 - 容器監控工具將涵蓋核心服務和應用程式容器。那麼，如何監控如此複雜和動態的環境呢？

Kubernetes 指標和日誌的代理程式

有許多 開源 Docker 監控和日誌記錄專案 可以組合在一起，以建構監控和日誌收集系統 (或系統)。優點是程式碼都是免費的。缺點是這需要時間 - 無論是在初始設定時還是在後續維護時。這就是我們建構 Sematext Docker Agent 的原因 - 一個現代、Docker 感知的指標、事件和日誌收集代理程式。它作為一個微小的容器在每個 Docker 主機上運行，並收集所有叢集節點和所有容器的日誌、指標和事件。它發現所有容器 (一個 Pod 可能包含多個容器)，包括用於 Kubernetes 核心服務的容器 (如果核心服務部署在 Docker 容器中)。讓我們看看如何部署這個代理程式。

**將代理程式部署到所有 Kubernetes 節點**

Kubernetes 提供 DaemonSets，它可以確保在節點新增到叢集時，Pod 也會新增到節點。我們可以利用這個功能輕鬆地將 Sematext Agent 部署到每個叢集節點！
為 Kubernetes 設定 Sematext Docker Agent
假設您已經為您的 Kubernetes 指標和事件建立了一個 SPM 應用程式，並為您的 Kubernetes 日誌建立了一個 Logsene 應用程式，每個應用程式都有自己的 Token。Sematext Docker Agent README 列出了所有設定 (例如，特定 Pod/映像/容器的篩選器)，但我們在這裡將保持簡單。

• 抓取最新的 sematext-agent-daemonset.yml (原始純文字) 範本 (也如下所示)
• 將其儲存到磁碟上的某個位置
• 將 SPM_TOKEN 和 LOGSENE_TOKEN 預留位置替換為您的 SPM 和 Logsene 應用程式 Token

apiVersion: extensions/v1beta1  
kind: DaemonSet  
metadata:  
  name: sematext-agent  
spec:  
  template:  
    metadata:  
      labels:  
        app: sematext-agent  
    spec:  
      selector: {}  
      dnsPolicy: "ClusterFirst"  
      restartPolicy: "Always"  
      containers:  
      - name: sematext-agent  
        image: sematext/sematext-agent-docker:latest  
        imagePullPolicy: "Always"  
        env:  
        - name: SPM\_TOKEN  
          value: "REPLACE THIS WITH YOUR SPM TOKEN"  
        - name: LOGSENE\_TOKEN  
          value: "REPLACE THIS WITH YOUR LOGSENE TOKEN"  
        - name: KUBERNETES  
          value: "1"  
        volumeMounts:  
          - mountPath: /var/run/docker.sock  
            name: docker-sock  
          - mountPath: /etc/localtime  
            name: localtime  
      volumes:  
        - name: docker-sock  
          hostPath:  
            path: /var/run/docker.sock  
        - name: localtime  
          hostPath:  
            path: /etc/localtime

將 Agent 作為 DaemonSet 運行

使用 kubectl 啟動 Sematext Agent Docker

\> kubectl create -f sematext-agent-daemonset.yml

daemonset "sematext-agent-daemonset" created

現在讓我們檢查代理程式是否已部署到所有節點

\> kubectl get pods

NAME                   READY     STATUS              RESTARTS   AGE

sematext-agent-nh4ez   0/1       ContainerCreating   0          6s

sematext-agent-s47vz   0/1       ImageNotReady       0          6s

狀態「ImageNotReady」或「ContainerCreating」可能會短暫可見，因為 Kubernetes 必須先下載 sematext/sematext-agent-docker 的映像。sematext-agent-daemonset.yml 中指定的設定 imagePullPolicy: "Always" 可確保 Sematext Agent 使用來自 Docker-Hub 的映像自動更新。

如果我們再次檢查，我們將看到 Sematext Docker Agent 已部署到 (所有) 叢集節點

\> kubectl get pods -l sematext-agent

NAME                   READY     STATUS    RESTARTS   AGE

sematext-agent-nh4ez   1/1       Running   0          8s

sematext-agent-s47vz   1/1       Running   0          8s

在部署後不到一分鐘，您應該會看到您的 Kubernetes 指標和日誌！以下是各種開箱即用報告的螢幕截圖以及各種指標含義的解釋。

Kubernetes 指標的解讀

來自所有 Kubernetes 節點的指標都收集在一個 SPM 應用程式中，該應用程式在多個層級聚合指標

• 叢集 - 在 SPM 總覽中顯示的所有節點上聚合的指標
• 主機/節點層級 - 每個節點聚合的指標
• Docker 映像層級 - 按映像名稱聚合的指標，例如所有 nginx Web 伺服器容器
• Docker 容器層級 - 單個容器聚合的指標

| | | 來自 Kubernetes 叢集的主機和容器指標 |

每個詳細圖表都有節點、Docker 映像和 Docker 容器的篩選選項。由於 Kubernetes 在 Docker 容器的名稱中使用 Pod 名稱，因此在 Docker 容器篩選器中按 Pod 名稱搜尋可以輕鬆選擇特定 Pod 的所有容器。

讓我們看看 SPM 提供的一些 Kubernetes (和 Docker) 關鍵指標。

主機指標，例如 CPU、記憶體和磁碟空間使用率。Docker 映像和容器比安裝在主機上的常規程序消耗更多的磁碟空間。例如，應用程式映像可能包含 Linux 作業系統，並且大小可能為 150-700 MB，具體取決於基礎映像的大小和容器中安裝的工具。資料容器也消耗主機上的磁碟空間。根據我們的經驗，監看磁碟空間並使用清理工具對於 Docker 主機的持續運作至關重要。

容器計數 - 表示每個主機運行的容器數量

| | | 每個 Kubernetes 節點的容器計數器隨時間變化 |

容器記憶體和記憶體失敗計數器。這些指標對於監看和調整應用程式非常重要。記憶體限制應符合已部署 Pod (應用程式) 的佔用空間，以避免 Kubernetes 使用預設限制 (例如，為命名空間定義的限制) 的情況，這可能會導致容器的 OOM 終止。記憶體失敗計數器反映容器中失敗的記憶體分配數量，並且在發生 OOM 終止的情況下，會觸發 Docker 事件。然後，此事件會顯示在 SPM 中，因為 Sematext Docker Agents 收集所有 Docker 事件。最佳實務是在幾個迭代中調整記憶體設定

• 監控應用程式容器的記憶體使用率
• 根據觀察設定記憶體限制
• 繼續監控記憶體、記憶體失敗計數器和記憶體不足事件。如果發生 OOM 事件，則可能需要增加容器記憶體限制，或需要進行偵錯以找出記憶體消耗過高的原因。

| | | 容器記憶體使用率、限制和失敗計數器 |

容器 CPU 使用率和受節流 CPU 時間。CPU 使用率可以透過 CPU 共享來限制 - 與記憶體不同，CPU 使用率不是硬性限制。只要資源可用，容器可能會使用更多 CPU，但在其他容器需要 CPU 的情況下，限制適用，並且 CPU 會被節流到限制。

還有更多 Docker 指標需要監看，例如磁碟 I/O 吞吐量、網路吞吐量和容器的網路錯誤，但接下來讓我們繼續查看 Kubernetes 日誌。

了解 Kubernetes 日誌

Kubernetes 容器的日誌與 Docker 容器日誌沒有太大區別。但是，Kubernetes 使用者需要查看已部署 Pod 的日誌。這就是為什麼擁有 Kubernetes 特定的資訊可用於日誌搜尋非常有用，例如

• Kubernetes 命名空間
• Kubernetes Pod 名稱
• Kubernetes 容器名稱
• Docker 映像名稱
• Kubernetes UID

Sematext Docker Agent 從 Docker 容器名稱中提取此資訊，並使用上述資訊標記所有日誌。將這些資料提取到個別欄位中，可以非常輕鬆地監看已部署 Pod 的日誌、從日誌建立報告、在疑難排解時快速縮小到有問題的 Pod 等！如果 Kubernetes 核心元件 (例如 kubelet、proxy、API 伺服器) 是透過 Docker 部署的，則 Sematext Docker Agent 也會收集 Kubernetes 核心元件日誌。

| | | Logsene 中來自 Kubernetes 容器的所有日誌 |

Logsene 和 Sematext Docker Agent 還為您提供了許多其他有用的開箱即用功能，例如

• 自動格式偵測和日誌剖析

  • Sematext Docker Agent 包含用於識別和剖析多種日誌格式的模式

• 特定映像和應用程式類型的自訂模式定義

• 容器日誌的自動 Geo-IP 豐富化

• 篩選日誌，例如排除嘈雜的服務

• 遮罩特定日誌欄位中的敏感資料 (電話號碼、付款資訊、驗證 Token)

• 基於日誌的警報和排程報告

• 結構化日誌的分析，例如在 Kibana 或 Grafana 中

這些主題中的大多數都在我們的 Docker 日誌管理 文章中描述，並且也與 Kubernetes 日誌管理相關。如果您想了解更多關於 Docker 監控 的資訊，請閱讀我們的 部落格。

• 下載 Kubernetes
• 參與 GitHub 上的 Kubernetes 專案
• 在 Stack Overflow 上發布問題 (或回答問題)
• 在 Slack 上與社群聯繫
• 在 Twitter 上關注我們 @Kubernetesio 以獲取最新更新

• ←上一篇
下一篇→