背景
在K8s 1.18之前，HPA擴(kuò)容是無法調(diào)整靈敏度的:
1.對于縮容，由kube-controller-manager的--horizontal-pod-autoscaler-downscale-stabilization-window參數(shù)控制縮容時(shí)間窗口，默認(rèn)5分鐘，即負(fù)載減小后至少需要等5分鐘才會(huì)縮容。
2.對于擴(kuò)容，由hpa controller固定的算法、硬編碼的常量因子來控制擴(kuò)容速度，無法自定義。
這樣的設(shè)計(jì)邏輯導(dǎo)致用戶無法自定義HPA的擴(kuò)縮容靈敏度，而不同的業(yè)務(wù)場景對于擴(kuò)容容靈敏度要求可能是不一樣的，比如：
1.對于有流量突發(fā)的關(guān)鍵業(yè)務(wù)，在需要的時(shí)候應(yīng)該快速擴(kuò)容(即便可能不需要，以防萬一)，但縮容要慢(防止另一個(gè)流量高峰)。
2.對于一些需要處理大量數(shù)據(jù)的離線業(yè)務(wù)，在需要的時(shí)候應(yīng)該盡快擴(kuò)容以減少處理時(shí)間，不需要那么多資源的時(shí)候應(yīng)該盡快縮容以節(jié)約成本。
3.處理常規(guī)數(shù)據(jù)/網(wǎng)絡(luò)流量的業(yè)務(wù)，它們可能會(huì)以一般的方式擴(kuò)大和縮小規(guī)模，以減少抖動(dòng)。
HPA在K8s 1.18迎來了一次更新，在之前v2beta2版本上新增了擴(kuò)縮容靈敏度的控制，不過版本號(hào)依然保持v2beta2不變。
如何使用
這次更新實(shí)際就是在HPA Spec下新增了一個(gè)behavior字段，下面有scaleUp和scaleDown兩個(gè)字段分別控制擴(kuò)容和縮容的行為。
下面給出一些使用場景的示例。
快速擴(kuò)容
當(dāng)你的應(yīng)用需要快速擴(kuò)容時(shí)，可以使用類似如下的HPA配置:
apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
name: web
spec:
minReplicas: 1
maxReplicas: 1000
metrics:
- pods:
metric:
name: k8s_pod_rate_cpu_core_used_limit
target:
averageValue: "80"
type: AverageValue
type: Pods
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: web
behavior: # 這里是重點(diǎn)
scaleUp:
policies:
- type: percent
value: 900%
上面的配置表示擴(kuò)容時(shí)立即新增當(dāng)前9倍數(shù)量的副本數(shù)，即立即擴(kuò)容到當(dāng)前10倍的Pod數(shù)量，當(dāng)然也不能超過maxReplicas的限制。
假如一開始只有1個(gè)Pod，如果遭遇流量突發(fā)，它將以飛快的速度進(jìn)行擴(kuò)容，擴(kuò)容時(shí)Pod數(shù)量變化趨勢如下:
1->10->100->1000
沒有配置縮容策略，將等待全局默認(rèn)的縮容時(shí)間窗口(--horizontal-pod-autoscaler-downscale-stabilization-window，默認(rèn)5分鐘)后開始縮容。
快速擴(kuò)容，緩慢縮容
如果流量高峰過了，并發(fā)量驟降，如果用默認(rèn)的縮容策略，等幾分鐘后Pod數(shù)量也會(huì)隨之驟降，如果Pod縮容后突然又來一個(gè)流量高峰，雖然可以快速擴(kuò)容，但擴(kuò)容的過程畢竟還是需要一定時(shí)間的，如果流量高峰足夠高，在這段時(shí)間內(nèi)還是可能造成后端處理能力跟不上，導(dǎo)致部分請求失敗。這時(shí)候我們可以為HPA加上縮容策略，HPA behavior配置示例如下:
behavior:
scaleUp:
policies:
- type: percent
value: 900%
scaleDown:
policies:
- type: pods
value: 1
periodSeconds: 600 # 每 10 分鐘只縮掉 1 個(gè) Pod
上面示例中增加了scaleDown的配置，指定縮容時(shí)每10分鐘才縮掉1個(gè)Pod，大大降低了縮容速度，縮容時(shí)的Pod數(shù)量變化趨勢如下:
1000 -> … (10 min later) -> 999
這個(gè)可以讓關(guān)鍵業(yè)務(wù)在可能有流量突發(fā)的情況下保持處理能力，避免流量高峰導(dǎo)致部分請求失敗。
緩慢擴(kuò)容
如果想要你的應(yīng)用不太關(guān)鍵，希望擴(kuò)容時(shí)不要太敏感，可以讓它擴(kuò)容平穩(wěn)緩慢一點(diǎn)，為HPA加入下面的behavior:
behavior:
scaleUp:
policies:
- type: pods
value: 1 # 每次擴(kuò)容只新增 1 個(gè) Pod
假如一開始只有1個(gè)Pod，擴(kuò)容時(shí)它的Pod數(shù)量變化趨勢如下:
1 -> 2 -> 3 -> 4
禁止自動(dòng)縮容
如果應(yīng)用非常關(guān)鍵，希望擴(kuò)容后不自動(dòng)縮容，需要人工干預(yù)或其它自己開發(fā)的controller來判斷縮容條件，可以使用類型如下的behavior配置來禁止自動(dòng)縮容:
behavior:
scaleDown:
policies:
- type: pods
value: 0
延長縮容時(shí)間窗口
縮容默認(rèn)時(shí)間窗口是5 min(--horizontal-pod-autoscaler-downscale-stabilization-window)，如果我們需要延長時(shí)間窗口以避免一些流量毛刺造成的異常，可以指定下縮容的時(shí)間窗口，behavior配置示例如下:
behavior:
scaleDown:
stabilizationWindowSeconds: 600 # 等待 10 分鐘再開始縮容
policies:
- type: pods
value: 5 # 每次只縮掉 5 個(gè) Pod
上面的示例表示當(dāng)負(fù)載降下來時(shí)，會(huì)等待600s(10分鐘)再縮容，每次只縮容5個(gè)Pod。
延長擴(kuò)容時(shí)間窗口
有些應(yīng)用經(jīng)常會(huì)有數(shù)據(jù)毛刺導(dǎo)致頻繁擴(kuò)容，而擴(kuò)容出來的Pod其實(shí)沒太大必要，反而浪費(fèi)資源。比如數(shù)據(jù)處理管道的場景，擴(kuò)容指標(biāo)是隊(duì)列中的事件數(shù)量，當(dāng)隊(duì)列中堆積了大量事件時(shí)，我們希望可以快速擴(kuò)容，但又不希望太靈敏，因?yàn)榭赡苤皇嵌虝r(shí)間內(nèi)的事件堆積，即使不擴(kuò)容也可以很快處理掉。
默認(rèn)的擴(kuò)容算法會(huì)在較短的時(shí)間內(nèi)擴(kuò)容，針對這種場景我們可以給擴(kuò)容增加一個(gè)時(shí)間窗口以避免毛刺導(dǎo)致擴(kuò)容帶來的資源浪費(fèi)，behavior配置示例如下:
behavior:
scaleUp:
stabilizationWindowSeconds: 300 # 擴(kuò)容前等待 5 分鐘的時(shí)間窗口
policies:
- type: pods
value: 20 # 每次擴(kuò)容新增 20 個(gè) Pod
上面的示例表示擴(kuò)容時(shí)，需要先等待5分鐘的時(shí)間窗口，如果在這段時(shí)間內(nèi)負(fù)載降下來了就不再擴(kuò)容，如果負(fù)載持續(xù)超過擴(kuò)容閥值才擴(kuò)容，每次擴(kuò)容新增20個(gè)Pod。
小結(jié)
本文介紹了如何利用K8s 1.18的HPA新特性來控制擴(kuò)縮容的靈敏度，以更好的滿足各種不同場景對擴(kuò)容速度的需求。
參考資料
HPA介紹:https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/
騰訊云
專欄
閩公網(wǎng)安備 35010202001226號(hào)
