Kubernetes大集群怎麼管？基於監控的彈性伸縮方法
導語：我們通常使用Prometheus來對Kubernetes運行情況進行監控。並根據監控數據來擴容或者縮容。通常的擴/縮容都是根據內存或者CPU的使用，但是很多時候我們擴/縮容的依據通常是業務監控指標。如何根據業務監控指標來進行擴/縮容，本文作者給出了很優雅的方式。
Kubernetes自動彈性伸縮
自動彈性伸縮是一種基於資源使用情況自動彈性伸縮工作負載的方法。
Kubernetes的自動彈性伸縮有兩個維度：
處理node縮放操作的Cluster Autoscaler
自動彈性伸縮部署副本集Pod數量的Horizontal Pod Autoscaler（HPA）。
Cluster Autoscaling和Horizontal Pod Autoscaler（HPA）可用於動態調整計算能力以滿足系統SLA的要求。
雖然群集Cluster Autoscaler高度依賴雲提供程序的底層功能，但HPA可以獨立於IaaS / PaaS提供程序運行。
HPA的演變
Horizontal Pod Autoscaler功能首次在Kubernetes V1.1中引入，自那時起已經發展了很久。 HPA V1版本基於觀察到的CPU利用率和內存使用情況來自動伸縮POD。 在Kubernetes 1.6中引入了新的API自定義度量API，使HPA可以訪問任意度量標準。 最終，Kubernetes 1.7引入了聚合層，允許第三方應用程序通過將自己註冊為API附加組件來擴展Kubernetes API。
Custom Metrics API和聚合層使得Prometheus等監控系統可以向HPA控制器公開特定於應用的指標。
Horizontal Pod Autoscaler使用控制循環來實現功能，它定期查詢Resource Metrics API的核心度量標準，如CPU /內存和Custom Metrics API以獲取特定於應用程序的度量標準。
以下是關於為Kubernetes 1.9或更高版本配置HPA v2的指南：
安裝提供核心指標的Metrics Server插件。
使用demo應用根據CPU和內存使用情況展示pod自動調節。
部署Prometheus和一個自定義的API伺服器。 將自定義API伺服器註冊到聚合層。
demo應用程序使用自定義指標配置HPA。
在開始之前，您需要安裝Go 1.8或更高版本，並在您的GOPATH克隆k8s-prom-hpa[1]：
1. 設置Metrics server
Kubernetes Metrics Server[2]是一個集群範圍的資源使用數據聚合器，是Heapster[3]的繼任者。 Metrics Server通過彙集來自kubernetes.summary_api.數據來收集node和POD的CPU和內存使用情況。summary API是用於將數據從Kubelet / cAdvisor傳遞到Metrics Server的API(基於內存十分高效)。
如果在HPA的第一個版本中，您需要Heapster提供CPU和內存指標，但在HPA v2和Kubernetes 1.8中，只有啟用horizontal-pod-autoscaler-use-rest-clients時才需要Metrics Server。 Kubernetes 1.9默認啟用HPA rest 客戶端。 GKE 1.9預裝了Metrics Server。
在kube-system命名空間中部署Metrics Server：
一分鐘後， metric-server開始報告node和POD的CPU和內存使用情況。
查看node指標：
查看pods指標：
2.基於CPU和內存使用情況的Auto Scaling
我們將使用一個基於Golang的小型Web應用程序來測試Horizontal Pod Autoscaler（HPA）。
將podinfo[4]部署到default名稱空間：
使用http://:31198.上的NodePort服務訪問podinfo。
接下來定義一個保持最少兩個副本的HPA，如果CPU平均值超過80％或內存超過200Mi，則可擴展到10：
創建HPA：
幾秒鐘後，HPA控制器聯繫Metrics Server，然後獲取CPU和內存使用情況：
為了增加CPU壓力，使用rakyll / hey運行負載測試：
暫時刪除podinfo。 稍後將在本教程中再次部署它：
3.設置自定義Metrics Server
為了根據自定義指標進行縮放，您需要兩個組件。 一個從您的應用程序收集指標並將它們存儲在Prometheus[5]時間序列資料庫中。 第二個組件使用collect， k8s-prometheus適配器[6]提供的度量標準擴展Kubernetes自定義指標API。
您將在專用命名空間中部署Prometheus和適配器。
創建monitoring名稱空間：
在monitoring命名空間中部署Prometheus v2：
生成Prometheus適配器所需的TLS證書：
部署Prometheus自定義指標API適配器：
列出Prometheus提供的自定義指標：
獲取monitoring命名空間中所有POD的FS使用情況：
4.基於自定義指標的Auto Scaling
在default命名空間中創建podinfoNodePort服務並部署：
podinfo應用程序公開名為http_requests_total的自定義指標。 Prometheus適配器移除_total後綴並將度量標記為計數器度量。
從自定義指標API獲取每秒的總請求數：
m代表milli-units，例如， 901m 意味著901 milli-requests （就是大約0.9個請求）。
創建一個HPA，如果請求數量超過每秒10個，將增加podinfo：
在default名稱空間中部署podinfoHPA：
幾秒鐘後，HPA從度量API獲取http_requests值：
以每秒25個請求的速度為podinfo服務加壓：
幾分鐘後，HPA開始增加POD數量：
按照目前每秒的請求速度，部署將永遠不會達到10個POD的最大值。 三個副本足以使每個POD的RPS保持在10以下。
負載測試完成後，HPA會將部署縮減為其初始副本數量：
您可能已經注意到自動調節器不會立即響應峰值。 默認情況下，指標同步每30秒一次。 如果在最近3-5分鐘內沒有重新縮放，才能進行擴容/縮容。這確保了HP以防止衝突決策快速執行，並為Cluster Autoscaler提供了時間。
結論
並非所有系統都可以通過單獨依靠CPU /內存使用量度來滿足其SLA，但大多數Web和移動後端均需要基於每秒請求數來對任何流量突發進行處理。
對於ETL應用程序，自動彈性伸縮可能由作業隊列長度超過某個閾值引發，等等。
通過使用Prometheus提供的適用於自動彈性伸縮的指標，您可以微調應用程序以更好地處理突發事件並確保高可用性。
參考鏈接
[1] https://github.com/stefanprodan/k8s-prom-hpa
[2] https://github.com/kubernetes-incubator/metrics-server
[3] https://github.com/kubernetes/heapster
[4] https://github.com/stefanprodan/k8s-podinfo
[5] https://prometheus.io
[6] https://github.com/DirectXMan12/k8s-prometheus-adapter
TAG:高可用架構 |