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監控！