管理Kubernetes集羣時須要關注的關鍵指標

歷經重重考驗，系統在生產環境中成功落地以後，可能依然面臨系統沒法適用大規模應用的挑戰，所以咱們須要對K8s集羣的關鍵指標進行追蹤。Rancher 資深解決方案架構師將在本文中介紹須要追蹤的內容及其緣由，讓您在面對問題時有所準備。

---

有時咱們在面對分佈式系統工程時常感到痛苦。構建分佈式系統真的很難，不管是哪一個行業的企業，都但願咱們在解決他們的業務問題的同時，還能考慮潛在的大規模業務問題。與大規模部署隨之而來的一大挑戰，是用戶還要考慮建立新特性和避免回檔。就算可以很是出色地實現這些目標，用戶仍然會擔心不少其餘問題，例如信息是否安全、是否聽從法規，以及企業的這一投資是否真的有足夠價值。

若是上述描述和你的團隊如今的境況很像，並且大家的系統已經在生產環境中運行了，那麼恭喜你，你已經經過了第一輪考驗。

不管你多麼努力創建了一個出色的系統，有時意想不到的事仍是會發生。有不少這樣的先例。一個傑出的產品，或者是病毒式應用，可能會帶來史無前例的成功，而成功以後你就會發現，原先你覺得的、你的系統面對大規模應用時的處理方式，好像不適用了。

Pokemon Go雲數據存儲的每秒處理數（預期vs實際）

這一狀況是可能發生的，而你也應該爲此作好準備。這也是本系列文章所要提到的。在本系列教程中咱們將向你介紹須要追蹤的內容，爲何追蹤它們，以及面對可能的根本緣由時須要作的緩解處理。

咱們會介紹每一種指標、追蹤它的方法以及你能夠對應採起的措施。咱們將使用不一樣的工具收集和分析這些數據。教程不會涉及到太多細節的內容，但會提供拓展連接，讓你們能夠獲取更多信息。話很少說，讓咱們開始吧。

Metrics：用於監控，不止監控

這一系列文章主要關注的是如何監控和運行Kubernetes集羣。使用日誌是一個不錯的方法，但在大規模部署的狀況下，日誌在過後分析工做中可能有很大做用，卻難以在過程之中不斷警告運維人員那些正在出現的愈來愈嚴重的問題。Metrics Server能夠監控容器的CPU和內存使用狀況，以及容器所運行在的節點的狀況。

這讓運維人員可以設置並監控KPI（關鍵績效指標）。這些運維定義層面的東西能夠爲運維團隊提供一種肯定應用程序或者節點什麼時候不健康的方法。同時也給他們提供了查看問題所須要的全部數據。

此外，Metrics Server

(https://kubernetes.io/docs/tasks/debug-application-cluster/core-metrics-pipeline/)容許Kubernetes啓用Horizontal Pod Autoscaling

(https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/)。該功能可讓Kubernetes在擴展pod實例數量時，是基於Kubernetes Metrics API報告的指標以及這些指標反映出來的API對象數量來進行擴展的。

在Rancher Kubernetes集羣中設置Metrics Server

從Kubernetes 1.8版本開始，Metrics Server以Kubernetes Monitoring Architecture

(https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/monitoring_architecture.md) 插件的方式成爲了拉取容器指標的標準。在該標準出現以前，默認使用的是Heapster，如今已經棄用，而開始支持Metrics Server。

很快，Metrics Server就將能夠在Rancher 2.0配置的Kubernetes集羣上運行了。您能夠在Rancher的Github repo中查看Rancher 2.0最新版本的發佈動態，一塊兒期待：https://github.com/rancher/rancher/releases。

若是想讓Metric Server工做，你必須經過Rancher Server API修改集羣的定義。這樣能夠容許Rancher服務器修改Kubelet以及KubeAPI參數，讓它們包含Metrics Server正常運行所須要的標記。

有關如何在Rancher Provisioned集羣上執行這一操做，以及修改其餘hyperkube-based集羣的說明，能夠參考github的這一連接：https://github.com/JasonvanBrackel/metrics-server-on-rancher-2.0.2。