01

前言

Aliware

云計算帶來的優勢之一便是彈性能力，云原生場景下 Kubernetes 提供了水平彈性擴容能力（HPA），讓應用可以隨著實時指標進行擴/縮。然而 HPA 的實際工作情況可能和我們直觀預想的情況是不一樣的，這里面存在一些認知誤區。本文總結了一下 EDAS 用戶在使用 HPA 時常遇到的三個認知誤區，具體如下：

誤區一：HPA 存在擴容死區

現象：當 Request=Limit 時，期望利用率超過 90%時，無法正常擴容。

原因剖析：HPA 中存在容忍度（默認為 10%），指標變化幅度小于容忍度時，HPA 會忽略本次擴/縮動作。若當期望利用率為 90%時，則實際利用率在 81%-99%之間，都會被 HPA 忽略。

避坑指南：當 Request=Limit 時，避免設置過高的期望利用率，一來避免擴容死區；二來被動擴容有一定的遲滯時間，留下更多的緩沖余量以應對突增流量。

誤區二：誤解利用率計算方法，HPA 擴容與預期使用量不符

現象：當 Limit > Request 時，配置 50%的利用率，使用量未達到 Limit 的 50%便擴容。

原因剖析：HPA 計算利用率是基于 Request 計算，當 Limit > Request 時，實際利用率是可以超過 100%。

避坑指南：對于較為重要的應用，應當設置 Request=Limit 保證資源的獨占。對于可以容忍資源共享的應用，對應的期望利用率也不應設置的過高，在集群資源緊張時，超量使用資源的 Pod 很有可能會被殺死，從而造成服務中斷。

誤區三：彈性行為總是滯后的，擴縮行為與心理預期不符

現象：指標突增時，HPA 不會立刻擴容，且擴容可能是分多次進行，最終穩定時的實例數也與預期不同。

原因剖析：HPA 的設計架構決定了，HPA 擴/縮容總是滯后的，且擴/縮容收到彈性行為（behavior）與容忍度共同作用。其中彈性行為限制了擴/縮容速率，不會一口氣擴/縮到期望實例數。而容忍度會忽略指標的小幅度變化，從而導致在多次擴容的場景下，最終計算的實例數可能與一開始計算出的實例數不同。

避坑指南：閱讀下文了解一下 HPA 工作原理，配置合理的彈性行為（behavior）。

HPA 工作機理

Cloud Native

在打破認知誤區前，我們有必要梳理一下 HPA 的工作機理。

如圖所示，HPA 控制器執行彈性功能主要分為四個步驟：

監聽 HPA 資源，一旦生成 HPA 資源或者是更改 HPA 配置，HPA 控制器能及時感知并調整。

從 Metrics API 獲取對應的指標數據，這里的 Metrics Server 又可以分為三類：

Kubernetes MetricServer：提供容器級別CPU/內存使用量

Custom MetricServer：提供來自Kubernetes集群自定義資源的指標數據

External MetricServer：提供來自Kubernetes集群外的指標數據?

每個指標項單獨計算期望實例數，最后取所有期望實例數中的最大值，作為當前工作負載的期望實例數

調整對應的工作負載

其中步驟 2-4 約每 15 秒執行一次，如需改變時間周期，可以調整 KCM 的配置參數--horizontal-pod-autoscaler-sync-period。

01

數據源

如上圖所示，HPA 目前提供了五種指標來源，以及三種指標服務（MetricsServer），簡單介紹如下：

Resource：提供 Pod 級別的 CPU/內存使用量

ContainerResource：提供容器級別的 CPU/內存使用量

Object：提供 Kubernetes 集群內任意資源的相關指標

Pods：提供 Kubernetes集群內 pod 相關的指標

External：提供 Kubernetes 集群外的指標數據

值得一提的是，在自建 Kubernetes 場景下，這三種 MetricsServer 都需要額外安裝，它們均運行于 KCM 之外。下表列舉了幾種 Kubernetes 集群 MetricsServer 的部署情況。

	自建Kubernetes	阿里云容器服務	EDAS托管集群
Kubernetes MetricsServer	手動安裝	自動安裝	自動安裝
Custom MetricsServer （如Prometheus Adapter）	手動安裝	手動安裝	手動安裝
External MetricsServer （如KEDA）	手動安裝	手動安裝	自動安裝

02

指標計算方法

HPA 提供了三種期望值類型：

總量（Value）

平均量（AverageValue）= 總量 / 當前實例數

利用率（Utilization）= 平均量 / Request

值得一提的是，利用率是基于 Request 進行計算的，所以沒有設置 Request 的場景下，HPA 可能無法正常工作。

下圖介紹了五種指標來源支持的期望類型，不難看出所有指標來源都支持平均量。

對于單個指標的期望實例數計算規則如下：

這里面引入了容忍度的概念，即認為在期望值附近小范圍的抖動是可以容忍忽略的。這個參數的來源是因為指標值是一個一直在抖動變化的值，如果不忽略微小的變動，那么很有可能造成應用不斷的擴容縮容，進而影響整個系統的穩定性。

如下圖所示，當指標值落入粉色區域內（容忍度范圍）時，期望實例數等于當前實例數。粉色區域（容忍度范圍）的上下限分別是 0.9 倍期望值與 1.1 倍期望值。

對于配置了多條指標規則，最終期望實例數計算規則如下：

其中 target1, ..., target n 分別是每個指標計算出來的期望實例數。

用一句話簡要概括計算方法：單個指標波動小時忽略不計，多個指標之間取最大值，最終實例數會落在下限和上限之間。

03

擴縮行為

在某些情況下，指標數據會有一個頻繁且大幅度的抖動。如下圖所示的一段 CPU 指標數據，存在一些指標抖動或間歇流量下降導致利用率下降，指標的變化范圍已經超出了容忍度的范圍。此時，從應用穩定性角度來看，我們不期望應用縮容。為了解決這個問題，HPA引入了配置來控制擴縮容，即擴縮行為（behavior），它是在HPA（autoscaling/v2beta2）中引入，要求 Kubernetes 集群版本>=1.18。

HPA 的彈性行分為擴容行為和縮容行為。行為具體由以下三部分組成：

• 穩定窗口：穩定窗口會參考過去一段時間計算出的期望實例數，選取極值作為最終結果，從而保證系統在一段時間窗口內是穩定的。對于擴容取極小值，對于縮容取極大值。

• 步長策略：限制一段時間內實例變化的范圍。由步長類型、步長值、時間周期三個部分組成。值得一提的是時間周期這個概念與上述的穩定窗口是兩回事，此處的時間周期定義了回溯多長歷史時間，計算實例數變化情況。

• 選擇策略：用于選取多個步長策略計算后的結果，支持 取最大值、取最小值、關閉 這三種策略。

03

回顧與總結

Aliware

至此，我們已經大致了解了 HPA 的工作機理。合理利用 HPA 可以有效提升資源利用率，在這之中我們總結了一些注意事項，熟記這些點可以在使用 HPA 時“有效避坑”。

HPA 的設計架構導致了 HPA 只能被動響應指標進行彈性擴縮，這種模式下，彈性滯后是一定存在的。目前阿里云容器服務推出了帶預測能力的 AHPA，可以有效減少彈性遲滯。

HPA 的利用率計算方法是基于 Request，實際利用率/期望利用率超過 100%是正常的，配置較高的期望利用率需要合理規劃集群資源和審視相應風險。

HPA 中的容忍度概念能緩解指標波動帶來的系統震蕩問題，但與此同時引入的擴容死區問題需要運維人員避開。

HPA 的設計架構允許擴展各種類型指標，需要開發/安裝相應的 MetricsServer，如 EDAS 則為用戶提供了微服務 RT 和 QPS 指標。

HPA 中存在擴縮容行為，即使不配置相應參數也有默認行為，擴容行為的穩定窗口默認是 0，如果應用常因噪聲數據造成擴容，可以設置一個較短的擴容穩定窗口規避尖銳噪聲。

單個 HPA 支持配置多個指標進行彈性，切勿對單個應用配置多個 HPA，會相互影響，導致應用震蕩。

云原生場景下彈性能力更為豐富，可供彈性的指標也更具備業務定制能力。應用 PaaS 平臺（如企業級分布式應用服務 EDAS）能結合云廠商在計算、存儲、網絡上的技術基礎能力，能讓使用云的成本更低。但是這里對于業務應用會提出一點點挑戰（如：無狀態/配置代碼解耦等等）。從更廣的側面來看，這是云原生時代應用架構面臨的挑戰。不過應用越來越原生的話，云的技術紅利也會離我們越來越近。

參考鏈接

[1] Prometheus Adapter

https://github.com/kubernetes-sigs/prometheus-adapter

[2]?KEDA

https://github.com/kedacore/keda

[3]?HorizontalPodAutoscaler Walkthrough

https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/

[4]?Resource metrics pipeline

https://kubernetes.io/docs/tasks/debug/debug-cluster/resource-metrics-pipeline/

[5]?Horizontal Pod Autoscaling

https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/

[6]?HPA 常見問題與診斷

https://help.aliyun.com/document_detail/186980.html

[7]?EDAS 自動彈性擴縮容

https://help.aliyun.com/document_detail/178448.html

擴展閱讀

Horizontal Pod Autoscaler with Arbitrary Metrics

https://github.com/kubernetes/design-proposals-archive/blob/main/autoscaling/hpa-v2.md

總結

以上是生活随笔為你收集整理的Kubernetes HPA 的三个误区与避坑指南的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。