Kubernetes自動彈性伸縮可以根據業務流量，自動增加或減少服務。這一功能在實際的業務場景中十分重要。在本文中，我們將瞭解Kubernetes如何針對應用產生的自定義指標實現自動伸縮。
爲什麼需要自定義指標？
應用程序的CPU或RAM的消耗並不一定能夠正確表明是否需要進行擴展。例如，如果你有一個消息隊列consumer，它每秒可以處理500條消息而不會導致崩潰。一旦該consumer的單個實例每秒處理接近500條消息，你可能希望將應用程序擴展到兩個實例，以便將負載分佈在兩個實例上。測量CPU或RAM對於擴展這樣的應用程序來說有點矯枉過正了，你需要尋找一個與應用程序性質更爲密切相關的指標。一個實例在特定時間點處理的消息數量能更貼切地反映該應用的實際負載。同樣，可能有一些應用的其他指標更有意義。這些可以使用Kubernetes中的自定義指標進行定義。
Metrics流水線
Metrics Server和API
最初，這些指標會通過Heapster暴露給用戶，Heapster可以從每個kubelet中查詢指標。Kubelet則與localhost上的cAdvisor對話，並檢索出節點級和pod級的指標。Metric-server的引入是爲了取代heapster，並使用Kubernetes API來暴露指標從而以Kubernetes API的方式提供指標。Metric server僅提供核心的指標，比如pod和節點的內存和CPU，對於其他指標，你需要構建完整的指標流水線。構建流水線和Kubernetes自動伸縮的機制將會保持不變。
Aggregation Layer
能夠通過Kubernetes API層暴露指標的關鍵部分之一是Aggregation Layer。該aggregation layer允許在集羣中安裝額外的Kubernetes格式的API。這使得API像任何Kubernetes資源一樣可用，但API的實際服務可以由外部服務完成，可能是一個部署到集羣本身的Pod（如果沒有在集羣級別完成，你需要啓用aggregation layer）。那麼，這到底是如何發揮作用的呢？作爲用戶，用戶需要提供API Provider（比如運行API服務的pod），然後使用APIService對象註冊相同的API。
讓我們以核心指標流水線爲例來說明metrics server如何使用 API Aggregation layer註冊自己。APIService對象如下：
apiVersion: apiregistration.k8s.io/v1
kind: APIService
metadata:
name: v1beta1.metrics.k8s.io
spec:
service:
name: metrics-server
namespace: kube-system
group: metrics.k8s.io
version: v1beta1
insecureSkipTLSVerify: true
groupPriorityMinimum: 100
versionPriority: 100
部署使用APIService註冊API的metrics server之後，我們可以看到Kubernetes API中提供了指標API：
Metrics流水線：核心部分和完整流水線
我們已經瞭解了基本組件，讓我們把它們放在一起組成核心metrics流水線。在覈心流水線中，如果你已經恰當地安裝了metrics server，它也將創建APIService將自己註冊到Kubernetes API server上。正如我們在上一節中所瞭解到的那樣，這些指標將在/apis/metrics.k8s.io中暴露，並被HPA使用。
大部分複雜的應用程序需要更多的指標，而不僅僅是內存和CPU，這也是大多數企業使用監控工具的原因，最常見的監控工具有Prometheus、Datadog以及Sysdig等。而不同的工具所使用的格式也有所區別。在我們可以使用Kubernetes API聚合來暴露endpoint之前，我們需要將指標轉換爲合適的格式。此時需要使用小型的adapter（適配器）——它可能是監控工具的一部分，也可能作爲一個單獨的組件，它在監控工具和Kubernetes API之間架起了一座橋樑。例如，Prometheus有專門的Prometheus adapter或者Datadog有Datadog Cluster Agent — 它們位於監控工具和API之間，並從一種格式轉換到另一個種格式，如下圖所示。這些指標在稍微不同的endpoint都可以使用。
Demo：Kubernetes自動伸縮
我們將演示如何使用自定義指標自動伸縮應用程序，並且藉助Prometheus和Prometheus adapter。你可以繼續閱讀文章，或者直接訪問Github repo開始構建demo：
https://github.com/infracloudio/kubernetes-autoscaling
設置Prometheus
爲了讓適配器可以使用指標，我們將使用Prometheus Operator來安裝Prometheus。它創建CRD來在集羣中部署Prometheus的組件。CRD是擴展Kubernetes資源的一種方式。使用Operator可以“以Kubernetes的方式”（通過在YAML文件中定義對象）輕鬆配置和維護Prometheus實例。由Prometheus Operator創建的CRD有：
-
AlertManager
-
ServiceMonitor
-
Prometheus
你可以根據下方鏈接的指導設置Prometheus：
https://github.com/infracloudio/kubernetes-autoscaling#installing-prometheus-operator-and-prometheus
部署Demo應用程序
爲了生成指標，我們將部署一個簡單的應用程序mockmetrics，它將在/metrics處生成total_hit_count值。這是一個用Go寫的網絡服務器。當URL被訪問時，指標total_hit_count的值會不斷增加。它使用Prometheus所要求的展示格式來顯示指標。
根據以下鏈接來爲這一應用程序創建deployment和服務，它同時也爲應用程序創建ServiceMonitor和HPA：
https://github.com/infracloudio/kubernetes-autoscaling#deploying-the-mockmetrics-application
ServiceMonitor
ServiceMonitor爲Prometheus創建了一個配置。它提到了服務的標籤、路徑、端口以及應該在什麼時候抓取指標的時間間隔。在服務label的幫助下，選擇了pods。Prometheus會從所有匹配的Pod中抓取指標。根據你的Prometheus配置，ServiceMonitor應該放在相應的命名空間中。在本例中，它和mockmetrics 在同一個命名空間。
部署和配置Prometheus Adapter
現在要爲HPA提供custom.metrics.k8s.io API endpoint，我們將部署Prometheus Adapter。Adapter希望它的配置文件在Pod中可用。我們將創建一個configMap並將其掛載在pod內部。我們還將創建Service和APIService來創建API。APIService將**/api/custom.metrics.k8s.io/v1beta1 endpoint**添加到標準的Kubernetes APIs。你可以根據以下教程來實現這一目標：
接下來，我們看一下配置：
- seriesQuery用於查詢Prometheus的資源，標籤爲“default“和”mockmetrics-service“。
- resources部分提到標籤如何被映射到Kubernetes資源。針對我們的情況，它將“namespace“標籤與Kubernetes的”namespace“進行映射，服務也是如此。
- metricsQuery又是一個Prometheus查詢，它可以將指標導入adapter。我們使用的查詢是獲取2分鐘內所有匹配regexmockmetrics-deploy-(.*)的pods的平均total_hit_count總和。
Kubernetes自動伸縮實踐
一旦你根據下文中的步驟進行，指標值會不斷增加。我們現在就來看HPA：
https://github.com/infracloudio/kubernetes-autoscaling#scaling-the-application
$ kubectl get hpa -w
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
mockmetrics-app-hpa Deployment/mockmetrics-deploy 0/100 1 10 1 11h
mockmetrics-app-hpa Deployment/mockmetrics-deploy 56/100 1 10 1 11h
mockmetrics-app-hpa Deployment/mockmetrics-deploy 110/100 1 10 1 11h
mockmetrics-app-hpa Deployment/mockmetrics-deploy 90/100 1 10 2 11h
mockmetrics-app-hpa Deployment/mockmetrics-deploy 126/100 1 10 2 11h
mockmetrics-app-hpa Deployment/mockmetrics-deploy 306/100 1 10 2 11h
mockmetrics-app-hpa Deployment/mockmetrics-deploy 171/100 1 10 4 11h
你可以看到當該值達到目標值時，副本數如何增加。
工作流程
自動伸縮的整體流程如下圖所示：
圖片來源: luxas/kubeadm-workshop
結 論
你可以從下方鏈接中瞭解更多相關項目和參考資料。在過去的幾個版本中，Kubernetes中的監控流水線已經大有發展，而Kubernetes的自動伸縮主要基於該流水線工作。如果你不熟悉這個環境，很容易感到困惑和迷茫。
https://github.com/infracloudio/kubernetes-autoscaling#other-references-and-credits
原文鏈接：https://dzone.com/articles/kubernetes-autoscaling-with-custom-metrics-updated
About SUSE Rancher
Rancher是一個開源的企業級Kubernetes管理平臺，實現了Kubernetes集羣在混合雲+本地數據中心的集中部署與管理。Rancher一向因操作體驗的直觀、極簡備受用戶青睞，被Forrester評爲“2020年多雲容器開發平臺領導廠商”以及“2018年全球容器管理平臺領導廠商”，被Gartner評爲“2017年全球最酷的雲基礎設施供應商”。
目前Rancher在全球擁有超過三億的核心鏡像下載量，並擁有包括中國聯通、中國平安、中國人壽、上汽集團、三星、施耐德電氣、西門子、育碧遊戲、LINE、WWK保險集團、澳電訊公司、德國鐵路、廈門航空、新東方等全球著名企業在內的共40000家企業客戶。
2020年12月，SUSE完成收購RancherLabs，Rancher成爲了SUSE “創新無處不在（Innovate Everywhere）”企業願景的關鍵組成部分。SUSE和Rancher共同爲客戶提供了無與倫比的自由和所向披靡的創新能力，通過混合雲IT基礎架構、雲原生轉型和IT運維解決方案，簡化、現代化並加速企業數字化轉型，推動創新無處不在。