基於自定義Istio指標的Pod水平自動縮放
作者:Sandor Magyari
譯者:張成
審校:羅廣明
原文:https://banzaicloud.com/blog/k8s-hpa-prom-istio/
本文來自Banzai Cloud,通過一個spring-boot應用示例演示如何通過Istio operator來實現pod水平擴充套件。
基於自定義Istio指標的Pod水平自動縮放
Pipeline的核心功能之一,Banzai Cloud的應用程式和devops容器管理平臺,是多維的並可以基於預設和自定義指標進行自動調節。 在我們引入自定義指標後,我們選擇了通過Prometheus介面卡從Prometheus收集指標。 從那時起,我們的許多客戶開始使用Hoizontal Pod Autoscaling,他們中的大多數人只對基本的CPU和記憶體指標感到滿意。
我們一直都知道這不是一個理想的解決方案,我們一直在努力尋求更靈活的解決方案,以便:
- 基於自定義Prometheus指標的擴充套件
- 為更復雜的Prometheus查詢提供擴充套件支援
隨著我們的開源Istio operator的釋出以及在Pipeline平臺上廣泛引入基於Istio的服務網格,我們也提供了根據自定義的Istio指標的自動縮放功能。 Prometheus現在提供網路指標,延遲,故障率以及更多指標(預設情況下從Istio中刪除)。 我們的HPA operator根據這些指標決定是否擴充套件。
但是,在使用Prometheus Adapter時,我們的方法已不再可行,因此我們決定探索替代方案。
如果您錯過了我們關於Pipeline平臺所支援和自動化不同型別的自動縮放功能的系列部落格,請檢視這些早先的帖子:
TL;DR
- Pipeline及其HPA Operator中對重新設計的自定義指標支援的介紹。
- 使用來自Prometheus的Istio指標自動調整Spring Boot部署的示例
- 深入瞭解新增自定義指標後發生了什麼
- 切換到另一個自定義指標介面卡,kube-metrics-adapter的介紹
重新支援自定義指標
由於上面列出的原因,我們決定使用另一個自定義指標介面卡,kube-metrics-adapter。
kube-metrics-adapter 是一種通用指標介面卡,可以從多個來源收集和提供指標。對於每個源,都有一個Collector
實現;目前,我們對其Prometheus收集器最感興趣。
Prometheus Collector
是一個通用收集器。它將Prometheus 查詢對映到可由HPA 控制器用於部署自動擴充套件的度量標準。它的方法不同於Prometheus Adapter ,它具有預定義的規則集 - 包含針對Prometheus 執行的查詢,用於將指標轉換為自定義指標 - 定期執行。獲取所有匹配的指標標準(因為這些查詢必須是通用的並且定位所有pod和部署),並作為自定義指標進行轉換和公開。相比之下,“Prometheus collector”僅收集自定義查詢返回的指標結果,其定義因部署而異,並且僅針對單個部署/ pod或服務,從而減少了儲存的指標總數。該解決方案的一個缺點是,目前,使用者應該避免執行效能不佳的查詢。
使用ISTIO自動伸縮Spring Boot應用
我選擇了流行的spotguides
,基於MySQL的Sprint Boot 應用,以便在MySQL伺服器旁,快速啟動一個輕量級Web應用程式容器。 我使用Banzai Pipeline Beta,它支援在六個雲提供商中或在本地快速啟動Kubernetes叢集。 Prometheus & Grafana Monitoring以及Istio是預設功能,可以通過UI開關輕鬆開啟(Pipeline處理其餘部分)。 在這個例子中,我將在Google Cloud上啟動一個Kubernetes叢集,並開啟Monitoring and Service Mesh,並在其上部署Spring Boot Spotguide。 群集建立是我們的spotguide
嚮導的一部分,但是,因為Service Mesh
是Pipeline中的一個相對較新的功能,我們不能(迄今為止)從spotguide
的流程中啟用它, 所以我們必須事先建立叢集。
我在這個視訊中記錄了這些步驟:
一旦你的Spring Boot容器
和MySQL
伺服器啟動並執行,你就可以從Spotguid 總覽開啟演示程式。這是一個演示應用程式,是典型的Spring Web
應用程式。我們已經建立了一個GitHub
程式碼庫,你可以在裡面找到示意程式碼(就像我們的其他spotguides
一樣)。預設情況下,應用程式URL將僅返回執行狀況檢查狀態,該狀態連線到Kubernetes
活動和準備情況檢查。然後,JVM指標將暴露給Prometheus,並且repo將整合到我們的CI/CD流中,因此,一旦您提交業務邏輯,它將自動部署到叢集。在這裡閱讀更多關於我們的spotguides。
您可以從群集列表或詳細資訊頁面下載Kubernetes
配置,以便稍後從本地計算機獲取對群集的kubectl
訪問許可權。
我正在使用hey
工具(go get -u github.com/rakyll/hey
)來生成針對Spring應用程式的負載;下面的命令將每秒發出50個請求
,總計10000
個請求:
hey -n 10000 -q 50 https://spring-boot-custom-metrics-demo.sancyx5g25.sancyx.beta.banzaicloud.io/actuator/health/kubernetes複製程式碼
現在,開啟監控(我們的Spotguide摘要或群集詳細資訊頁面中提供的連結)以檢視可用的指標並確定您的Prometheus 查詢。 因為我們啟用了Service Mesh,所有網路通訊都將通過Envoy代理,將指標傳送到Istio遙測服務,該服務由Prometheus抓取。
我將基於我的示例,查詢基於istiorequeststotal指標,該指標與Spring容器相關:
sum(rate(istio_requests_total{destination_service="spring-boot-custom-metrics-demo-spotguide-spring-boot.default.svc.cluster.local",destination_service_name="spring-boot-custom-metrics-demo-spotguide-spring-boot",destination_service_namespace="default",destination_workload="spring-boot-custom-metrics-demo-spotguide-spring-boot"}[1m]))複製程式碼
請務必新增相應的標籤過濾器,以便專門選擇與您的pod/部署相關的指標。
從部署列表頁面上的Horizontal Pod Autoscaler選單中選擇spring-boot-custom-metrics-demo-spotguide-spring-boot部署,以訪問HPA Edit頁面。 在那裡,您可以通過輸入自定義指標或查詢的名稱來設定cpu,記憶體和自定義指標。
現在,如果您在更長的時間內生成另一個負載(50個請求/秒),則應在屬於部署的HPA中增加副本計數:
hey -n 50000 -q 50 https://spring-boot-custom-metrics-demo.sancyx5g25.sancyx.beta.banzaicloud.io/actuator/health/kubernetes
...
kubectl get hpa
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
spring-boot-custom-metrics-demo-spotguide-spring-boot Deployment/spring-boot-custom-metrics-demo-spotguide-spring-boot 245866m/40 1 10 7 80s複製程式碼
載入結束後,副本數將慢慢減少到預設的最小值:
kubectl get hpa
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
spring-boot-custom-metrics-demo-spotguide-spring-boot Deployment/spring-boot-custom-metrics-demo-spotguide-spring-boot 266m/40 1 10 1 32m複製程式碼
背後的場景
讓我們深入瞭解使用Pipeline UI向部署新增自定義指標時幕後發生的情況。 這個流程非常類似於資源指標,您可能會從之前的一系列帖子中熟悉這些指標,但是現在,讓我們關注與自定義指標相關的API。
Pipeline UI使用HPA API建立/更新指標:
PUT {{pipeline_url}}/api/v1/orgs/:orgId/clusters/:clusterId/hpa
{
"scaleTarget": "example-deployment-name","minReplicas": 1,"maxReplicas": 10,"customMetrics": {
"customMetricName": {
"query": "sum({kubernetes_pod_name=~\"^example-deployment-name-pod.*\",__name__=~\"example-metric-name\"})","targetAverageValue": "100"
}
}
}複製程式碼
如果要指定絕對值,可以使用targetValue
而不是targetAverageValue
。 不同之處在於,targetAverageValue
使用當前pod副本計數對獲取的度量值進行平均。
Pipeline實際上做的是為您的部署新增以下注釋:
hpa.autoscaling.banzaicloud.io/maxReplicas=10
hpa.autoscaling.banzaicloud.io/minReplicas=1
prometheus.customMetricName.hpa.autoscaling.banzaicloud.io/query=sum({kubernetes_pod_name=~\"^example-deployment-name-pod.*\",__name__=~\"example-metric-name\"})複製程式碼
所有這些都是通過HPA operator實現的,它根據部署註釋管理HPA資源。 Pipeline在群集建立完成後,通過一個post hook,部署HPA operator,然後,如果metrics.api
尚未註冊,則部署kube-metrics-adapter
和metrics-server
。 此過程可能會有所不同,具體取決於您的雲提供商和K8s版本,這些版本可能已安裝了某些功能。在我們的例子中,新建立的HPA物件將如下所示:
apiVersion: v1
items:
- apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
annotations:
...
autoscaling.alpha.kubernetes.io/current-metrics: '[{"type":"Object","object":{"target":{"kind":"Pod","name":"example-deployment-name-customMetricName","apiVersion":"v1"},"metricName":"customMetricName","currentValue":"222m"}}]'
autoscaling.alpha.kubernetes.io/metrics: '[{"type":"Object","targetValue":"40"}}]'
metric-config.object.customMetricName.prometheus/per-replica: "true"
metric-config.object.customMetricName.prometheus/query: sum({kubernetes_pod_name=~\"^example-deployment-name-pod.*\",__name__=~\"example-metric-name\"})
...
spec:
maxReplicas: 10
minReplicas: 1
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: example-deployment-name
status:
currentReplicas: 1
desiredReplicas: 1
kind: List
metadata:
resourceVersion: ""
selfLink: ""複製程式碼
請注意,自定義度量標準是Object
型別,並繫結到名為example-deployment-name-customMetricName
的Pod資源。 Kube-metrics-adapter
也使用註釋查詢來獲取度量值,該值在以下端點公開/apis/custom.metrics.k8s.io/v1beta1/namespaces/default/pods/example-deployment-name -customMetricName/customMetricName
,並且它正是HPA控制器將要查詢的位置:
$ kubectl get --raw "/apis/custom.metrics.k8s.io/v1beta1/namespaces/default/pods/*/customMetricName" | jq .
{
"kind": "MetricValueList","apiVersion": "custom.metrics.k8s.io/v1beta1","metadata": {
"selfLink": "/apis/custom.metrics.k8s.io/v1beta1/namespaces/default/pods/%2A/customMetricName"
},"items": [
{
"describedObject": {
"kind": "Pod","namespace": "default","name": "example-deployment-name-customMetricName","apiVersion": "v1"
},"metricName": "customMetricName","timestamp": "2019-03-13T20:23:32Z","value": "222m"
}
]
}複製程式碼
很高興你閱讀本文,希望你有一個關於自動縮放愉快的實踐體驗!
關於 ServiceMesher 社群
ServiceMesher 社群是由一群擁有相同價值觀和理念的志願者們共同發起,於 2018 年 4 月正式成立。
社群關注領域有:容器、微服務、Service Mesh、Serverless,擁抱開源和雲原生,致力於推動 Service Mesh 在中國的蓬勃發展。
社群官網:https://www.servicemesher.com