建站
咨詢
售后
建站咨詢
新聞中心
Kubernetes 垂直自動伸縮走向何方?
作者：Kgrygiel 2019-12-05 09:34:29
云計算 目前 Kubernetes 的 Pod 水平自動伸縮(HPA，Horizontal Pod Autoscaler)已在業(yè)界廣泛應用。
創(chuàng)新互聯(lián)公司專注于企業(yè)成都全網(wǎng)營銷推廣、網(wǎng)站重做改版、吳起網(wǎng)站定制設計、自適應品牌網(wǎng)站建設、成都h5網(wǎng)站建設、購物商城網(wǎng)站建設、集團公司官網(wǎng)建設、外貿(mào)營銷網(wǎng)站建設、高端網(wǎng)站制作、響應式網(wǎng)頁設計等建站業(yè)務，價格優(yōu)惠性價比高，為吳起等各大城市提供網(wǎng)站開發(fā)制作服務。
目前 Kubernetes 的 Pod 水平自動伸縮(HPA，Horizontal Pod Autoscaler)已在業(yè)界廣泛應用。但對一些特殊的 Pod(如一些有狀態(tài)的 Pod)，HPA 并不能很好地解決資源不足的問題。這就引出 Pod 垂直自動伸縮(VPA，Vertical Pod Autoscaler)，本文主要介紹 Kubernetes 社區(qū)對 Pod 垂直自動伸縮組件的開發(fā)規(guī)劃。
VPA定義
垂直自動伸縮(VPA，Vertical Pod Autoscaler) 是一個基于歷史數(shù)據(jù)、集群可使用資源數(shù)量和實時的事件(如 OMM， 即 out of memory)來自動設置Pod所需資源并且能夠在運行時自動調(diào)整資源基礎服務。
介紹
背景
- 計算資源
- 資源服務質量
- 準入控制器
- 外部準入webhooks
目標
VPA有兩個目標：
- 通過自動配置資源請求來減少運維成本。
- 在提高集群資源利用率的同時最小化容器出現(xiàn)內(nèi)存溢出或 CPU 饑餓的風險。
相關特性
水平自動伸縮(Horizontal Pod Autoscaler，HPA)
HPA 是基于實時的CPU利用率或者其他的一些特定信號動態(tài)調(diào)整 Replication controller 中 Pod 數(shù)量的基礎服務。
通常用戶在無狀態(tài)的工作負載時選用 HPA，在有狀態(tài)的工作負載時選用 VPA。也有一些場景下會混合使用。
集群自動伸縮(Cluster Autoscaler)
集群自動伸縮基于集群整體的資源利用率動態(tài)調(diào)整 Kubernetes 集群的大小。
集群自動伸縮、HPA 和 VPA 提供了一個完整的自動伸縮解決方案。
初始資源(Initial resources)
初始資源基于歷史資源利用率提供初始資源請求，它僅僅在Pod創(chuàng)建時觸發(fā)，VPA打算繼承使用這個特性。
原地升級(In-place updates)
原地升級是一個計劃中的功能,在節(jié)點上有足夠資源的情況下，原地升級無需殺死容器就能夠調(diào)整已存在容器的資源的請求和限制。
VPA將從這種能力中受益匪淺，但它不被視為最小可行產(chǎn)品 ( inimum Viable Product, MVP) 的阻擋者。
資源估計(Resource estimation)
資源估計是另外一個計劃中的功能，它可以通過暫時回收運行中容器的暫未使用的資源來提高資源利用率。
資源估計與 VPA 的不同在于它基于的時間表比較短(僅基于本地的短期的歷史數(shù)據(jù))，回收以后再提供的質量低，不提供初始資源預測。VPA 和資源估計是互補的。
需求
功能
- VPA 能夠在 Pod 提交時設置容器的資源(CPU和內(nèi)存的請求和限制)。
- VPA能夠調(diào)整已存在的 Pod 的容器資源，特別是能夠對 CPU 饑餓和內(nèi)存溢出等事件作出響應。
- 當 VPA 重啟 Pod 時，它必須考慮中斷服務的成本。
- 用戶能夠配置 VPA 的在資源上的固定限制,特別是最小和最大資源請求。
- VPA 要與 Pod 控制器兼容，最起碼要與
- Deployment
兼容。特別地：
- 資源更新的時候不能干擾 spec 更新或和 spec 更新沖突。
- 在已有的部署中，能夠滾動更新 VPA 的策略。
- 在創(chuàng)建 Pod 時能夠盡快開始遵循 VPA 策略,特別是對于一些只有VPA策略應用以后才能被調(diào)度的 Pod 。
可用性
重量級的組件(數(shù)據(jù)庫或推薦器)出故障不會阻塞重新創(chuàng)建已存在的 Pod 。Pod 創(chuàng)建路徑非常關鍵的組件必須設計成高可用。
可擴展性
在原地升級組件開發(fā)好后, VPA 能夠使用它。
設計
綜述
- 提出新的API資源: VerticalPodAutoscaler 。它包括一個標簽識別器 label selector(匹配Pod)、資源策略 resources policy(控制VPA如何計算資源)、更新策略 update policy(控制資源變化應用到Pod)和推薦資源信息。
- VPA Recommender 是一個新的組件，它考慮集群中來自 Metrics Server 的所有 Pod 的資源利用率信號和內(nèi)存溢出事件。
- VPA Recommender 會監(jiān)控所有 Pod，為每個 Pod 持續(xù)計算新的推薦資源，并將它們存儲到 VPA Object 中。
- VPA Recommender 會暴露一個同步 API 獲取 Pod 詳細信息并返回推薦信息。
- 所有的 Pod 創(chuàng)建請求都會通過 VPA Admission Controller。如果 Pod 與任何一個 VPA 對象匹配，那么 Admission controller 會依據(jù) VPA Recommender 推薦的值重寫容器的資源。如果 Recommender 連接不上，它將會返回 VPA Object 中緩存的推薦信息。
- VPA Updater 是負責實時更新 Pod 的組件。如果一個 Pod 使用 VPA 的自動模式，那么Updater 會依據(jù)推薦資源來決定如何更新。在 MVP 模式中，這需要通過刪除 Pod 然后依據(jù)新的資源重建 Pod 來實現(xiàn)，這種方法需要 Pod 屬于一個 Replica Set(或者其他能夠重新創(chuàng)建它的組件)。在未來，Updater 會利用原地升級，因為重新創(chuàng)建或者重新分配Pod對服務是很有破壞性的，必須盡量減少這種操作。
- VPA 僅僅控制容器的資源請求,它把資源限制設置為無限,資源請求的計算基于對當前和過去運行狀況的分析。
- History Storage 是從 API Server 中獲取資源利用率信號和內(nèi)存溢出并將它們永久保存的組件。Recommender 在一開始用這些歷史數(shù)據(jù)來初始化狀態(tài)。History Storage 基礎的實現(xiàn)是使用 Prometheus。
體系架構
VPA Architecture Diagram
API
我們提出了一個新的類型的API對象 VertialPodAutoscaler，它包含了擴容的目標，也就是用于匹配 Pod 的 label seletctor 和兩個策略模塊：更新策略 update policy 和資源策略resources policy。此外他還持有 VPA 計算的最新的推薦信息。
VPA API 對象綜述
- // VerticalPodAutoscaler is the configuration for a vertical pod
- // autoscaler, which automatically manages pod resources based on historical and
- // real time resource utilization.
- type VerticalPodAutoscaler struct {
- metav1.TypeMeta
- // Standard object metadata.
- // More info: https://git.k8s.io/community/contributors/devel/api-conventions.md#metadata
- // +optional
- metav1.ObjectMeta
- // Specification of the behavior of the autoscaler.
- // More info: https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status.
- // +optional
- Spec VerticalPodAutoscalerSpec
- // Current information about the autoscaler.
- // +optional
- Status VerticalPodAutoscalerStatus
- }
- // VerticalPodAutoscalerSpec is the specification of the behavior of the autoscaler.
- type VerticalPodAutoscalerSpec {
- // A label query that determines the set of pods controlled by the Autoscaler.
- // More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors
- Selector *metav1.LabelSelector
- // Describes the rules on how changes are applied to the pods.
- // +optional
- UpdatePolicy PodUpdatePolicy
- // Controls how the autoscaler computes recommended resources.
- // +optional
- ResourcePolicy PodResourcePolicy
- }
- // VerticalPodAutoscalerStatus describes the runtime state of the autoscaler.
- type VerticalPodAutoscalerStatus {
- // The time when the status was last refreshed.
- LastUpdateTime metav1.Time
- // The most recently computed amount of resources recommended by the
- // autoscaler for the controlled pods.
- // +optional
- Recommendation RecommendedPodResources
- // A free-form human readable message describing the status of the autoscaler.
- StatusMessage string
- }
標簽選擇 (Label Selector)
Label Selector 依據(jù)給定的VPA策略決定哪些Pod需要伸縮。Recommender 會匯聚匹配給定 VPA 的所有信號，因此用戶設置標簽來將行為類似的 pod 分組到一個 VPA 下是非常重要的。
現(xiàn)在還沒有決定如何處理沖突，例如一個 pod 同時被多個 VPA 策略匹配。
更新策略(Update Policy)
更新策略控制了VPA如何應用更改。在 MVP 中,它只包含一個單個字段: mode
- "updatePolicy" {
- "mode": "",
- }
mode 可以設置為三種：
- Intitial: VPA 只在創(chuàng)建 Pod 時分配資源，在 Pod 的其他生命周期不改變Pod的資源。
- Auto(默認)：VPA 在 Pod 創(chuàng)建時分配資源，并且能夠在 Pod 的其他生命周期更新它們，包括淘汰和重新調(diào)度 Pod。
- Off：VPA 從不改變Pod資源。Recommender 而依舊會在VPA對象中生成推薦信息，他們可以被用在演習中。
以下任意一個操作都可以關掉 VPA ：
- 把更新策略改為 Off。
- 刪除 VPA 組件。
- 改變 Pod 的標簽讓它不在于 VPA Label Selector 匹配。
注意：關閉 VPA 會讓 Pod 不再進行進一步的改變，但它不會恢復到正在Pod的最初資源狀態(tài)，直到用戶手動對它進行更新。
- // VerticalPodAutoscalerStatus describes the runtime state of the autoscaler.
- type VerticalPodAutoscalerStatus {
- // The time when the status was last refreshed.
- LastUpdateTime metav1.Time
- // The most recently computed amount of resources recommended by the
- // autoscaler for the controlled pods.
- // +optional
- Recommendation RecommendedPodResources
- // A free-form human readable message describing the status of the autoscaler.
- StatusMessage string
- }
- // UpdateMode controls when autoscaler applies changes to the pod resources.
- type UpdateMode string
- const (
- // UpdateModeOff means that autoscaler never changes Pod resources.
- // The recommender still sets the recommended resources in the
- // VerticalPodAutoscaler object. This can be used for a "dry run".
- UpdateModeOff UpdateMode = "Off"
- // UpdateModeInitial means that autoscaler only assigns resources on pod
- // creation and does not change them during the lifetime of the pod.
- UpdateModeInitial UpdateMode = "Initial"
- // UpdateModeAuto means that autoscaler assigns resources on pod creation
- // and additionally can update them during the lifetime of the pod,
- // including evicting / rescheduling the pod.
- UpdateModeAuto UpdateMode = "Auto"
- )
- // PodUpdatePolicy describes the rules on how changes are applied to the pods.
- type PodUpdatePolicy struct {
- // Controls when autoscaler applies changes to the pod resources.
- // +optional
- UpdateMode UpdateMode
- }
資源策略(Resource Policy )
資源策略控制 VPA 如何計算推薦資源。在 MVP 中，它包含每個容器請求中可選的上限和下限。資源策略在后面可以被擴展為額外的開關可以讓用戶根據(jù)他們特定的場景調(diào)整推薦算法。
- const (
- // DefaultContainerResourcePolicy can be passed as
- // ContainerResourcePolicy.Name to specify the default policy.
- DefaultContainerResourcePolicy = "*"
- )
- // ContainerResourcePolicy controls how autoscaler computes the recommended
- // resources for a specific container.
- type ContainerResourcePolicy struct {
- // Name of the container or DefaultContainerResourcePolicy, in which
- // case the policy is used by the containers that don't have their own
- // policy specified.
- Name string
- // Whether autoscaler is enabled for the container. Defaults to "On".
- // +optional
- Mode ContainerScalingMode
- // Specifies the minimal amount of resources that will be recommended
- // for the container.
- // +optional
- MinAllowed api.ResourceRequirements
- // Specifies the maximum amount of resources that will be recommended
- // for the container.
- // +optional
- MaxAllowed api.ResourceRequirements
- }
- // PodResourcePolicy controls how autoscaler computes the recommended resources
- // for containers belonging to the pod.
- type PodResourcePolicy struct {
- // Per-container resource policies.
- ContainerPolicies []ContainerResourcePolicy
- }
- // ContainerScalingMode controls whether autoscaler is enabled for a speciifc
- // container.
- type ContainerScalingMode string
- const (
- // ContainerScalingModeOn means autoscaling is enabled for a container.
- ContainerScalingModeOn ContainerScalingMode = "On"
- // ContainerScalingModeOff means autoscaling is disabled for a container.
- ContainerScalingModeOff ContainerScalingMode = "Off"
- )
推薦(Recommendation)
VPA 資源有一個僅輸出的字段用來保存一個由 Recommender 生成的最近的一次推薦。這個字段可以在 Recommender 暫時無法訪問時被用來獲取最近的一次推薦。這個推薦包含推薦目標資源數(shù)量以及范圍(最大,最小),可以被 Updater 用來決定在何時更新 Pod。在資源緊缺的情況下,Updater 可能決定將 Pod 資源壓縮到推薦的最小值。范圍的寬度同樣也影響了推薦的置信區(qū)間。
- // RecommendedPodResources is the recommendation of resources computed by
- // autoscaler.
- type RecommendedPodResources struct {
- // Resources recommended by the autoscaler for each container.
- ContainerRecommendations []RecommendedContainerResources
- }
- // RecommendedContainerResources is the recommendation of resources computed by
- // autoscaler for a specific container. Respects the container resource policy
- // if present in the spec.
- type RecommendedContainerResources struct {
- // Name of the container.
- Name string
- // Recommended amount of resources.
- Target api.ResourceRequirements
- // Minimum recommended amount of resources.
- // Running the application with less resources is likely to have
- // significant impact on performance/availability.
- // +optional
- MinRecommended api.ResourceRequirements
- // Maximum recommended amount of resources.
- // Any resources allocated beyond this value are likely wasted.
- // +optional
- MaxRecommended api.ResourceRequirements
- }
準入控制器(Admission Controller)
VPA Admission Controller 攔截 Pod 創(chuàng)建請求。如果 Pod 與 VPA 配置匹配且模式未設置為off，則控制器通過將建議的資源應用于 Pod spec 來重寫資源請求。否則它會使 Pod spec保持不變。
控制器通過從 Recommender 中的 /recommendedPodResources 來獲取推薦的資源。如果呼叫超時或失敗，控制器將回退到 VPA object 中緩存的建議。如果這也不可用，則控制器允許資源請求傳遞最初指定的資源。
注意：將來可以通過將 Pod 標記為 requiring VPA 來(可選)強制使用 VPA 。這將禁止在創(chuàng)建相應的 VPA 配置之前調(diào)度 Pod 。如果找不到匹配的 VPA 配置，則準入控制器將拒絕此類 Pod 。對于想要創(chuàng)建 VPA 配置并提交 Pod 的用戶來說，此功能將非常方便。
VPA 準入控制器將作為外部入場鉤子(External Admission Hook)實施。但請注意，這取決于變異webhook 準入控制器(Mutating Webhook Admission Controllers)。
推薦器(Recommender)
Recommender 是 VPA 的主要組成部分。它負責計算推薦的資源。在啟動時，Recommender 獲取所有 Pod 的歷史資源利用率(無論它們是否使用 VPA )以及歷史存儲中的 Pod OOM 事件的歷史記錄。它聚合這些數(shù)據(jù)并將其保存在內(nèi)存中。
在正常操作期間，Recommender 通過 Metrics API 從 Metrics Server 獲取資源利用率和新事件的實時更新。此外，它還可以監(jiān)視群集中的所有 Pod 和所有 VPA object 。對于由某個VPA選擇器匹配的每個 Pod，Recommender 計算推薦的資源并在 VPA object 上設置推薦。
意識到每個 VPA object 有一個推薦是非常重要的。用戶應使用一個 VPA 來控制具有類似資源使用模式的 Pod ，通常是一組副本或單個工作負載的分片。
Recommender 充當了一個 extension-apiserver，暴露了一個同步方法，該方法獲取 Podspec 和 Pod 元數(shù)據(jù)并返回推薦的資源。
Recommender API
- 請求體：
- ```go
- // RecommendationQuery obtains resource recommendation for a pod.
- type RecommendationQuery struct {
- metav1.TypeMeta
- // +optional
- metav1.ObjectMeta
- // Spec is filled in by the caller to request a recommendation.
- Spec RecommendationQuerySpec
- // Status is filled in by the server with the recommended pod resources.
- // +optional
- Status RecommendationQueryStatus
- }
- // RecommendationQuerySpec is a request of recommendation for a pod.
- type RecommendationQuerySpec struct {
- // Pod for which to compute the recommendation. Does not need to exist.
- Pod core.Pod
- }
- // RecommendationQueryStatus is a response to the recommendation request.
- type RecommendationQueryStatus {
- // Recommendation holds recommended resources for the pod.
- // +optional
- Recommendation autoscaler.RecommendedPodResources
- // Error indicates that the recommendation was not available. Either
- // Recommendation or Error must be present.
- // +optional
- Error string
- }
注意，現(xiàn)有 Pod 以及尚未創(chuàng)建的 Pod 都可以調(diào)用此 API。
更新器(Updater)
VPA Updater 是一個負責將推薦資源應用于現(xiàn)有 Pod 的組件。它監(jiān)視集群中的所有 VPA object 和 Pod ，通過調(diào)用 Recommender API 定期獲取由 VPA 控制的 Pod 的建議。當推薦的資源與實際配置的資源明顯不同時，Updater 可能會決定更新 Pod。在 MVP 中(直到 Pod 資源的原地升級可用)，這意味著需要驅逐現(xiàn)有的 Pod 然后使用推薦的資源重新創(chuàng)建它們。
Updater 依賴于其他機制(例如副本集)來重新創(chuàng)建已刪除的 Pod 。但是，它不驗證是否實際為 Pod 配置了此類機制。這樣的檢查可以在 CLI 中實現(xiàn)，并在 VPA 匹配 Pod 時警告用戶，但 Pod 不會自動重啟。
雖然終止Pod是破壞性的并且通常是不期望的，但有時也是合理的：
- 避免 CPU 饑餓.
- 隨機降低跨多個 Pod 的相關 OOM 的風險.
- 在長時間內(nèi)節(jié)省資源.
Updater 僅在 updatePolicy.mod 設置為 Auto 時才會配置 Pod 。
根據(jù)群集的當前狀態(tài)(例如，配額，節(jié)點上可用的空間或其他調(diào)度約束)，Updater 還需要了解如何在將推薦應用于Pod之前調(diào)整推薦。否則它可能會永久性地取消一個 Pod 。這種機制尚未設計。
推薦計算模型(Recommendation model)
VPA控制容器的資源請求(內(nèi)存和 CPU)。在 MVP 中，它總是將資源限制設置為無窮大。目前尚不清楚是否存在 VPA 設定資源限制的用例。
資源請求是基于對容器的當前和先前運行以及具有類似屬性的其他容器(名稱，圖像，命令，args)的分析來計算的。推薦的模型(MVP)假設內(nèi)存和CPU消耗是獨立的隨機變量，其分布等于在過去 N 天中觀察到的分布(推薦 N 值取為 N =8 以捕獲每周峰值)。未來更先進的模型可能會嘗試檢測趨勢，周期性和其他與時間相關的模式。
對于CPU， 目標是保證容器使用的CPU超過容器請求的 CPU 資源的高百分比(如95%)時間低于某個特定的閾值(如保證只有1%的時間內(nèi)容器的CPU使用高于請求的 CPU 資源的95%)在此模型中，“CPU 使用”定義為在短時間間隔內(nèi)測量的平均值。測量間隔越短，對尖峰，延遲敏感的工作負載的建議質量越好。最低合理間隔為 1/min，建議為 1/sec。
對于內(nèi)存，目標是保證在特定時間窗口內(nèi)容器使用的內(nèi)存超過容器請求的內(nèi)存資源的概率低于某個閾值(例如，在 24 小時內(nèi)低于 1%)。窗口必須很長( ≥24h )，以確保 OOM 引起的驅逐不會明顯影響服務應用程序的可用性和批量計算的進度(更高級的模型可以允許用戶指定 SLO 來控制它)。
內(nèi)存溢出處理(Handling OOMs)
當容器由于超出可用內(nèi)存而被逐出時，其實際內(nèi)存要求是未知的(消耗的量顯然給出了下限)。這是通過將 OOM 事件轉換為人工內(nèi)存使用樣本來建模的，方法是將“安全邊際”乘數(shù) (“safety margin” multiplier ) 應用于最后一次觀察到的使用情況。
歷史存儲(History Storage )
VPA 為歷史事件和資源利用的提供者定義數(shù)據(jù)訪問 API 。一開始，至少在資源利用部分，我們將使用 Prometheus 作為此 API 的參考實現(xiàn)，歷史事件可以由另一個解決方案支持，例如，Infrastore。用戶將能夠插入自己的實現(xiàn)。
History Storage 被不斷填充實時更新的資源利用率和事件，類似于 Recommender。它至少保留8天的數(shù)據(jù)。此數(shù)據(jù)僅用于在啟動時初始化 Recommender 。
開放問題
如果多個 VPA 對象與一個 Pod 匹配，如何解決沖突。
如何在將推薦應用于特定容器之前根據(jù)集群的當前狀態(tài)調(diào)整推薦(例如，配額，節(jié)點上可用的空間或其他調(diào)度約束)。
未來的工作
Pod啟動時融入 VPA
在當前提案中，如果在 Pod 接納時間 (Admission Time) 內(nèi) Pod 沒有匹配的 VPA 配置，則將使用最初配置的資源調(diào)度 Pod。這可能并不是用戶希望的行為。特別地，用戶可能想要創(chuàng)建 VPA 配置同時提交到 Pod，這會導致競爭條件：結果取決于首先處理哪個資源(VPA 或 Pod)。
為了解決這個問題，我們建議允許使用特殊注釋(requires VPA)標記 Pod，如果相應的 VPA 不可用，則阻止接納控制器 (Admission Controlle) 接納Pod。
另一種方法是引入用于相同目的的VPA初始化器。
結合垂直和水平縮放
原則上，只要兩個機制在不同的資源上運行，就可以對單個工作負載(Pod 組)使用垂直和水平縮放。正確的方法是讓 HPA 基于瓶頸資源擴展組。VPA 可以控制其他資源。例子：
- CPU綁定的工作負載可以根據(jù) CPU 利用率水平伸縮，同時使用垂直伸縮來調(diào)整內(nèi)存。
- IO綁定工作負載可以基于 IO 吞吐量水平伸縮，同時使用垂直伸縮來調(diào)整內(nèi)存和 CPU。
然而，這是一種更高級的自動縮放形式，并且 MVP 版本的 Vertical Pod Autoscaler 不能很好地支持它。實現(xiàn)的難度在于改變實例數(shù)不僅會影響瓶頸資源的利用率(這是水平擴展的原則)，而且可能也會影響由 VPA 控制的非瓶頸資源。在匯總歷史資源利用率和生成建議時，必須擴展 VPA 模型從而能夠將組的大小考慮在內(nèi)，以便將其與HPA相結合。
批量工作負載
批處理工作負載具有與延遲敏感工作負載有不同的 CPU 要求。他們關心吞吐量而不是請求延遲，這意味著 VPA 應該將 CPU 需求基于平均 CPU 消耗而不是高百分位的 CPU 分布。
TODO：描述批處理工作負載的推薦模型以及VPA如何區(qū)分批處理和服務。一種可能的方法是查看 PodSpec.restartPolicy。另一種方法是讓用戶在 PodResourcePolicy 中指定工作負載的延遲要求。
網(wǎng)頁標題：Kubernetes垂直自動伸縮走向何方?
鏈接地址：http://m.fisionsoft.com.cn/article/djsgiep.html
