導(dǎo)語：?我們通常使用Prometheus來對Kubernetes運行情況進行監(jiān)控。并根據(jù)監(jiān)控數(shù)據(jù)來擴容或者縮容。通常的擴/縮容都是根據(jù)內(nèi)存或者CPU的使用，但是很多時候我們擴/縮容的依據(jù)通常是業(yè)務(wù)監(jiān)控指標。如何根據(jù)業(yè)務(wù)監(jiān)控指標來進行擴/縮容，本文作者給出了很優(yōu)雅的方式。

Kubernetes自動彈性伸縮

自動彈性伸縮是一種基于資源使用情況自動彈性伸縮工作負載的方法。
Kubernetes的自動彈性伸縮有兩個維度：

• 處理node縮放操作的Cluster Autoscaler

• 自動彈性伸縮部署副本集Pod數(shù)量的Horizontal Pod Autoscaler（HPA）。

Cluster Autoscaling和Horizontal Pod Autoscaler（HPA）可用于動態(tài)調(diào)整計算能力以滿足系統(tǒng)SLA的要求。
雖然群集Cluster Autoscaler高度依賴云提供程序的底層功能，但HPA可以獨立于IaaS / PaaS提供程序運行。

?

HPA的演變

Horizontal Pod Autoscaler功能首次在Kubernetes V1.1中引入，自那時起已經(jīng)發(fā)展了很久。 HPA V1版本基于觀察到的CPU利用率和內(nèi)存使用情況來自動伸縮POD。 在Kubernetes 1.6中引入了新的API自定義度量API，使HPA可以訪問任意度量標準。 最終，Kubernetes 1.7引入了聚合層，允許第三方應(yīng)用程序通過將自己注冊為API附加組件來擴展Kubernetes API。
Custom Metrics API和聚合層使得Prometheus等監(jiān)控系統(tǒng)可以向HPA控制器公開特定于應(yīng)用的指標。
Horizontal Pod Autoscaler使用控制循環(huán)來實現(xiàn)功能，它定期查詢Resource Metrics API的核心度量標準，如CPU /內(nèi)存和Custom Metrics API以獲取特定于應(yīng)用程序的度量標準。

以下是關(guān)于為Kubernetes 1.9或更高版本配置HPA v2的指南：

安裝提供核心指標的Metrics Server插件。

使用demo應(yīng)用根據(jù)CPU和內(nèi)存使用情況展示pod自動調(diào)節(jié)。

部署Prometheus和一個自定義的API服務(wù)器。 將自定義API服務(wù)器注冊到聚合層。

demo應(yīng)用程序使用自定義指標配置HPA。

在開始之前，您需要安裝Go 1.8或更高版本，并在您的GOPATH克隆k8s-prom-hpa[1]：

1.?設(shè)置Metrics server

Kubernetes?Metrics Server[2]是一個集群范圍的資源使用數(shù)據(jù)聚合器，是Heapster[3]的繼任者。 Metrics Server通過匯集來自kubernetes.summary_api.數(shù)據(jù)來收集node和POD的CPU和內(nèi)存使用情況。summary API是用于將數(shù)據(jù)從Kubelet / cAdvisor傳遞到Metrics Server的API(基于內(nèi)存十分高效)。

如果在HPA的第一個版本中，您需要Heapster提供CPU和內(nèi)存指標，但在HPA v2和Kubernetes 1.8中，只有啟用horizontal-pod-autoscaler-use-rest-clients時才需要Metrics Server。 Kubernetes 1.9默認啟用HPA rest 客戶端。 GKE 1.9預(yù)裝了Metrics Server。
在kube-system命名空間中部署Metrics Server：

kubectl create -f ./metrics-server

一分鐘后，?metric-server開始報告node和POD的CPU和內(nèi)存使用情況。

查看node指標：

?

kubectl?get?--raw?"/apis/metrics.k8s.io/v1beta1/nodes"?|?jq?.

查看pods指標：

kubectl get --raw "/apis/metrics.k8s.io/v1beta1/pods" | jq .

?

2.基于CPU和內(nèi)存使用情況的Auto Scaling

我們將使用一個基于Golang的小型Web應(yīng)用程序來測試Horizontal Pod Autoscaler（HPA）。
將podinfo[4]部署到default名稱空間：

kubectl create -f ./podinfo/podinfo-svc.yaml,./podinfo/podinfo-dep.yaml

使用http://<K8S_PUBLIC_IP>:31198.上的NodePort服務(wù)訪問podinfo。
接下來定義一個保持最少兩個副本的HPA，如果CPU平均值超過80％或內(nèi)存超過200Mi，則可擴展到10：

創(chuàng)建HPA：

kubectl create -f ./podinfo/podinfo-hpa.yaml

幾秒鐘后，HPA控制器聯(lián)系Metrics Server，然后獲取CPU和內(nèi)存使用情況：

為了增加CPU壓力，使用rakyll / hey運行負載測試：

暫時刪除podinfo。 稍后將在本教程中再次部署它：

kubectl delete -f ./podinfo/podinfo-hpa.yaml,./podinfo/podinfo-dep.yaml,./podinfo/podinfo-svc.yaml

?

3.設(shè)置自定義Metrics Server

為了根據(jù)自定義指標進行縮放，您需要兩個組件。 一個從您的應(yīng)用程序收集指標并將它們存儲在Prometheus[5]時間序列數(shù)據(jù)庫中。 第二個組件使用collect，?k8s-prometheus適配器[6]提供的度量標準擴展Kubernetes自定義指標API。
?

您將在專用命名空間中部署Prometheus和適配器。
創(chuàng)建monitoring名稱空間：

kubectl create -f ./namespaces.yaml

在monitoring命名空間中部署Prometheus v2：

kubectl create -f ./prometheus

生成Prometheus適配器所需的TLS證書：

make certs

部署Prometheus自定義指標API適配器：

kubectl create -f ./custom-metrics-api

列出Prometheus提供的自定義指標：

kubectl get --raw "/apis/custom.metrics.k8s.io/v1beta1" | jq .

獲取monitoring命名空間中所有POD的FS使用情況：

kubectl get --raw "/apis/custom.metrics.k8s.io/v1beta1/namespaces/monitoring/pods/*/fs_usage_bytes" | jq .

?

4.基于自定義指標的Auto Scaling

在default命名空間中創(chuàng)建podinfoNodePort服務(wù)并部署：

kubectl create -f ./podinfo/podinfo-svc.yaml,./podinfo/podinfo-dep.yaml

podinfo應(yīng)用程序公開名為http_requests_total的自定義指標。 Prometheus適配器移除_total后綴并將度量標記為計數(shù)器度量。
從自定義指標API獲取每秒的總請求數(shù)：

m代表milli-units，例如，?901m?意味著901 milli-requests （就是大約0.9個請求）。
創(chuàng)建一個HPA，如果請求數(shù)量超過每秒10個，將增加podinfo：

在default名稱空間中部署podinfoHPA：

kubectl create -f ./podinfo/podinfo-hpa-custom.yaml

幾秒鐘后，HPA從度量API獲取http_requests值：

以每秒25個請求的速度為podinfo服務(wù)加壓：

幾分鐘后，HPA開始增加POD數(shù)量：

按照目前每秒的請求速度，部署將永遠不會達到10個POD的最大值。 三個副本足以使每個POD的RPS保持在10以下。
負載測試完成后，HPA會將部署縮減為其初始副本數(shù)量：

您可能已經(jīng)注意到自動調(diào)節(jié)器不會立即響應(yīng)峰值。 默認情況下，指標同步每30秒一次。 如果在最近3-5分鐘內(nèi)沒有重新縮放，才能進行擴容/縮容。這確保了HP以防止沖突決策快速執(zhí)行，并為Cluster Autoscaler提供了時間。

?

結(jié)論

并非所有系統(tǒng)都可以通過單獨依靠CPU /內(nèi)存使用量度來滿足其SLA，但大多數(shù)Web和移動后端均需要基于每秒請求數(shù)來對任何流量突發(fā)進行處理。

對于ETL應(yīng)用程序，自動彈性伸縮可能由作業(yè)隊列長度超過某個閾值引發(fā)，等等。
通過使用Prometheus提供的適用于自動彈性伸縮的指標，您可以微調(diào)應(yīng)用程序以更好地處理突發(fā)事件并確保高可用性。

?

參考鏈接

[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

總結(jié)

以上是生活随笔為你收集整理的Kubernetes大集群怎么管?基于监控的弹性伸缩方法的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。