管理Kubernetes集群時需要關註的關鍵指標
有時我們在面對分布式系統工程時常感到痛苦。構建分布式系統真的很難，無論是哪個行業的企業，都希望我們在解決他們的業務問題的同時，還能考慮潛在的大規模業務問題。與大規模部署隨之而來的一大挑戰，是用戶還要考慮創建新特性和避免回檔。就算能夠非常出色地實現這些目標，用戶仍然會擔憂很多其他問題，例如信息是否安全、是否遵從法規，以及企業的這一投資是否真的有足夠價值。
如果上述描述和你的團隊現在的境況很像，而且你們的系統已經在生產環境中運行了，那麽恭喜你，你已經通過了第一輪考驗。
無論你多麽努力建立了一個出色的系統，有時意想不到的事還是會發生。有很多這樣的先例。一個傑出的產品，或者是病毒式應用，可能會帶來前所未有的成功，而成功之後你就會發現，原先你以為的、你的系統面對大規模應用時的處理方式，好像不適用了。
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。
管理Kubernetes集群時需要關註的關鍵指標