目前 Kubernetes 的 Pod 水平自動伸縮(HPA，Horizontal Pod Autoscaler)已在業界廣泛應用。但對一些特殊的 Pod(如一些有狀態的 Pod)，HPA 并不能很好地解決資源不足的問題。這就引出 Pod 垂直自動伸縮(VPA，Vertical Pod Autoscaler)，本文主要介紹 Kubernetes 社區對 Pod 垂直自動伸縮組件的開發規劃。

VPA定義

垂直自動伸縮(VPA，Vertical Pod Autoscaler) 是一個基于歷史數據、集群可使用資源數量和實時的事件(如 OMM， 即 out of memory)來自動設置Pod所需資源并且能夠在運行時自動調整資源基礎服務。

介紹

背景

計算資源

資源服務質量

準入控制器

外部準入webhooks

目標

VPA有兩個目標：

通過自動配置資源請求來減少運維成本。

在提高集群資源利用率的同時最小化容器出現內存溢出或 CPU 饑餓的風險。

相關特性

水平自動伸縮(Horizontal Pod Autoscaler，HPA)

HPA 是基于實時的CPU利用率或者其他的一些特定信號動態調整 Replication controller 中 Pod 數量的基礎服務。

通常用戶在無狀態的工作負載時選用 HPA，在有狀態的工作負載時選用 VPA。也有一些場景下會混合使用。

集群自動伸縮(Cluster Autoscaler)

集群自動伸縮基于集群整體的資源利用率動態調整 Kubernetes 集群的大小。

集群自動伸縮、HPA 和 VPA 提供了一個完整的自動伸縮解決方案。

初始資源(Initial resources)

初始資源基于歷史資源利用率提供初始資源請求，它僅僅在Pod創建時觸發，VPA打算繼承使用這個特性。

原地升級(In-place updates)

原地升級是一個計劃中的功能,在節點上有足夠資源的情況下，原地升級無需殺死容器就能夠調整已存在容器的資源的請求和限制。

VPA將從這種能力中受益匪淺，但它不被視為最小可行產品 ( inimum Viable Product, MVP) 的阻擋者。

資源估計(Resource estimation)

資源估計是另外一個計劃中的功能，它可以通過暫時回收運行中容器的暫未使用的資源來提高資源利用率。

資源估計與 VPA 的不同在于它基于的時間表比較短(僅基于本地的短期的歷史數據)，回收以后再提供的質量低，不提供初始資源預測。VPA 和資源估計是互補的。

需求

功能

VPA 能夠在 Pod 提交時設置容器的資源(CPU和內存的請求和限制)。

VPA能夠調整已存在的 Pod 的容器資源，特別是能夠對 CPU 饑餓和內存溢出等事件作出響應。

當 VPA 重啟 Pod 時，它必須考慮中斷服務的成本。

用戶能夠配置 VPA 的在資源上的固定限制,特別是最小和最大資源請求。

VPA 要與 Pod 控制器兼容，最起碼要與

Deployment

兼容。特別地：

資源更新的時候不能干擾 spec 更新或和 spec 更新沖突。

在已有的部署中，能夠滾動更新 VPA 的策略。

在創建 Pod 時能夠盡快開始遵循 VPA 策略,特別是對于一些只有VPA策略應用以后才能被調度的 Pod 。

可用性

重量級的組件(數據庫或推薦器)出故障不會阻塞重新創建已存在的 Pod 。Pod 創建路徑非常關鍵的組件必須設計成高可用。

可擴展性

在原地升級組件開發好后, VPA 能夠使用它。

設計

綜述

提出新的API資源: VerticalPodAutoscaler 。它包括一個標簽識別器 label selector(匹配Pod)、資源策略 resources policy(控制VPA如何計算資源)、更新策略 update policy(控制資源變化應用到Pod)和推薦資源信息。

VPA Recommender 是一個新的組件，它考慮集群中來自 Metrics Server 的所有 Pod 的資源利用率信號和內存溢出事件。

VPA Recommender 會監控所有 Pod，為每個 Pod 持續計算新的推薦資源，并將它們存儲到 VPA Object 中。

VPA Recommender 會暴露一個同步 API 獲取 Pod 詳細信息并返回推薦信息。

所有的 Pod 創建請求都會通過 VPA Admission Controller。如果 Pod 與任何一個 VPA 對象匹配，那么 Admission controller 會依據 VPA Recommender 推薦的值重寫容器的資源。如果 Recommender 連接不上，它將會返回 VPA Object 中緩存的推薦信息。

VPA Updater 是負責實時更新 Pod 的組件。如果一個 Pod 使用 VPA 的自動模式，那么Updater 會依據推薦資源來決定如何更新。在 MVP 模式中，這需要通過刪除 Pod 然后依據新的資源重建 Pod 來實現，這種方法需要 Pod 屬于一個 Replica Set(或者其他能夠重新創建它的組件)。在未來，Updater 會利用原地升級，因為重新創建或者重新分配Pod對服務是很有破壞性的，必須盡量減少這種操作。

VPA 僅僅控制容器的資源請求,它把資源限制設置為無限,資源請求的計算基于對當前和過去運行狀況的分析。

History Storage 是從 API Server 中獲取資源利用率信號和內存溢出并將它們永久保存的組件。Recommender 在一開始用這些歷史數據來初始化狀態。History Storage 基礎的實現是使用 Prometheus。

體系架構

VPA Architecture Diagram

API

我們提出了一個新的類型的API對象 VertialPodAutoscaler，它包含了擴容的目標，也就是用于匹配 Pod 的 label seletctor 和兩個策略模塊：更新策略 update policy 和資源策略resources policy。此外他還持有 VPA 計算的最新的推薦信息。

VPA API 對象綜述

//VerticalPodAutoscaleristheconfigurationforaverticalpod

//autoscaler,whichautomaticallymanagespodresourcesbasedonhistoricaland

//realtimeresourceutilization.

typeVerticalPodAutoscalerstruct{

metav1.TypeMeta

//Standardobjectmetadata.

//Moreinfo:https://git.k8s.io/community/contributors/devel/api-conventions.md#metadata

//+optional

metav1.ObjectMeta

//Specificationofthebehavioroftheautoscaler.

//Moreinfo:https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status.

//+optional

SpecVerticalPodAutoscalerSpec

//Currentinformationabouttheautoscaler.

//+optional

StatusVerticalPodAutoscalerStatus

}

//VerticalPodAutoscalerSpecisthespecificationofthebehavioroftheautoscaler.

typeVerticalPodAutoscalerSpec{

//AlabelquerythatdeterminesthesetofpodscontrolledbytheAutoscaler.

//Moreinfo:https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors

Selector*metav1.LabelSelector

//Describestherulesonhowchangesareappliedtothepods.

//+optional

UpdatePolicyPodUpdatePolicy

//Controlshowtheautoscalercomputesrecommendedresources.

//+optional

ResourcePolicyPodResourcePolicy

}

//VerticalPodAutoscalerStatusdescribestheruntimestateoftheautoscaler.

typeVerticalPodAutoscalerStatus{

//Thetimewhenthestatuswaslastrefreshed.

LastUpdateTimemetav1.Time

//Themostrecentlycomputedamountofresourcesrecommendedbythe

//autoscalerforthecontrolledpods.

//+optional

RecommendationRecommendedPodResources

//Afree-formhumanreadablemessagedescribingthestatusoftheautoscaler.

StatusMessagestring

}

標簽選擇 (Label Selector)

Label Selector 依據給定的VPA策略決定哪些Pod需要伸縮。Recommender 會匯聚匹配給定 VPA 的所有信號，因此用戶設置標簽來將行為類似的 pod 分組到一個 VPA 下是非常重要的。

現在還沒有決定如何處理沖突，例如一個 pod 同時被多個 VPA 策略匹配。

更新策略(Update Policy)

更新策略控制了VPA如何應用更改。在 MVP 中,它只包含一個單個字段: mode

"updatePolicy"{

"mode":"",

}

mode 可以設置為三種：

Intitial: VPA 只在創建 Pod 時分配資源，在 Pod 的其他生命周期不改變Pod的資源。

Auto(默認)：VPA 在 Pod 創建時分配資源，并且能夠在 Pod 的其他生命周期更新它們，包括淘汰和重新調度 Pod。

Off：VPA 從不改變Pod資源。Recommender 而依舊會在VPA對象中生成推薦信息，他們可以被用在演習中。

以下任意一個操作都可以關掉 VPA ：

把更新策略改為 Off。

刪除 VPA 組件。

改變 Pod 的標簽讓它不在于 VPA Label Selector 匹配。

注意：關閉 VPA 會讓 Pod 不再進行進一步的改變，但它不會恢復到正在Pod的最初資源狀態，直到用戶手動對它進行更新。

//VerticalPodAutoscalerStatusdescribestheruntimestateoftheautoscaler.

typeVerticalPodAutoscalerStatus{

//Thetimewhenthestatuswaslastrefreshed.

LastUpdateTimemetav1.Time

//Themostrecentlycomputedamountofresourcesrecommendedbythe

//autoscalerforthecontrolledpods.

//+optional

RecommendationRecommendedPodResources

//Afree-formhumanreadablemessagedescribingthestatusoftheautoscaler.

StatusMessagestring

}

//UpdateModecontrolswhenautoscalerapplieschangestothepodresources.

typeUpdateModestring

const(

//UpdateModeOffmeansthatautoscalerneverchangesPodresources.

//Therecommenderstillsetstherecommendedresourcesinthe

//VerticalPodAutoscalerobject.Thiscanbeusedfora"dryrun".

UpdateModeOffUpdateMode="Off"

//UpdateModeInitialmeansthatautoscaleronlyassignsresourcesonpod

//creationanddoesnotchangethemduringthelifetimeofthepod.

UpdateModeInitialUpdateMode="Initial"

//UpdateModeAutomeansthatautoscalerassignsresourcesonpodcreation

//andadditionallycanupdatethemduringthelifetimeofthepod,

//includingevicting/reschedulingthepod.

UpdateModeAutoUpdateMode="Auto"

)

//PodUpdatePolicydescribestherulesonhowchangesareappliedtothepods.

typePodUpdatePolicystruct{

//Controlswhenautoscalerapplieschangestothepodresources.

//+optional

UpdateModeUpdateMode

}

資源策略(Resource Policy )

資源策略控制 VPA 如何計算推薦資源。在 MVP 中，它包含每個容器請求中可選的上限和下限。資源策略在后面可以被擴展為額外的開關可以讓用戶根據他們特定的場景調整推薦算法。

const(

//DefaultContainerResourcePolicycanbepassedas

//ContainerResourcePolicy.Nametospecifythedefaultpolicy.

DefaultContainerResourcePolicy="*"

)

//ContainerResourcePolicycontrolshowautoscalercomputestherecommended

//resourcesforaspecificcontainer.

typeContainerResourcePolicystruct{

//NameofthecontainerorDefaultContainerResourcePolicy,inwhich

//casethepolicyisusedbythecontainersthatdon'thavetheirown

//policyspecified.

Namestring

//Whetherautoscalerisenabledforthecontainer.Defaultsto"On".

//+optional

ModeContainerScalingMode

//Specifiestheminimalamountofresourcesthatwillberecommended

//forthecontainer.

//+optional

MinAllowedapi.ResourceRequirements

//Specifiesthemaximumamountofresourcesthatwillberecommended

//forthecontainer.

//+optional

MaxAllowedapi.ResourceRequirements

}

//PodResourcePolicycontrolshowautoscalercomputestherecommendedresources

//forcontainersbelongingtothepod.

typePodResourcePolicystruct{

//Per-containerresourcepolicies.

ContainerPolicies[]ContainerResourcePolicy

}

//ContainerScalingModecontrolswhetherautoscalerisenabledforaspeciifc

//container.

typeContainerScalingModestring

const(

//ContainerScalingModeOnmeansautoscalingisenabledforacontainer.

ContainerScalingModeOnContainerScalingMode="On"

//ContainerScalingModeOffmeansautoscalingisdisabledforacontainer.

ContainerScalingModeOffContainerScalingMode="Off"

)

推薦(Recommendation)

VPA 資源有一個僅輸出的字段用來保存一個由 Recommender 生成的最近的一次推薦。這個字段可以在 Recommender 暫時無法訪問時被用來獲取最近的一次推薦。這個推薦包含推薦目標資源數量以及范圍(最大,最小),可以被 Updater 用來決定在何時更新 Pod。在資源緊缺的情況下,Updater 可能決定將 Pod 資源壓縮到推薦的最小值。范圍的寬度同樣也影響了推薦的置信區間。

//RecommendedPodResourcesistherecommendationofresourcescomputedby

//autoscaler.

typeRecommendedPodResourcesstruct{

//Resourcesrecommendedbytheautoscalerforeachcontainer.

ContainerRecommendations[]RecommendedContainerResources

}

//RecommendedContainerResourcesistherecommendationofresourcescomputedby

//autoscalerforaspecificcontainer.Respectsthecontainerresourcepolicy

//ifpresentinthespec.

typeRecommendedContainerResourcesstruct{

//Nameofthecontainer.

Namestring

//Recommendedamountofresources.

Targetapi.ResourceRequirements

//Minimumrecommendedamountofresources.

//Runningtheapplicationwithlessresourcesislikelytohave

//significantimpactonperformance/availability.

//+optional

MinRecommendedapi.ResourceRequirements

//Maximumrecommendedamountofresources.

//Anyresourcesallocatedbeyondthisvaluearelikelywasted.

//+optional

MaxRecommendedapi.ResourceRequirements

}

準入控制器(Admission Controller)

VPA Admission Controller 攔截 Pod 創建請求。如果 Pod 與 VPA 配置匹配且模式未設置為off，則控制器通過將建議的資源應用于 Pod spec 來重寫資源請求。否則它會使 Pod spec保持不變。

控制器通過從 Recommender 中的 /recommendedPodResources 來獲取推薦的資源。如果呼叫超時或失敗，控制器將回退到 VPA object 中緩存的建議。如果這也不可用，則控制器允許資源請求傳遞最初指定的資源。

注意：將來可以通過將 Pod 標記為 requiring VPA 來(可選)強制使用 VPA 。這將禁止在創建相應的 VPA 配置之前調度 Pod 。如果找不到匹配的 VPA 配置，則準入控制器將拒絕此類 Pod 。對于想要創建 VPA 配置并提交 Pod 的用戶來說，此功能將非常方便。

VPA 準入控制器將作為外部入場鉤子(External Admission Hook)實施。但請注意，這取決于變異webhook 準入控制器(Mutating Webhook Admission Controllers)。

推薦器(Recommender)

Recommender 是 VPA 的主要組成部分。它負責計算推薦的資源。在啟動時，Recommender 獲取所有 Pod 的歷史資源利用率(無論它們是否使用 VPA )以及歷史存儲中的 Pod OOM 事件的歷史記錄。它聚合這些數據并將其保存在內存中。

在正常操作期間，Recommender 通過 Metrics API 從 Metrics Server 獲取資源利用率和新事件的實時更新。此外，它還可以監視群集中的所有 Pod 和所有 VPA object 。對于由某個VPA選擇器匹配的每個 Pod，Recommender 計算推薦的資源并在 VPA object 上設置推薦。

意識到每個 VPA object 有一個推薦是非常重要的。用戶應使用一個 VPA 來控制具有類似資源使用模式的 Pod ，通常是一組副本或單個工作負載的分片。

Recommender 充當了一個 extension-apiserver，暴露了一個同步方法，該方法獲取 Podspec 和 Pod 元數據并返回推薦的資源。

Recommender API

請求體：

```go

//RecommendationQueryobtainsresourcerecommendationforapod.

typeRecommendationQuerystruct{

metav1.TypeMeta

//+optional

metav1.ObjectMeta

//Specisfilledinbythecallertorequestarecommendation.

SpecRecommendationQuerySpec

//Statusisfilledinbytheserverwiththerecommendedpodresources.

//+optional

StatusRecommendationQueryStatus

}

//RecommendationQuerySpecisarequestofrecommendationforapod.

typeRecommendationQuerySpecstruct{

//Podforwhichtocomputetherecommendation.Doesnotneedtoexist.

Podcore.Pod

}

//RecommendationQueryStatusisaresponsetotherecommendationrequest.

typeRecommendationQueryStatus{

//Recommendationholdsrecommendedresourcesforthepod.

//+optional

Recommendationautoscaler.RecommendedPodResources

//Errorindicatesthattherecommendationwasnotavailable.Either

//RecommendationorErrormustbepresent.

//+optional

Errorstring

}

注意，現有 Pod 以及尚未創建的 Pod 都可以調用此 API。

更新器(Updater)

VPA Updater 是一個負責將推薦資源應用于現有 Pod 的組件。它監視集群中的所有 VPA object 和 Pod ，通過調用 Recommender API 定期獲取由 VPA 控制的 Pod 的建議。當推薦的資源與實際配置的資源明顯不同時，Updater 可能會決定更新 Pod。在 MVP 中(直到 Pod 資源的原地升級可用)，這意味著需要驅逐現有的 Pod 然后使用推薦的資源重新創建它們。

Updater 依賴于其他機制(例如副本集)來重新創建已刪除的 Pod 。但是，它不驗證是否實際為 Pod 配置了此類機制。這樣的檢查可以在 CLI 中實現，并在 VPA 匹配 Pod 時警告用戶，但 Pod 不會自動重啟。

雖然終止Pod是破壞性的并且通常是不期望的，但有時也是合理的：

避免 CPU 饑餓.

隨機降低跨多個 Pod 的相關 OOM 的風險.

在長時間內節省資源.

Updater 僅在 updatePolicy.mod 設置為 Auto 時才會配置 Pod 。

根據群集的當前狀態(例如，配額，節點上可用的空間或其他調度約束)，Updater 還需要了解如何在將推薦應用于Pod之前調整推薦。否則它可能會永久性地取消一個 Pod 。這種機制尚未設計。

推薦計算模型(Recommendation model)

VPA控制容器的資源請求(內存和 CPU)。在 MVP 中，它總是將資源限制設置為無窮大。目前尚不清楚是否存在 VPA 設定資源限制的用例。

資源請求是基于對容器的當前和先前運行以及具有類似屬性的其他容器(名稱，圖像，命令，args)的分析來計算的。推薦的模型(MVP)假設內存和CPU消耗是獨立的隨機變量，其分布等于在過去 N 天中觀察到的分布(推薦 N 值取為 N =8 以捕獲每周峰值)。未來更先進的模型可能會嘗試檢測趨勢，周期性和其他與時間相關的模式。

對于CPU， 目標是保證容器使用的CPU超過容器請求的 CPU 資源的高百分比(如95%)時間低于某個特定的閾值(如保證只有1%的時間內容器的CPU使用高于請求的 CPU 資源的95%)在此模型中，“CPU 使用”定義為在短時間間隔內測量的平均值。測量間隔越短，對尖峰，延遲敏感的工作負載的建議質量越好。最低合理間隔為 1/min，建議為 1/sec。

對于內存，目標是保證在特定時間窗口內容器使用的內存超過容器請求的內存資源的概率低于某個閾值(例如，在 24 小時內低于 1%)。窗口必須很長( ≥24h )，以確保 OOM 引起的驅逐不會明顯影響服務應用程序的可用性和批量計算的進度(更高級的模型可以允許用戶指定 SLO 來控制它)。

內存溢出處理(Handling OOMs)

當容器由于超出可用內存而被逐出時，其實際內存要求是未知的(消耗的量顯然給出了下限)。這是通過將 OOM 事件轉換為人工內存使用樣本來建模的，方法是將“安全邊際”乘數 (“safety margin” multiplier ) 應用于最后一次觀察到的使用情況。

歷史存儲(History Storage )

VPA 為歷史事件和資源利用的提供者定義數據訪問 API 。一開始，至少在資源利用部分，我們將使用 Prometheus 作為此 API 的參考實現，歷史事件可以由另一個解決方案支持，例如，Infrastore。用戶將能夠插入自己的實現。

History Storage 被不斷填充實時更新的資源利用率和事件，類似于 Recommender。它至少保留8天的數據。此數據僅用于在啟動時初始化 Recommender 。

開放問題

如果多個 VPA 對象與一個 Pod 匹配，如何解決沖突。

如何在將推薦應用于特定容器之前根據集群的當前狀態調整推薦(例如，配額，節點上可用的空間或其他調度約束)。

未來的工作

Pod啟動時融入 VPA

在當前提案中，如果在 Pod 接納時間 (Admission Time) 內 Pod 沒有匹配的 VPA 配置，則將使用最初配置的資源調度 Pod。這可能并不是用戶希望的行為。特別地，用戶可能想要創建 VPA 配置同時提交到 Pod，這會導致競爭條件：結果取決于首先處理哪個資源(VPA 或 Pod)。

為了解決這個問題，我們建議允許使用特殊注釋(requires VPA)標記 Pod，如果相應的 VPA 不可用，則阻止接納控制器 (Admission Controlle) 接納Pod。

另一種方法是引入用于相同目的的VPA初始化器。

結合垂直和水平縮放

原則上，只要兩個機制在不同的資源上運行，就可以對單個工作負載(Pod 組)使用垂直和水平縮放。正確的方法是讓 HPA 基于瓶頸資源擴展組。VPA 可以控制其他資源。例子：

CPU綁定的工作負載可以根據 CPU 利用率水平伸縮，同時使用垂直伸縮來調整內存。

IO綁定工作負載可以基于 IO 吞吐量水平伸縮，同時使用垂直伸縮來調整內存和 CPU。

然而，這是一種更高級的自動縮放形式，并且 MVP 版本的 Vertical Pod Autoscaler 不能很好地支持它。實現的難度在于改變實例數不僅會影響瓶頸資源的利用率(這是水平擴展的原則)，而且可能也會影響由 VPA 控制的非瓶頸資源。在匯總歷史資源利用率和生成建議時，必須擴展 VPA 模型從而能夠將組的大小考慮在內，以便將其與HPA相結合。

批量工作負載

批處理工作負載具有與延遲敏感工作負載有不同的 CPU 要求。他們關心吞吐量而不是請求延遲，這意味著 VPA 應該將 CPU 需求基于平均 CPU 消耗而不是高百分位的 CPU 分布。

TODO：描述批處理工作負載的推薦模型以及VPA如何區分批處理和服務。一種可能的方法是查看 PodSpec.restartPolicy。另一種方法是讓用戶在 PodResourcePolicy 中指定工作負載的延遲要求。