Kubernetes集群監控詳解

介 紹

Kubernetes在Github上擁有超過4萬顆星，7萬以上的commits，以及像Google這樣的主要貢獻者。Kubernetes可以說已經快速地接管了容器生態系統，成為了容器編排平臺中的真正領頭羊。

理解Kubernetes和它的Abstractions

在基礎設施層，Kubernetes集群好比是一組扮演特定角色的物理或虛擬機器。其中扮演Master角色的機器作為全部操作的大腦，并由運行在節點上的編排容器控制。

• Master組件管理pod的生命周期，pod是Kubernetes集群中部署的基本單元。pod完成周期，Controller會創建一個新的。如果我們向上或向下（增加減少）Pod副本的數量，Controller會相應的創建和銷毀pod來滿足請求。Master角色包含了下面組件：

°kube-apiserver – 為其他master組件提供APIs

°etcd – 具有一致性且高可用的key/value存儲，用于存儲所有內部集群數據

°kube-scheduler – 使用pod規范中的信息來確定運行pod的節點

°kube-controller-manager – 負責節點管理（檢測節點是否失敗）、pod復制和端點創建

°cloud-controller-manager – 運行與底層云提供商交互的controller

• Node組件是Kubernetes中的worker機器，由Master來管理。一個節點可能表示未一個虛擬機（VM）或者物理機，而Kubernetes都可以在它們上面運行。每個節點都包含了運行pods所需要的組件：

°kubelet:處理Master和運行它的節點之間的所有通信。它在使用container runtime時提供接口來部署和監視容器。

° kube-proxy:維護主機上的網絡規則，處理在pods、host和外部世界之間包的傳輸。

°container runtime:負責在host上運行容器。雖然Kubernetes支持來自rkt、runc以及其他各式的container runtime，當下最流行的引擎還是Docker。

從邏輯層面來看，Kubernetes部署由各種組件組成，每個組件在集群中提供的服務都有特定的目的。

• Pods是Kubernetes部署時的基本單元。一個pod由一個或者多個共享相同網絡命名空間和IP地址的容器組成。最佳實踐推薦我們為每個應用程序創建一個pod，這樣你就可以分別擴展和控制它們。

• Services設置在pods集合之前，給它們提供一致的IP地址以及一套策略用來控制對它們的訪問。Service所針對的pod集合通常由label selector（標簽選擇器）決定。這樣在升級或者藍/綠部署期間很容易就讓Service指向不同的pod集合。

• ReplicaSets由部署控制，并確保運行該部署所需要的pods數量。

• Namespaces為諸如pods和services資源定義了一個邏輯命名空間。它們允許資源使用相同的名稱，而單個命名空間中的資源名稱必須唯一。Rancher使用命名空間和機遇角色的訪問控制，為命名空間和其中運行的資源之間提供安全隔離。

• Metadata根據容器的部署特性來標記容器。

監控Kubernetes

多個服務和命名空間可以跨基礎設施分布。就像上面所說，每個服務都是由pods組成，而pod可以包含一個或多個容器。有了如此多的移動部件，即便是監控一個小型的Kubernetes集群也會帶來挑戰。為了高效地監控它，這就需要深入了解應用程序體系結構和功能。

Kubernetes提供了用于監控集群的工具：

• Probes能積極地監控容器的健康狀態。如果Probe檢測到容器不健康，那么它就會重啟容器。

• cAdvisor是一個開源代理，它監控資源的使用情況并分析容器的性能。cAdvisor最初由Google創建，現在已經和Kubelet集成。它能夠收集、聚合、處理和導出在給定節點上運行的所有勇氣的度量指標，比如CPU、內存、文件和網絡的使用情況。

• kubernetes dashboard（儀表板）是一個附加組件，它能提供集群上運行的資源的概述信息。此外還提供了非常基本的方法來部署這些資源并和它們交互。

Kubernetes由從故障中自動回復的強大能力。如果進程發生崩潰，它可以重新啟動pods，如果節點出現錯誤，它能重新分配pods。然而，盡管有如此能力，還是會有不能解決問題的情況。為了檢測到這些情況，我們還需要額外的監控。

監控的層次

基礎設施

服務器級別的問題會在工作負載中出現，因此所有集群都應該監控底層服務器組件

監控什么

CPU利用率。監控CPU既能顯示系統和用戶的開銷，也能顯示iowait。擋在云中或者任何網絡存儲中運行集群時，iowait會提示存儲讀寫（i/o過程）的瓶頸等待時間。超額訂閱的存儲框架會影響性能。

內存使用情況。監控內存可以顯示出有多少內存在使用，以及有多少可用內存，可用內存可以是空閑內存，也可以是緩存。出現內存限制的系統會開始進行交換（swap），交換會迅速降低性能。

磁盤壓力。如果系統正在運行諸如etcd或者任何數據存儲這樣的寫入密集型服務時，如果磁盤空間耗盡，那將是災難性的問題。不能寫入數據會出現崩潰，而這種崩潰會轉化為真實世界的損失。有了像LVM這樣的技術，就能很容易地根據需要增加磁盤空間，但是盡管如此還是要監控它。

網絡帶寬。在當今千兆接口的時代，似乎帶寬永遠都不會耗盡。然而，僅僅是出現一些異常的服務、數據泄漏、系統損壞或者DOS***，就可能耗盡所有的帶寬導致停機。如果了解自己的正常數據使用情況和應用程序的模式，就能有效降低成本，有助于規劃容量。

Pod資源。如果能知道pod需要什么資源的話，Kubernetes調度器就能最大化發揮作用。它可以確保在可用的節點上放置pod。在設計網絡時，為了避免剩余節點無法運行所有所需的資源的情況，需要預先考慮有多少節點可能會失敗。使用云自動伸縮組之類的服務可以快速恢復，但要確保其余節點在失敗節點恢復回來之前，能夠處理增加的負載。

Kubernetes服務

組成Kubernetes Master或者Worker的所有組件（包括etcd）都對應用程序的健康運行至關重要。如果其中任何一個出現失敗，監控系統就需要檢測失敗，修復它并且發送警告。

內部服務

最后一層是Kubernetes資源本身。Kubernetes公開了關于資源的度量，我們還可以直接監控應用程序。雖然Kubernetes會盡力維持理想的狀態，但如果它無能為力的話，我們就需要一種由人類干預和解決問題的方法了。

用Rancher來監控

除了管理運行在任何提供者上、任何位置的Kubernetes集群外，Rancher還會監控這些集群中運行的資源，并在資源超過定義的閾值時發送警報。

現在已經有許多關于如何部署Rancher的教程。如果你還沒有正在運行的集群，請先在這里暫停，進入我們的快速上手指南：https://rancher.com/quick-start/。等到集群正在運行了再返回到這里開始監控。

集群概述可以讓你了解正在使用的資源和Kubernetes組件的狀態。在我們的例子中，我們使用了78%的CPU、26%的RAM和11%的最大pod數量。

點擊Nodes選項卡，你可以看到關于運行在集群上每個節點的附加信息，點擊具體節點時，可以看到關于該成員的健康狀況。

Workloads選項卡顯示了運行在集群上的pods。如果你還沒有任何運行的pod，先發布一個運行nginx鏡像的工作負載，把它擴展成多個副本。

當需要選擇工作負載名稱時，Rancher會彈出一個顯示有關該工作負載的信息頁面。在頁面頂部，它展示了每個pod所運行的節點，pod的IP地址以及它們的狀態。點擊任何一個pod會看到更多內容，現在我們看到了關于該pod的詳細信息。右上角的漢堡菜單圖標能讓我們和pod交互，通過該圖標，我們可以執行shell、查看日志或者刪除pod。

Other選項卡展示了不同Kubernetes資源的信息，包括ingress或LoadBalancer類型的服務的Load Balancing，其他服務類型的Service Discovery以及在集群中配置卷的Volumes。

使用Prometheus監控

Rancher UI中可以看到的信息對故障排除非常有幫助，不過這并不是在集群生命周期的每一時刻積極追蹤集群狀態的最佳方法。我們將使用Prometheus，它是Kubernetes公司的一個兄弟項目，由Cloud Native Computing Foundation負責維護和運營。我們還將使用到Grafana工具，它能把時間序列數據轉換成漂亮的圖形和儀表板顯示。

Prometheus是一個用來監控系統和生成警報的開源應用程序。從服務器到應用程序、數據庫、甚至單個進程，它幾乎可以監控任何東西。在Prometheus的詞表中，它監控targets，目標的每個單位稱為metric。檢索關于目標信息的行為稱為scraping（抓取）。Prometheus將在指定的時間間隔內采集目標，并把信息存儲在時間序列數據庫中。Prometheus擁有自己的腳本語言PromQL。

Grafana也是開源的，可以作為Web應用程序運行。雖然它經常和Prometheus一起使用，但也支持后端數據存儲，如fluxDB、Graphite、Elasticsearch等等。Grafana可以很容易地創建圖形，并且把它們合并稱儀表板，而這些儀表板由一個強大的身份驗證和授權層保護，它們還可以和其他儀表板進行共享而不需要訪問服務器本身。Grafana在其對象定義中大量使用JSON，這樣它的圖形和儀表板都非常容易移植，并且版本控制非常方便。

在Rancher的應用程序目錄中已經同時包含了Prometheus和Grafana，我們只需點擊幾下鼠標就能部署它們了。

安裝Prometheus和Grafana

訪問集群的Catalog Apps頁面，搜索Prometheus。安裝它的同時還會安裝Grafana和AlertManager。對本文來說，所有內容都使用默認值就可以了，但如果考慮到生產部署，請閱讀Detailed Descriptions下的信息，看看圖表中有多少配置可供使用。

單擊Launch，Rancher將把應用程序部署到集群中，幾分鐘之后，你就能看到prometheus命名空間下所有工作負載處于Active狀態。

默認情況下使用了xip.io設置Layer7 ingress，我們可以在Load Balancing選項卡上看到它，單擊鏈接打開Grafana儀表板。

Prometheus的安裝還在Grafana中部署了幾個儀表板，因此我們可以馬上看到關于集群的信息，查看它的性能。

總 結

Kubernetes能盡可能保持應用程序的運行，但這并不說明我們就不需要了解應用程序運行的情況。當你開始使用Kubernetes工作時，還需要去部署監控系統，幫助你了解情況并作出決策。

Prometheus和Grafana將幫助你完成這一項工作，如果你使用了Rancher，那部署這兩個應用程序只需要短短幾分鐘。而在即將發布的Rancher 2.2中，配備了完全集成的Prometheus和Grafana，增強所有Kubernetes集群的可見性，同時確保不同項目與用戶之間的隔離。Rancher也因此成為唯一一個在多集群、多租戶環境中支持Prometheus的解決方案。

使用Prometheus監控Rancher管理的Kubernetes環境，只需要兩個步驟：

1. 選擇集群

2. 一鍵啟動監控

你可以在此了解如何更加簡單快速地在多Kubernetes集群和多租戶環境中使用Prometheus監控！