Kubernetes有哪些新特性

這篇文章給大家分享的是有關Kubernetes有哪些新特性的內容。小編覺得挺實用的，因此分享給大家做個參考，一起跟隨小編過來看看吧。

新特性背景

不同的應用程序業務價值不同，其對擴縮容的要求也不同，比如以下三種類型應用：

1. 關鍵流量處理應用：該類應用希望在流量到來時快速的擴容，在流量高峰過去后，希望慢慢的縮容，以避免流量反彈；

2. 關鍵數據處理應用： 該類應用希望當大量數據到達時希望快速擴容，在數據減少時，希望快速的縮容，以節省成本；

3. 常規流量/數據處理應用：該類應用不那么重要，可以緩慢的擴容和縮容，以避免快速擴縮容帶來抖動；

然而當前版本的實現（1.15 & 1.16）并不能很好的滿足這類應用的期望。

當前版本的 kube-controller-manager 參數 --horizontal-pod-autoscaler-downscale-stabilization 可以在一定程度上控制縮容的速度。在每個調度周期（默認為30s）都會計算出一個縮放的推薦值并記錄下來，在每次計算縮放值時都會查看歷史的推薦值，從最近的一段歷史推薦值中挑選最大的，downscale-stabilization 就是用來指定這個時間窗口，默認為5min。

另外在 HPA controller 層面，有兩個硬編碼的常量控制擴容的速度：

• scaleUpLimitFactor = 2.0 // 擴容倍數

• scaleUpLimitMinimum = 4.0 // 擴容個數

在計算擴容的目標值時算法如下：

Max(scaleUpLimitFactor*當前副本數, scaleUpLimitMinimum))

也就是說，擴容要么擴成原來的2倍，要么擴大4個 pod，二者取大者。 一方面這個擴容速度并不能滿足上面提到的應用訴求，另一方面，這個硬編碼也確實不夠友好，盡管它設計本意是希望穩定的擴容以避免抖動。 注：這里提到的算法是HPA controller層面的，跟據每個HPA的當前值和目標值計算出擴容比例后再套用該算法，以限制擴容速度。

縮上所述，當前版本的實現并不能滿足一些應用對擴縮容的訴求，我們需要做一些改進。 本文的目標就是分析社區對此需求的討論結果，算是提前剖析新特性，但最終實現有可能跟此不一致。

新特性目標

結合前述的背景，不難得出，本次改進目標有兩點：

1. 允話用戶更精確的控制擴縮容速度；

2. 允話用戶在 HPA 層面控制擴縮容速度（每個HPA可以有個性化的控制）；

新特性設計

既然要對每個 HPA 單獨控制，那就需要在 HPA 資源API中增加相應的參數，所以將會引入下面4個參數：

periodSeconds（擴縮容的周期）

我們知道在kube-controller-manager有個參數（--horizontal-pod-autoscaler-sync-period）控制的是 HPA controller 處理周期，每個周期中處理所有的 HPA（為HPA生成擴縮容建議，并執行擴縮容）。

本次計劃引入的這個周期（periodSeconds）控制每個HPA兩次擴縮容操作的間隔，也可以叫冷卻時間。

percent （擴縮容百分比）

顧名思義，這個是控制擴縮容的百分比，可以簡單的理解成把硬編碼的 scaleUpLimitFactor = 2.0 改成可配置項。

例如，ScaleUpPercent = 150，那么每次擴容比例為150%（10-->25）。

pods （擴縮容個數）

這個是控制每個擴縮容的絕對個數，可以簡單的理解成把硬編碼的 scaleUpLimitMinimum = 4.0 改成可配置項。

例如：ScaleUpPods = 5，那么每次擴容的數量將是5個（10-->15）。

delay

這個參數與kube-controller-manager的horizontal-pod-autoscaler-downscale-stabilization含義一樣， 就是在計算擴縮容時，我們需要回頭看多久的建議值（從中選最大），可以簡單理解成把kube-controller-manager的參數下沉到 HPA 層面

需要注意的是，這幾個參數既可以控制擴容，也可以控制縮容，下面我們給出幾個示例來說明用法。

新特性示例

Story 1： 我希望應用能盡快的擴容

當希望應用能盡快的擴容時，可以使用大一點的percent。比如：

• scaleUp

• percent = 900 (每次擴容900%，即10倍速擴容)

假如pod最開始數量為1，那么擴容路徑如下：

1 -> 10 -> 100 -> 1000

當然，HPA既有的maxReplicas仍然有效，最大pod數不能超過此設置。

Story 2: 我希望應用能盡快的擴容、逐步的縮容

當希望應用能盡快的擴容，同時縮容的慢一些時，可以使用如下配置：

• scaleUp

• percent = 900

• scaleDown

• pods = 1 (每次縮容減少一個pod)

• periodSeconds = 600 (每10分鐘縮容一次)

假如pod最開始數量為1，那么擴容路徑如下：

1 -> 10 -> 100 -> 1000

同時，縮容路徑如下(每10分鐘縮容一次，每次減少一個pod)：

1000 -> 1000 -> 1000 -> … (7 more min) -> 999

Story 3: 我希望能緩慢擴容、正常的縮容

希望緩慢的擴容、正常的縮容，可以使用如下配置：

• scaleUp

• pods = 1

假如pod最開始數量為1，那么擴容路徑如下：

1 -> 2 -> 3 -> 4

Story 4: 我希望正常的擴容、不要自動縮容

如果希望能正常的擴容，但是不要自動縮容，可以使用如下配置：

• scaleDown:

• percent= 0

• pods = 0

把縮容的百分比和pod都置為0，那么就永遠不會縮容。

Story 5: 我希望更謹慎的縮容

如果希望縮容時再謹慎些，可以使用delaySeconds(這個跟kube-controller-manager的horizontal-pod-autoscaler-downscale-stabilization非常類似），配置如下：

• scaleDown：

• pods = 5

• delaySeconds = 600

那么，每次縮容最多減少5個pod，同時每次縮容，至少看到之前600s的推薦值，從中選擇最大的值。 這樣，縮容時就會變得非常謹慎。

API 變化

API的變化，主要是在HorizontalPodAutoscalerSpec中增加一個Constraints字段。

type HPAScaleConstraintValue struct {
    Rate         *HPAScaleConstraintRateValue
    DelaySeconds *int32

type HPAScaleConstraintRateValue struct {
    Pods          *int32
    Percent       *int32
    PeriodSeconds *int32
}

type HPAScaleConstraints struct {
    ScaleUp   *HPAScaleConstraintValue
    ScaleDown *HPAScaleConstraintValue
}

type HorizontalPodAutoscalerSpec struct {
    ScaleTargetRef CrossVersionObjectReference
    MinReplicas    *int32
    MaxReplicas    int32
    Metrics        []MetricSpec
    Constraints    *HPAScaleConstraints
}

感謝各位的閱讀！關于“Kubernetes有哪些新特性”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，讓大家可以學到更多知識，如果覺得文章不錯，可以把它分享出去讓更多的人看到吧！