您好,登錄后才能下訂單哦!
這期內(nèi)容當(dāng)中小編將會給大家?guī)碛嘘P(guān)如何根據(jù)不同業(yè)務(wù)場景調(diào)節(jié)HPA 擴(kuò)縮容靈敏度,文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述,閱讀完這篇文章希望大家可以有所收獲。
在 K8s 1.18 之前,HPA 擴(kuò)容是無法調(diào)整靈敏度的:
對于縮容,由 kube-controller-manager
的 --horizontal-pod-autoscaler-downscale-stabilization-window
參數(shù)控制縮容時(shí)間窗口,默認(rèn) 5 分鐘,即負(fù)載減小后至少需要等 5 分鐘才會縮容。
對于擴(kuò)容,由 hpa controller 固定的算法、硬編碼的常量因子來控制擴(kuò)容速度,無法自定義。
這樣的設(shè)計(jì)邏輯導(dǎo)致用戶無法自定義 HPA 的擴(kuò)縮容靈敏度,而不同的業(yè)務(wù)場景對于擴(kuò)容容靈敏度要求可能是不一樣的,比如:
對于有流量突發(fā)的關(guān)鍵業(yè)務(wù),在需要的時(shí)候應(yīng)該快速擴(kuò)容 (即便可能不需要,以防萬一),但縮容要慢 (防止另一個(gè)流量高峰)。
對于一些需要處理大量數(shù)據(jù)的離線業(yè)務(wù),在需要的時(shí)候應(yīng)該盡快擴(kuò)容以減少處理時(shí)間,不需要那么多資源的時(shí)候應(yīng)該盡快縮容以節(jié)約成本。
處理常規(guī)數(shù)據(jù)/網(wǎng)絡(luò)流量的業(yè)務(wù),它們可能會以一般的方式擴(kuò)大和縮小規(guī)模,以減少抖動。
HPA 在 K8s 1.18 迎來了一次更新,在之前 v2beta2 版本上新增了擴(kuò)縮容靈敏度的控制,不過版本號依然保持 v2beta2 不變。
這次更新實(shí)際就是在 HPA Spec 下新增了一個(gè) behavior
字段,下面有 scaleUp
和 scaleDown
兩個(gè)字段分別控制擴(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分鐘) 后開始縮容。
如果流量高峰過了,并發(fā)量驟降,如果用默認(rèn)的縮容策略,等幾分鐘后 Pod 數(shù)量也會隨之驟降,如果 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)致部分請求失敗。
如果想要你的應(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
如果應(yīng)用非常關(guān)鍵,希望擴(kuò)容后不自動縮容,需要人工干預(yù)或其它自己開發(fā)的 controller 來判斷縮容條件,可以使用類型如下的 behavior
配置來禁止自動縮容:
behavior: scaleDown: policies: - type: pods value: 0
縮容默認(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í),會等待 600s (10 分鐘) 再縮容,每次只縮容 5 個(gè) Pod。
有些應(yīng)用經(jīng)常會有數(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ò)容算法會在較短的時(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。
上述就是小編為大家分享的如何根據(jù)不同業(yè)務(wù)場景調(diào)節(jié)HPA 擴(kuò)縮容靈敏度了,如果剛好有類似的疑惑,不妨參照上述分析進(jìn)行理解。如果想知道更多相關(guān)知識,歡迎關(guān)注億速云行業(yè)資訊頻道。
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點(diǎn)不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進(jìn)行舉報(bào),并提供相關(guān)證據(jù),一經(jīng)查實(shí),將立刻刪除涉嫌侵權(quán)內(nèi)容。