Kubernetes滾動更新速率控制解讀

 雲平臺容器團隊 360雲計算 

女主宣言

利用kubernetes的滾動更新時，可能常常遇到發佈「太快不穩定」或「太慢體驗差」的狀況。本文將介紹kubernetes滾動更新控制速率的特性。

PS：豐富的一線技術、多元化的表現形式，盡在「360雲計算」，點關注哦！

1

含義

服務在滾動更新時，deployment控制器的目的是：給舊版本(old_rs)副本數減小至0、給新版本(new_rs)副本數量增至指望值(replicas)。你們在使用時，一般容易忽視控制速率的特性，如下是kubernetes提供的兩個參數：

1. maxUnavailable：和指望ready的副本數比，不可用副本數最大比例（或最大值），這個值越小，越能保證服務穩定，更新越平滑；
2. maxSurge：和指望ready的副本數比，超過時望副本數最大比例（或最大值），這個值調的越大，副本更新速度越快。

2

取值範圍

數值

1. maxUnavailable: [0, 副本數]maxSurge: [0, 副本數]

2. maxSurge: [0, 副本數]

注意：二者不能同時爲0。

比例

1. maxUnavailable: [0%, 100%] 向下取整，好比10個副本，5%的話==0.5個，但計算按照0個；

2. maxSurge: [0%, 100%] 向上取整，好比10個副本，5%的話==0.5個，但計算按照1個；

注意：二者不能同時爲0。

建議配置

1. maxUnavailable == 0

2. maxSurge == 1

這是咱們生產環境提供給用戶的默認配置。即「一上一下，先上後下」最平滑原則：1個新版本pod ready（結合readiness）後，才銷燬舊版本pod。此配置適用場景是平滑更新、保證服務平穩，但也有缺點，就是「太慢」了。

3

自定義策略

Deployment controller調整replicaset數量時，嚴格經過如下公式來控制發佈節奏。因此，如需快速發佈，可根據實際狀況去調整這兩個值：

(目標副本數-maxUnavailable) <= 線上實際Ready副本數 <= (目標副本數+maxSurge)

舉例：若是指望副本數是10，指望能有至少80%數量的副本能穩定工做，因此:maxUnavailable = 2，maxSurge = 2 (可自定義，建議與maxUnavailable保持一致)

8 <= 線上實際Ready副本數 <= 12

這樣，更新過程當中，線上可以正常提供服務的pod數總會保持在這個區間內。

4

總結

本文解釋了kubernetes最易忽略的「滾動更新策略中控制更新速率」的特性：maxUnavailable與maxSurge，但願能對你在發佈版本時有所幫助。

後續文章會帶來deployment controller在多版本(replicaset)下控制滾動更新的原理，並分析其相應源碼實現邏輯。