歷史問題

眾所周知，Kubernetes 有個親生的 HPA 組件，在云原生早期，這個名義上的自動擴(kuò)縮容的能力給 Kubernetes 贏得了不少掌聲。當(dāng)然現(xiàn)在回頭看看，僅僅根據(jù) CPU 和內(nèi)存這樣“貧瘠”的指標(biāo)，不論是用于判斷負(fù)載水平，還是用于計(jì)算擴(kuò)容目標(biāo)，都不是很夠用的。這個階段里，HPA 的擴(kuò)縮容效率也是廣受詬病的一個問題，在一個多級微服務(wù)調(diào)用的業(yè)務(wù)場景里，壓力是逐級傳遞的，下圖展示了一個常見情況：l9P28資訊網(wǎng)——每日最新資訊28at.com

l9P28資訊網(wǎng)——每日最新資訊28at.com

圖片l9P28資訊網(wǎng)——每日最新資訊28at.com

l9P28資訊網(wǎng)——每日最新資訊28at.com

如上圖，用戶流量進(jìn)入集群之后：l9P28資訊網(wǎng)——每日最新資訊28at.com

1. 首先在 Deploy A 造成負(fù)載，指標(biāo)變化迫使 Deploy A 擴(kuò)容
2. A 擴(kuò)容之后，吞吐量變大，B 受到壓力，再次采集到指標(biāo)變化，擴(kuò)容 Deploy B
3. B 吞吐變大，C ..

這個逐級傳遞的過程不僅緩慢，而且可以說是步步驚心——每一級的擴(kuò)容都是直接被 CPU 或內(nèi)存的飆高觸發(fā)的，被“沖垮”的可能性是普遍存在的。這種被動、滯后的方式，很明顯是有問題的。l9P28資訊網(wǎng)——每日最新資訊28at.com

推陳出新

造成 HPA 窘境的原因之一，就是“自掃門前雪”，每個 Pod 都只能根據(jù)自身負(fù)載情況來進(jìn)行擴(kuò)縮容決策。如果能夠直接根據(jù)業(yè)務(wù)流量的變化進(jìn)行決策，并且將流量流經(jīng)的所有微服務(wù)進(jìn)行擴(kuò)縮容，看起來情況就會好很多了。HPA 的自定義指標(biāo)支持，給這個問題了一個可行的方案。該能力讓 HPA 可以用其它的指標(biāo)來作為擴(kuò)縮容的觸發(fā)器，例如我們可以用 Promethues 采集消息中間件的深度或者負(fù)載均衡器的隊(duì)列長度，作為一個更能如實(shí)反映業(yè)務(wù)流量的指標(biāo)，直接用來觸發(fā)相關(guān)的多個微服務(wù)的擴(kuò)縮容，如下圖所示：l9P28資訊網(wǎng)——每日最新資訊28at.com

圖片l9P28資訊網(wǎng)——每日最新資訊28at.com

l9P28資訊網(wǎng)——每日最新資訊28at.com

在上圖中：l9P28資訊網(wǎng)——每日最新資訊28at.com

1. Prometheus 采集消息隊(duì)列和負(fù)載均衡等更能反映業(yè)務(wù)流量的指標(biāo)
2. 使用 Prometheus Adapter 將 Promethues Metrics 轉(zhuǎn)換為 Kubernetes 的 Aggregated API
3. HPA 使用自定義指標(biāo)，同時對多個應(yīng)用進(jìn)行擴(kuò)縮容。

這中間涉及到的 Prometheus Adapter，通過配置文件完成步驟 2 的轉(zhuǎn)換：l9P28資訊網(wǎng)——每日最新資訊28at.com

- seriesQuery: '{__name__=~"^container_.*_total",container!="POD",namespace!="",pod!=""}'  resources:    overrides:      namespace: {resource: "namespace"}      pod: {resource: "pod"}  seriesFilters:  # since this is a superset of the query above, we introduce an additional filter here  - isNot: "^container_.*_seconds_total$"  name: {matches: "^container_(.*)_total$"}  metricsQuery: "sum(rate(<<.Series>>{<<.LabelMatchers>>,container!="POD"}[2m])) by (<<.GroupBy>>)"

當(dāng)然，完全可以自行實(shí)現(xiàn) Aggregated API 來支持這種指標(biāo)的采集和呈現(xiàn)工作。Prometheus 所提供的大量 Exporter 是吸引我們寫這種古怪語法的最大動力。l9P28資訊網(wǎng)——每日最新資訊28at.com

那么如果是 KEDA 的話，這個問題又如何呢？KEDA 提供了幾十個被稱為 Scaler 的東西，其中除了 Promethues 之外，還包括 Kafka、Redis、PostgreSQL 等多種選擇。所以在很多場景中，無需 Promethues，也能使用 Scaler 完成對輸入指標(biāo)的讀取和判斷。下面用 KEDA 為例，看看這種伸縮方法的具體實(shí)現(xiàn)。l9P28資訊網(wǎng)——每日最新資訊28at.com

KEDA

假設(shè)一個容器化應(yīng)用由多個工作負(fù)載組成：l9P28資訊網(wǎng)——每日最新資訊28at.com

• Ingress：負(fù)責(zé)接收業(yè)務(wù)流量
• Backend 1、Backend 2：負(fù)責(zé)處理 Ingress 發(fā)來的任務(wù)
• Database：數(shù)據(jù)庫

我們希望達(dá)成的效果是 —— Ingress、Backend 1、Backend 2、Database，實(shí)例數(shù)量保持在 1:2:1.5:2 的關(guān)系，Keda 的大致流程如下圖所示：l9P28資訊網(wǎng)——每日最新資訊28at.com

圖片l9P28資訊網(wǎng)——每日最新資訊28at.com

l9P28資訊網(wǎng)——每日最新資訊28at.com

首先使用 Helm 安裝 KEDA：l9P28資訊網(wǎng)——每日最新資訊28at.com

$ helm repo add kedacore https://kedacore.github.io/charts$ helm install keda kedacore/keda --namespace defaultNAME: kedaLAST DEPLOYED: Wed Nov 29 18:56:36 2023NAMESPACE: defaultSTATUS: deployedREVISION: 1...

隨便創(chuàng)建幾個工作負(fù)載，冒充微服務(wù)：l9P28資訊網(wǎng)——每日最新資訊28at.com

$ kubectl create deploy ingress --image=nginxdeployment.apps/ingress created$ kubectl create deploy backend1 --image=nginxdeployment.apps/backend1 created$ kubectl create deploy backend2 --image=nginxdeployment.apps/backend2 created$ kubectl create deploy database --image=nginxdeployment.apps/database created$ kubectl get pods | cut -d - -f 1 | grep -v keda | sort...backend1backend2databaseingress

運(yùn)行成功后，我們可以看到，四個微服務(wù)，每個微服務(wù)都有一個實(shí)例。l9P28資訊網(wǎng)——每日最新資訊28at.com

按照剛才瞎掰的比例，編寫一個 ScaleObject：l9P28資訊網(wǎng)——每日最新資訊28at.com

apiVersion: keda.sh/v1alpha1kind: ScaledObjectmetadata:  name: bk1spec:  scaleTargetRef:    name: backend1  triggers:  - type: kubernetes-workload    metadata:       podSelector: 'app=ingress'      value: '0.5'---apiVersion: keda.sh/v1alpha1kind: ScaledObjectmetadata:  name: bk2spec:  scaleTargetRef:    name: backend2  triggers:  - type: kubernetes-workload    metadata:       podSelector: 'app=ingress'      value: '0.67'      ---apiVersion: keda.sh/v1alpha1kind: ScaledObjectmetadata:  name: dbspec:  scaleTargetRef:    name: database  triggers:  - type: kubernetes-workload    metadata:       podSelector: 'app=ingress'      value: '0.5'

上述代碼引入了 kubernetes-workload 類型的觸發(fā)器，他會監(jiān)控 app=ingress 的容器，并對 scaleTargetRef 中提到的工作負(fù)載數(shù)量比例進(jìn)行擴(kuò)縮容。l9P28資訊網(wǎng)——每日最新資訊28at.com

提交到集群之后，會看到實(shí)例數(shù)量數(shù)量發(fā)生了變化：l9P28資訊網(wǎng)——每日最新資訊28at.com

$ kubectl get pods | cut -d - -f 1 | sort | uniq --count...   2 backend1   2 backend2   2 database   1 ingress   3 keda

我們把 Ingress 擴(kuò)容到 2 實(shí)例，再次統(tǒng)計(jì)：l9P28資訊網(wǎng)——每日最新資訊28at.com

$ kubectl scale deployment ingress --replicas=2deployment.apps/ingress scaled$ kubectl get pods | cut -d - -f 1 | sort | uniq --count...   4 backend1   3 backend2   4 database   2 ingress   3 keda

可以看到，的確是按照我們設(shè)定的比例，同步產(chǎn)生了縮放。如果縮減 Ingress 服務(wù)實(shí)例數(shù)，幾分鐘之后，其它工作負(fù)載也會隨之縮容。l9P28資訊網(wǎng)——每日最新資訊28at.com

$ kubectl scale deployment ingress --replicas=1deployment.apps/ingress scaled$ kubectl get pods | cut -d - -f 1 | sort | uniq --count                                                         /...   2 backend1   2 backend2   2 database   1 ingress

結(jié)論

雖說云原生架構(gòu)的復(fù)雜性問題越來越被強(qiáng)調(diào)，但是這一生態(tài)的宗旨應(yīng)該還是沒有變化——用簡單的透明的手段解決復(fù)雜問題。l9P28資訊網(wǎng)——每日最新資訊28at.com

本文鏈接：http://www.tebozhan.com/showinfo-26-35285-0.html一篇學(xué)會用 KEDA 根據(jù)工作負(fù)載進(jìn)行快速擴(kuò)容

聲明：本網(wǎng)頁內(nèi)容旨在傳播知識，若有侵權(quán)等問題請及時與本網(wǎng)聯(lián)系，我們將在第一時間刪除處理。郵件：2376512515@qq.com

上一篇： Git 難用？有救！

下一篇： useEffect 實(shí)踐案例之一