監控 Kubernetes

當您開始在 Kubernetes 中管理應用程式效能時，第一件發現的事，就是操作起來很複雜。無論您多會監控傳統應用程式的效能，仍然很容易迷失在 Kubernetes 叢集中。

在 Kubernetes 中不僅有更多層需要監控，而且有鑑於應用程式資料隱藏在 Kubernetes 叢集中的方式，可能更難取得所需的資料。

為了幫助您開始使用 Kubernetes 效能管理，本文將說明您要監控哪些指標以及如何收集它們。我們不會逐一介紹 Kubernetes 應用程式效能管理的各種操作，因為單是一篇文章無法涵蓋這些篇幅，但我們將介紹您需要了解的基本知識，以便開始建立適用於 Kubernetes 的應用程式效能監控策略。

Kubernetes 應用程式監控 vs. Kubernetes 監控
在進一步討論之前，您需要了解一個基本概念，那就是您將需要在 Kubernetes 環境中進行兩種不同類型的效能監控。

第一是監控以容器或 Pod (它們是相互關聯的容器的集合) 形式在 Kubernetes 叢集中執行的應用程式。這就是我們將在下面介紹的內容。

第二是監控 Kubernetes 本身的效能，這意味著您必須監控構成 Kubernetes 的各種元件 (如 API 伺服器和 Kubelet 等)。觀察 Kubernetes 叢集本身是否健康的指標 (以及取得這些指標的方式)，與監控個別應用程式效能時需要注意的指標不同 (將於後續文章中介紹)。

您可以將它們的差別，看作是在傳統伺服器上監控作業系統效能和監控在伺服器上執行的應用程式之間的差異。在 Kubernetes 中，Kubernetes 是作業系統，部署在其上的容器或 Pod 是應用程式。顯然，Kubernetes 本身的效能會影響應用程式效能，但是環境的每一層都會產生不同類型的指標，並以不同的方式儲存它們。

Kubernetes 應用程式效能監控的指標
雖然聽起來可能讓人困惑，不過好消息是，您在 Kubernetes 中監控應用程式效能時收集的指標通常與您在傳統環境中收集的指標相同。

根據所管理的應用程式不同，這些指標也會不同，但它們一般都會包括以下資料：
• 請求速率。
• 回應時間。
• 錯誤率。
• 記憶體使用情況。
• CPU 使用率。
• 長期儲存使用情況。

通常來說，在 Kubernetes 中執行的應用程式若不是透過日誌檔輸出這些效能指標，就是將它們輸出到標準輸出和標準錯誤串流中，就如同它們是處於標準伺服器而不是在 Kubernetes 中執行一樣。

很容易，對吧？

Kubernetes 如何處理應用程式指標和日誌
嗯，情況不完全是那麼理想。當您在 Kubernetes 中真正收集應用程式效能指標時，事情會稍微複雜一些。

Kubernetes 和傳統伺服器之間的最大區別在於，在 Kubernetes 中，Pod 和容器寫入內部檔案系統的資料，在 Pod 或容器關閉時後不會永久儲存。資料就這樣不見了，除非您先將其收集並轉存至其他地方。

此外，Pod 和容器並不會將監控資料寫入到 Kubernetes 叢集中的單一位置。每個 Pod 或容器都是將日誌和事件資料儲存在不同的位置 (通常在其容器的內部檔案系統中)。這意味著 Kubernetes 並未提供一種使用單一介面或命令就能從所有應用程式彙整或查詢監控資料的方法。

換句話說，您不能簡單地在 Kubernetes 中執行 “tail /var/log/syslog” 之類的操作，然後就獲得所有相關的應用程式資料。

如何收集 Kubernetes 應用程式資料
幸運的是，我們仍然可以在 Kubernetes 中收集應用程式指標和日誌資料。只需要比在傳統伺服器環境多一些動作。

從 Kubernetes 取得應用程式監控資料的主要方法有兩種。一種是在 Kubernetes 叢集內的節點上部署日誌代理程式。這些節點是託管容器的個別伺服器。當容器將監控資料寫入內部檔案系統時，節點上執行的日誌代理程式就可以將這些資料提取出來，然後將其轉送到外部監控工具。如此一來，即使容器或 Pod 關閉，資料也能永久保存。

另一種方法是在 Kubernetes 中執行會託管日誌代理程式的 “sidecar” 容器。使用這種技術時，sidecar 容器會與其他您想要監控的容器在同一個 Pod 中執行，並從中收集監控資料。然後，它會將監控資料轉送到外部日誌記錄和監控系統。

第三種解決方案是在應用程式本身中建立處理機制，將監控資料直接匯出到外部日誌系統。但是，這種作法需要修改應用程式，所以與其他兩種技術相比，這種方法較不常使用。

如何監控 Kubernetes 叢集？
同樣地，為了管理應用程式效能的每一個方面，您還需要監控 Kubernetes 叢集本身的效能，並將該資料與來自各個應用程式的資料相關聯。這是知道因缺乏可用記憶體而回應緩慢的應用程式是否發生內部記憶體外洩，或者它是否在叢集層發生資源不足問題的唯一方法。

您還可以從 Kubernetes 主節點和工作節點上的作業系統日誌等來源收集這些資料。不過這個主題同樣超出本文的範圍。我們提到它是為了提醒大家，監控 Kubernetes 應用程式效能時也需要監控 Kubernetes 本身，而不僅僅是應用程式。

結論
在 Kubernetes 中監控應用程式對於新手來說似乎令人生畏。幸運的是，它與其他相關的應用程式監控並無太大分別。主要差異是應用程式資料在 Kubernetes 叢集中是如何產生的。此時，取得您需要的資料比過去習慣的作法難一點，但一旦您了解其中的架構，事情就不會那麼棘手了。

這是 Chris Tozzi 的客座部落格文章，他是 Fixate IO 的內容資深編輯和 DevOps 分析師。Chris Tozzi 曾擔任記者和 Linux 系統管理員。他對開放原始碼、敏捷式基礎架構和網路技術特別感興趣。他是 Fixate IO 的內容資深編輯和 DevOps 分析師。此貼文不代表 Splunk 的立場、策略或意見。

作者
Stephen Watts
Stephen Watts 在 Splunk 負責不斷成長的行銷工作。Stephen 擁有美國奧本大學的哲學學位，並是加州大學丹佛分校的準資訊管理碩士。他為各種出版品撰稿，包括 CIO.com、Search Engine Journal、ITSM.Tools、IT Chronicles、DZone 和 CompTIA。