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