使用 Sematext 進行 Kubernetes 容器日誌記錄和監控

容器中的微服務管理通常透過叢集管理器和編排工具完成。每個容器平臺都有略微不同的選項集來部署容器或在每個叢集節點上排程任務。由於我們在 Sematext 進行容器監控和日誌記錄，我們的工作一部分是分享我們對這些工具的知識，尤其是在容器可觀察性和 DevOps 方面。今天我們將展示一個關於 Kubernetes 容器監控和日誌收集的教程。

動態部署需要動態監控

容器和微服務生命週期的高度自動化使得 Kubernetes 的監控比傳統的、更靜態的部署更具挑戰性。任何用於監控特定應用容器的靜態設定都無法工作，因為 Kubernetes 會根據定義的部署規則做出自己的決策。不僅需要監控已部署的微服務，監控 Kubernetes 核心服務（例如執行 etcd、controller-manager、scheduler 和 apiserver 的 Kubernetes Master 以及執行 kubelet 和代理服務的 Kubernetes Worker（以前稱為 minion））的指標和日誌同樣重要。擁有一個集中式位置來關注所有這些服務、它們的指標和日誌有助於發現叢集基礎設施中的問題。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 應用程式，每個應用程式都有自己的令牌。Sematext Docker Agent README列出了所有配置（例如，過濾特定 pod/映象/容器），但我們在這裡將保持簡單。

• 獲取最新的 sematext-agent-daemonset.yml（原始純文字）模板（如下所示）
• 將其儲存在磁碟上的某個位置
• 將 SPM_TOKEN 和 LOGSENE_TOKEN 佔位符替換為您的 SPM 和 Logsene App 令牌

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

以 DaemonSet 執行 Agent

使用 _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 App 中，該 App 在多個級別聚合指標

• 叢集 - 在 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、代理、API 伺服器）透過 Docker 部署，Sematext Docker Agent 也會收集 Kubernetes 核心元件的日誌。

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

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

• 自動格式檢測和日誌解析

  • Sematext Docker Agent 包含識別和解析許多日誌格式的模式

• 特定映象和應用程式型別的自定義模式定義

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

• 過濾日誌，例如排除嘈雜的服務

• 特定日誌欄位中的敏感資料掩碼（電話號碼、支付資訊、身份驗證令牌）

• 基於日誌的警報和定期報告

• Kibana 或 Grafana 等工具中結構化日誌的分析

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

• 下載 Kubernetes
• 在 GitHub 上參與 Kubernetes 專案
• 在 Stack Overflow 上提問（或回答問題）
• 在 Slack 上與社群聯絡
• 在 Twitter 上關注我們 @Kubernetesio 獲取最新更新

• ←上一篇
• 下一篇→