Kubernetes 的 HPA 原理详解
1. HPA解決的問題
HPA全稱是 Horizontal Pod Autoscaler，也就是對k8s的workload的副本數進行自動水平擴縮容（scale）機制，也是k8s里使用需求最廣泛的一種Autoscaler機制，在開始詳細介紹HPA之前，先簡單梳理下k8s autoscale的整個大背景。
k8s被譽為新一代數據中心操作系統（DCOS），說到操作系統我們自然想到其定義：管理計算機的軟硬件資源的系統，k8s也一樣其核心工作也是管理整個集群的計算資源，并按需合理分配給系統里的程序（以Pod為基礎的各種workload）。
其本質是解決資源與業務負載之間供需平衡的問題，隨著業務需求和部署規模的增大，k8s集群就要相應擴容計算資源，集群擴容的最直接的辦法是新增資源，一般單機器很難垂直擴展（k8s node也不支持），所以一般都是直接增加節點。但是隨著機器的不斷增加成本也不斷加大，而實際上大量服務大部分時間負載很低導致機器的整體使用率很低，一方面業務為了應對每日隨機流量高峰會把副本數盡量擴得很高，另一方面業務方并不能準確評估服務實際需要的CPU等資源，也出現大量浪費。
為了解決業務服務負載時刻存在的巨大波動和資源實際使用與預估之間差距，就有了針對業務本身的“擴縮容”解決方案： Horizontal Pod Autoscaler（HPA）和 Vertical Pod Autoscaler（VPA）。
為了充分利用集群現有資源優化成本，當一個資源占用已經很大的業務需要擴容時，其實可以先嘗試優化業務負載自身的資源需求配置（request與實際的差距），只有當集群的資源池確實已經無法滿足負載的實際的資源需求時，再調整資源池的總量保證資源的可用性，這樣可以將資源用到極致。
所以總的來說彈性伸縮應該包括：
其中VPA和HPA都是從業務負載角度從發的優化，VPA是解決資源配額（Pod的CPU、內存的limit/request）評估不準的問題，HPA則要解決的是業務負載壓力波動很大，需要人工根據監控報警來不斷調整副本數的問題，有了HPA后，被關聯上HPA的deployment，后續副本數修改就不用人工管理，HPA controller將會根據業務忙閑情況自動幫你動態調整。當然還有一種固定策略的特殊HPA: cronHPA，也就是直接按照cron的格式設定擴容和縮容時間及對應副本數，這種不需要動態識別業務繁忙度屬于靜態HPA，適用于業務流量變化有固定時間周期規律的情況，這種比較簡單可以算做HPA的一種簡單特例。
2. 原理架構
既然是自動根據業務忙閑來調整業務工作負載的副本數，其實HPA的實現思路很容易想到：通過監控業務繁忙情況，在業務忙時，就要對workload擴容副本數；等到業務閑下來時，自然又要把副本數再縮下去。所以實現水平擴縮容的關鍵就在于：
- 如何識別業務的忙閑程度
- 使用什么樣的副本調整策略
kubernetes提供了一種標準metrics接口（整個HPA及metrics架構如下圖所示），HPA controller通過這個統一metrics接口可以查詢到任意一個HPA對象關聯的deployment業務的繁忙指標metrics數據，不同的業務的繁忙指標均可以自定義，只需要在對應的HPA里定義關聯deployment對應的metrics即可。
標準的metrics查詢接口有了，還需要實現metrics API的服務端，并提供各種metrics數據，我們知道k8s的所有核心組件之間都是通過apiserver進行通信，所以作為k8s API的擴展，metrics APIserver自然選擇了基于API Aggregation聚合層，這樣HPA controller的metrics查詢請求就自動通過apiserver的聚合層轉發到后端真實的metrics API的服務端（對應下圖的Promesheus adapter和Metrics server）。
最早的metrics數據是由metrics-server提供的，只支持CPU和內存的使用指標，metrics-serve通過將各node端kubelet提供的metrics接口采集到的數據匯總到本地，因為metrics-server是沒有持久模塊的，數據全在內存中所以也沒有保留歷史數據，只提供當前最新采集的數據查詢，這個版本的metrics對應HPA的版本是autoscaling/v1（HPA v1只支持CPU指標）。
后來為了適應更靈活的需求，metrics API開始擴展支持用戶自定義metrics指標（custom metrics），自定義數據則需要用戶自行開發custom metrics server，社區有提供專門的custom adpater框架 custom-metrics-apiserver ，該框架定義了Custom和External的MetricsProvider接口（如下所示），需要自行實現對應的接口。
type MetricsProvider interface {CustomMetricsProviderExternalMetricsProvider }type CustomMetricsProvider interface {// GetMetricByName fetches a particular metric for a particular object.// The namespace will be empty if the metric is root-scoped.GetMetricByName(name types.NamespacedName, info CustomMetricInfo, metricSelector labels.Selector) (*custom_metrics.MetricValue, error)// GetMetricBySelector fetches a particular metric for a set of objects matching// the given label selector. The namespace will be empty if the metric is root-scoped.GetMetricBySelector(namespace string, selector labels.Selector, info CustomMetricInfo, metricSelector labels.Selector) (*custom_metrics.MetricValueList, error)// ListAllMetrics provides a list of all available metrics at// the current time. Note that this is not allowed to return// an error, so it is reccomended that implementors cache and// periodically update this list, instead of querying every time.ListAllMetrics() []CustomMetricInfo }type ExternalMetricsProvider interface {GetExternalMetric(namespace string, metricSelector labels.Selector, info ExternalMetricInfo) (*external_metrics.ExternalMetricValueList, error)ListAllExternalMetrics() []ExternalMetricInfo }目前社區已經有人基于promethus server的監控數據源，實現看一個promethus adapter來提供 custom metrics server服務，如果需要的自定義指標數據已經在promesheus里有了，可以直接對接使用，否則要先把自定義的指標數據注入到promesheus server里才行。因為HPA的負載一般來源于監控數據，而promesheus又是CNCF標準的監控服務，所以這個promesheus adapter基本也可以滿足我們所有自定義metrics的HPA的擴展需求。
講清楚了metrics，也就解決了識別業務的忙閑程度的問題，那么HPA Controller是怎么利用metrics數據進行擴縮容控制的呢，也就是使用什么樣的副本調整機制呢？
如上圖右邊所示，用戶需要在HPA里設置的metrics類型和期望的目標metrics數值，HPA Controller會定期（horizontal-pod-autoscaler-sync-period配置，默認15s）reconcile每個HPA對像，reconcile里面又通過metrics的API獲取該HPA的metrics實時最新數值（在當前副本數服務情況下），并將它與目標期望值比較，首先根據比較的大小結果確定是要擴縮容方向：擴容、縮容還是不變，若不需要要進行擴縮容調整就直接返回當前副本數，否則才使用HPA metrics 目標類型對應的算法來計算出deployment的目標副本數，最后調用deployment的scale接口調整當前副本數，最終實現盡可能將deployment下的每個pod的最終metrics指標（平均值）基本維持到用戶期望的水平。注意HPA的目標metrics是一個確定值，而不是一個范圍。
3. HPA的metrics的分類
要支持最新的custom（包括external）的metrics，也需要使用新版本的HPA：autoscaling/v2beta1，里面增加四種類型的Metrics：Resource、Pods、Object、External，每種資源對應不同的場景，下面分別說明：
-
Resource支持k8s里Pod的所有系統資源（包括cpu、memory等），但是一般只會用cpu，memory因為不太敏感而且跟語言相關：大多數語言都有內存池及內置GC機制導致進程內存監控不準確。
-
Pods類型的metrics表示cpu，memory等系統資源之外且是由Pod自身提供的自定義metrics數據，比如用戶可以在web服務的pod里提供一個promesheus metrics的自定義接口，里面暴露了本pod的實時QPS監控指標，這種情況下就應該在HPA里直接使用Pods類型的metrics。
-
Object類型的metrics表示監控指標不是由Pod本身的服務提供，但是可以通過k8s的其他資源Object提供metrics查詢，比如ingress等，一般Object是需要匯聚關聯的Deployment下的所有的pods總的指標。
-
External類型的metrics也屬于自定義指標，與Pods和Object不同的是，其監控指標的來源跟k8s本身無關，metrics的數據完全取自外部的系統。
在HPA最新的版本 autoscaling/v2beta2 中又對metrics的配置和HPA擴縮容的策略做了完善，特別是對 metrics 數據的目標指標值的類型定義更通用靈活：包括AverageUtilization、AverageValue和Value，但是不是所有的類型的Metrics都支持三種目標值的，具體對應關系如下表。
HPA里的各種類型的Metrics和Metrics Target Type的對應支持關系表
| Resource（pod’s cpu/memory etc.） | Yes | Yes | No | pods metrics list |
| Pods（pod’s other metrics） | No | Yes | No | pods metrics list |
| Object（k8s object） | No | Yes | Yes | object metrics |
| External（not k8s object） | No | Yes | Yes | external metrics list |
4. HPA的使用說明
先看個最簡單的HPA的定義的例子
apiVersion: autoscaling/v2beta2 kind: HorizontalPodAutoscaler metadata:name: php-apache spec:scaleTargetRef:apiVersion: apps/v1kind: Deploymentname: php-apacheminReplicas: 1maxReplicas: 10metrics:- type: Resourceresource:name: cputarget:type: UtilizationaverageUtilization: 50從上面的例子可以看出，HPA的spec定義由三個必填部分組成：
HPA控制的目標workload，即scaleTargetRef，理論上HPA可以對任意支持scale子接口（ sub-resource ）的workload做彈性伸縮，不過statefulset一般代表有狀態服務，副本不可隨便修改，而Job一般代表短生命周期的，所以基本可以認為HPA目前是專門控制deployment的擴縮容的（不建議直接控制RS，否則將無法滾動升級）。
彈性擴縮容的上下邊界，minReplicas和maxReplicas，也就是說HPA的擴縮容也不能是漫無邊際，如果計算出的副本數超過max則統一取maxReplicas，maxReplicas是為了保護k8s集群的資源被耗盡，minReplicas則相反，而且minReplicas必須不大于maxReplicas，但是也要大于0（k8s v1.16之后才放開允許Objetct和External類型的metrics的minReplicas為0，需要apiserver開啟–feature-gates mapStringBool HPAScaleToZero=true），兩者相等就相當于關閉了自動伸縮功能了，總的來說minReplicas和maxReplicas邊界機制避免metrics數據異常導致的副本數不受控，特別是HPA在k8s最新的v1.18版本也依然是alpha特性，強烈建議大家謹慎設置這兩個邊界。
metrics指標類型和目標值，在autoscaling/v1里只有targetCPUUtilizationPercentage，autoscaling/v2beta1開始就擴展為metrics數組了，也就是說一個HPA可以同時設置多個類型維度的metrics目標指標，如果有多個HPA 將會依次考量各個指標，然后最終HPA Controller選擇一個會選擇擴縮幅度最大的那個為最終擴容副本數。在最新的autoscaling/v2beta2版本的HPA中，metrics type共有4種類型：Resource、Pods、Object、External，target里則定義了metrics的目標期望值，這里target的type也有三種類型Utilization，AverageValue和 Value，不同的metrics type都只能支持部分target type（詳見上面表格）
此外，在autoscaling/v2beta2的HPA的spec里還新增了一個Behavior可選結構，它是用來精確控制HPA的擴容和縮容的速度，下面會專門講。
完整的HPA的定義可參考k8s的官方API文檔。
默認HPA spec里不配置任何metrics的話k8s會默認設置cpu的Resouce，且目標類型是AverageUtilization value為80%。
5. HPA擴縮容算法具體實現
算法模型
在HPA控制器里，針對不同類型的metrics和不同metrics下的target 類型，都有獨立的計算算法，雖然有很多細節差異，但是總的來說，計算公式可以抽象為：
desiredReplicas = ceil[currentReplicas * ( currentMetricValue / desiredMetricValue )]例如如果配置 target value 是100m，當前從metrics接口讀取到的 metrics value 是 200m，說明最新的副本數應該是當前的 200m/100m=2.0倍， 如果當前副本數為 2，則HPA計算后的期望副本數是2*2.0=4；
而如果當前從metrics接口讀取到的 metrics value是 50m，說明最新的副本數應該是 當前的 50m/100m=0.5倍，也就是最終scale的副本數將為1。
當然實際上當前的metrics value并不一定就只有一個值，如果是 Resource或者Pods類型的metrics，實際上 GetMetrics 會返回一批關聯的Pods對應的metrics數據，一般需要做一個平均后再與target的metrics的做比較。
此外，為了保證結果盡量精確，metrics的計算都是浮點數計算，但是最終的副本數肯定要是整數，為了統一HPA控制器在最后，都會對計算出的浮點數副本數向上取整，也就是上面公式里最外層的ceil函數。
擴縮容threshold控制
當然上面的公式也只是純數學模型，實際工程實現還要考慮很多現實細節問題：比如監控數據可能會有一定的誤差，如果GetMetrics里讀到數據不穩定就會造成算出的期望副本數不穩定，導致deployment一會擴縮1個副本，一會又擴容1副本。所以為了避免這種問題kube-controller-manager里有個HPA的專屬參數 horizontal-pod-autoscaler-tolerance 表示HPA可容忍的最小副本數變化比例，默認是0.1，如果期望變化的副本倍數在[0.9, 1.1] 之間就直接停止計算返回。那么如果相反，某個時間點開始metrics數據大幅增長，導致最后計算的副本數變化倍數很大，是否HPA控制器會一步擴容到位呢？ 事實上HPA控制器為了避免副本倍增過快還加了個約束：單次倍增的倍數不能超過2倍，而如果原副本數小于2，則可以一次性擴容到4副本，注意這里的速率是代碼寫死不可用配置的。(這個也是HPA controller默認的擴縮容速率控制，autoscaling/v2beta2的HPA Behavior屬性可以覆蓋這里的全局默認速率)
縮容冷卻機制（cooldown delay）
雖然HPA同時支持擴容和縮容，但是在生產環境上擴容一般來說重要性更高，特別是流量突增的時候，能否快速擴容決定了系統的穩定性，所以HPA的算法里對擴容的時機是沒有額外限制的，只要達到擴容條件就會在reconcile里執行擴容（當前一次至少擴容到原來的1.1倍）。但是為了避免過早縮導致來回波動（thrashing ），而容影響服務穩定性甚，HPA的算法對縮容的要求比較嚴格，通過設置一個默認5min（可配置horizontal-pod-autoscaler-downscale-stabilization）的滑動窗口，來記錄過去5分鐘的期望副本數，只有連續5分鐘計算出的期望副本數都比當前副本數小，才執行scale縮容操作，縮容的目標副本數取5分鐘窗口的最大值。
總的來說k8s HPA算法的默認擴縮容原則是：快速擴容，謹慎縮容。
Pod的metrics數據過濾檢查機制
一般情況下HPA的數據指標都來自k8s的Pod里，但是實際上每次創建deployment、對deployment做擴縮容，Pod的副本數和狀態都會不斷變化，這就導致HPA controller在reconcile里獲取到的metrics的指標肯定會有一定的異常，比如Pod還沒有Running、Pod剛剛啟動還在預熱期、或者Pod中間臨時OOM恰逢采集時刻、或者Pod正處在刪除中，這些都可能導致metrics指標缺失。如果有任何 pod 的指標缺失，HPA控制器會采取最保守的方式重新計算平均值， 在需要縮小時假設這些 pod 消耗了目標值的 100%， 在需要放大時假設這些 pod 消耗了0%目標值， 這可以在一定程度上抑制伸縮的幅度。
具體來說，HPA算法里把deployment下的所有Pod的metrics的指標數據分為三類：
-
ready pods list， deployment下處于Running狀態的Pod且HPA controller成功通過GetMetrics獲取的pod metrics的列表
-
ignore pods list， deployment下處于pending狀態的Pods或者（僅對Resouce類似的cpu metrics有效）雖然pod running了但controller成功通過GetMetrics獲取的pod metrics，但是pod的啟動時間在配置的initial-readiness-delay和cpu-initialization-period 保護期內。
-
missing pods list，deployment下處于running狀態的pod（非pending、非failed、非deleted狀態）但是HPA controller通過GetMetrics無法獲取的pod metrics的列表
在計算pod的平均metrics值的時候，統一把 ignore pods的metrics設置為最小值0，如果HPA擴縮容的方向是擴容，把missing pods的metrics也設置為最小值0，如果是縮容方向則把missing pods的metrics也設置為最大值（如果是Resouce類型，最大值是Pod的request值，否則最大值就是target value）。
6. HPA的scale速度控制
講解完HPA的原理及具體算法后，最后再重點介紹HPA在擴縮容的速率控制機制。在前面講過HPA controller里默認擴縮容總原則是：快速擴容，謹慎縮容，擴容上雖然強調快，但是速度卻是固定的最大于當前副本數的2倍速度，對于想設置其他倍數或者說想精確控制副本數增量的方式的需求都是不行的；縮容上則僅僅只是靠設置一個集群全局的窗口時間，窗口期過后也就失去控制能力。
為了能更精準靈活地控制HPA的autoscale速度，從k8s v1.18（依賴HPA autoscaling/v2beta2）開始HPA的spec里新增了behavior結構（如下定義）擴展了HPA的scale速度控制策略，該結構支持每個HPA實例獨立配置擴縮容的速度，而且還可以單獨配置擴容scaleUp和縮容scaleDown使用不同的策略。
在擴容策略ScalingRules里，有個StabilizationWindowSeconds用來記錄最近計算的期望副本數，效果跟上面縮容的cooldown delay機制一樣，每次都會選擇窗口里所有推薦值的最大值，保證結果的穩定性。
Policies是一個HPAScalingPolicy數組，每個HPAScalingPolicy才是真正控制速度的部分：擴縮容計算周期和周期內擴縮容變化的最大幅度，PeriodSeconds周期單位是秒，Percent是設置副本數每次變化的百分比，擴容后副本數是：（1+PercentValue%）* currentReplicas，縮容后副本數是：（1-PercentValue%）* currentReplicas； Pods則是設置每次副本數變化的絕對值。
次外，每個方向還可以設置多個策略，多個策略會同時計算最終副本數，最后結果則是通過SelectPolicy：Max/Min/Disabled做聚合，注意在縮容時Max會選擇計算副本數最小的那個，Min會選擇計算的副本數最大的那個，Disabled表示禁止這個方向的擴縮容。
type HorizontalPodAutoscalerBehavior struct {// scaleUp is scaling policy for scaling Up.// If not set, the default value is the higher of:// * increase no more than 4 pods per 60 seconds// * double the number of pods per 60 secondsScaleUp *HPAScalingRules// scaleDown is scaling policy for scaling Down.// If not set, the default value is to allow to scale down to minReplicas pods, with a// 300 second stabilization window (i.e., the highest recommendation for// the last 300sec is used).ScaleDown *HPAScalingRules }type HPAScalingRules struct {// StabilizationWindowSeconds is the number of seconds for which past recommendations should be// considered while scaling up or scaling down.StabilizationWindowSeconds *int32// selectPolicy is used to specify which policy should be used.// If not set, the default value MaxPolicySelect is used.SelectPolicy *ScalingPolicySelect// policies is a list of potential scaling polices which can used during scaling.// At least one policy must be specified, otherwise the HPAScalingRules will be discarded as invalidPolicies []HPAScalingPolicy }// HPAScalingPolicyType is the type of the policy which could be used while making scaling decisions. type HPAScalingPolicyType string const (// PodsScalingPolicy is a policy used to specify a change in absolute number of pods.PodsScalingPolicy HPAScalingPolicyType = "Pods"// PercentScalingPolicy is a policy used to specify a relative amount of change with respect to// the current number of pods.PercentScalingPolicy HPAScalingPolicyType = "Percent" )// HPAScalingPolicy is a single policy which must hold true for a specified past interval. type HPAScalingPolicy struct {// Type is used to specify the scaling policy.Type HPAScalingPolicyType// Value contains the amount of change which is permitted by the policy.Value int32// PeriodSeconds specifies the window of time for which the policy should hold true.// PeriodSeconds must be greater than zero and less than or equal to 1800 (30 min).PeriodSeconds int32 }HPA的Behavior如果不設置，k8s會自動設置擴縮容的默認配置, 具體內容如下：
behavior:scaleDown:stabilizationWindowSeconds: 300policies:- type: Percentvalue: 100periodSeconds: 15scaleUp:stabilizationWindowSeconds: 0policies:- type: Percentvalue: 100periodSeconds: 15- type: Podsvalue: 4periodSeconds: 15selectPolicy: Max默認配置里分別定義了擴容和縮容的速率策略，縮容按照百分比，每15秒最多減少currentReplicas*100%個副本（但最終不可小于minReplicas），且縮容后的最終副本不得低于過去300s內計算的歷史副本數的最大值；擴容則采用快速擴容，不考慮歷史計算值（窗口時間為0），每15秒副本翻倍或者每15秒新增4個副本（取最大值），即：max(2*currentReplicas,4)。這個默認Behavior的默認配置是否有點似曾相似的感覺，沒錯它跟HPA沒有Behavior時的默認快速擴容，縮容的策略是完全一致的。
不同擴縮容速率需求場景下的behavior用法舉例
場景1：擴容越快越好
如果業務希望能盡快的擴容，可以配置大的 percent值，可以按照如下配置：
behavior:scaleUp:policies:- type: Percentvalue: 900periodSeconds: 60假如 deployment的副本數最開始是1，那么每隔60s的的極限擴容副本數的變化如下：
1 -> 10 -> 100 -> 1000
也就是每個擴容period都是（1+900%）=10倍的速度，不過最大副本數依然不可用超過HPA 的 maxReplicas上界，縮容則使用默認行為。當然Percent類型可能對資源消耗波動特別大，如果希望資源消耗可控，可以按絕對副本數來Pods類型來配置。
場景 2: 擴容越快越好但要逐步縮容
當業務希望能盡快的擴容，但是縮容需要緩慢一些時，可以使用如下配置：
behavior:scaleUp:policies:- type: Percentvalue: 900periodSeconds: 60scaleDown:policies:- type: Podsvalue: 1periodSeconds: 600假如 pod 最開始數量為 1，那么擴容路徑如下：
1 -> 10 -> 100 -> 1000
同時，縮容路徑如下 (每 10 分鐘縮容一次，每次減少一個 pod)：
1000 -> 1000 -> 1000 -> … (another 7 min) -> 999 （最小不低于minReplicas）
場景 3: 逐步擴容、正常的縮容
當希望緩慢的擴容、正常的縮容，可以使用如下配置：
behavior:scaleUp:policies:- type: Podsvalue: 1periodSeconds: 600假如 pod 最開始數量為 1，那么擴容路徑如下：
1 -> 2 -> 3 -> 4
場景 4: 正常擴容、不要縮容
如果希望能正常的擴容，但是不要自動縮容，可以使用如下配置：
behavior:scaleDown:policies:- type: Percent 或 Podsvalue: 0periodSeconds: 600把縮容的百分比或者pod 都置為 0，那么就永遠不會縮容。
或者直接設置 selectPolicy: Disabled。
場景 5: 延后縮容
一般在流量激增時，都希望快速擴容應對，那么發現流量降低是否應該立馬縮容呢，加入只是臨時的流量降低呢，這樣就可能導致短時間反復的擴縮容，為了避免這種情況，縮容時應該更謹慎些，可以使用延遲縮容機制：delaySeconds(這個跟 kube-controller-manager 的 horizontal-pod-autoscaler-downscale-stabilization 非常類似，但是這個參數是全局的，如果HPA有配置優先使用delaySeconds），配置如下：
behavior:scaleDown:policies:- type: Podsvalue: 5periodSeconds: 600那么，每次縮容最多減少 5 個 pod，同時每次縮容，至少要往前看 600s 窗口期的所有推薦值，每次都從窗口期中選擇最大的值。這樣，除非連續600s的推薦值都比之前的最大副本數小，才開始縮容。
7. 總結
總的來說，從k8s v1.18開始HPA的機制已經算比較靈活了，在擴縮容識別指標上可以使用Pod的系統cpu、內存指標，也可以Pods自身暴露的自定義metrics指標，還可以支持外部的業務指標；在具體自定義實現上也提供了標準的擴展框架，還有社區其他人貢獻的promesheus adapter。在擴縮容速度上也通過相對百分比和絕對 Pods數變化，可以獨立控制單位時間內最大的擴容和縮容，此外還通過自定義窗口時間機制保證副本變化的穩定性。
需要說明下，HPA特性還依然處于非正式GA版本，社區相關的issue有些沒有解決，包括HPA縮容的最小副本不允許為0（Resouce和Pods類型的metrics如果在pod副本為0時，將采集不到metrics，需要依賴額外的流量激活機制，Knative集成了service mesh有對流量的劫持所以可以直接實現0副本），參數控制粒度還不夠靈活，而且HPA controller的reconcile循環不支持多線程并發，所以也一定程度上影響了一個k8s集群內HPA的對象數過多的時效性，隨著k8s HPA關注和使用人數的增多，相信這些問題也都會逐步優化掉。
網易輕舟之前就已經集成了基于業務容器的CPU、內存指標的HPA，網易傳媒業務很早就開始在生產環境使用這個特性，不過隨著離線業務的容器化遷移和離在線混部的廣泛使用，傳媒業務團隊也提出了希望根據任務隊列的大小這樣的外部指標來進行彈性伸縮，所以輕舟也開始支持自定義metrics的HPA的功能，目前相關配套已經開發完畢，正逐步應用在網易內部業務中，未來也將會跟隨輕舟新版本對外發布。
作者：婁超，網易數帆輕舟事業部資深工程師
總結
以上是生活随笔為你收集整理的Kubernetes 的 HPA 原理详解的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Kubernetes(K8s)基本概念：
- 下一篇： Zotero使用指南04：群组功能