在 Rolling Update 中使用 Health Check - 天天5分鐘玩轉 Docker 容器技術（146）

上一節討論了 Health Check 在 Scale Up 中的應用，Health Check 另外一個重要的應用場景是 Rolling Update。試想一下下面的狀況：

現有一個正常運行的多副本應用，接下來對應用進行更新（好比使用更高版本的 image），Kubernetes 會啓動新副本，而後發生了以下事件：

1. 正常狀況下新副本須要 10 秒鐘完成準備工做，在此以前沒法響應業務請求。

2. 但因爲人爲配置錯誤，副本始終沒法完成準備工做（好比沒法鏈接後端數據庫）。

先別繼續往下看，如今請花一分鐘思考這個問題：若是沒有配置 Health Check，會出現怎樣的狀況？

由於新副本自己沒有異常退出，默認的 Health Check 機制會認爲容器已經就緒，進而會逐步用新副本替換現有副本，其結果就是：當全部舊副本都被替換後，整個應用將沒法處理請求，沒法對外提供服務。若是這是發生在重要的生產系統上，後果會很是嚴重。

若是正確配置了 Health Check，新副本只有經過了 Readiness 探測，纔會被添加到 Service；若是沒有經過探測，現有副本不會被所有替換，業務仍然正常進行。

下面經過例子來實踐 Health Check 在 Rolling Update 中的應用。

用以下配置文件 app.v1.yml 模擬一個 10 副本的應用：

10 秒後副本可以經過 Readiness 探測。

接下來滾動更新應用，配置文件 app.v2.yml 以下：

很顯然，因爲新副本中不存在 /tmp/healthy，是沒法經過 Readiness 探測的。驗證以下：

這個截圖包含了大量的信息，值得咱們詳細分析。

先關注 kubectl get pod 輸出：

1. 從 Pod 的 AGE 欄可判斷，最後 5 個 Pod 是新副本，目前處於 NOT READY 狀態。

2. 舊副本從最初 10 個減小到 8 個。

再來看 kubectl get deployment app 的輸出：

1. DESIRED 10 表示指望的狀態是 10 個 READY 的副本。

2. CURRENT 13 表示當前副本的總數：即 8 箇舊副本 + 5 個新副本。

3. UP-TO-DATE 5 表示當前已經完成更新的副本數：即 5 個新副本。

4. AVAILABLE 8 表示當前處於 READY 狀態的副本數：即 8箇舊副本。

在咱們的設定中，新副本始終都沒法經過 Readiness 探測，因此這個狀態會一直保持下去。

上面咱們模擬了一個滾動更新失敗的場景。不過幸運的是：Health Check 幫咱們屏蔽了有缺陷的副本，同時保留了大部分舊副本，業務沒有因更新失敗受到影響。

接下來咱們要回答：爲何新建立的副本數是 5 個，同時只銷毀了 2 箇舊副本？

緣由是：滾動更新經過參數 maxSurge 和 maxUnavailable 來控制副本替換的數量。

maxSurge

此參數控制滾動更新過程當中副本總數的超過 DESIRED 的上限。maxSurge 能夠是具體的整數（好比 3），也能夠是百分百，向上取整。maxSurge 默認值爲 25%。

在上面的例子中，DESIRED 爲 10，那麼副本總數的最大值爲：
roundUp(10 + 10 * 25%) = 13

因此咱們看到 CURRENT 就是 13。

maxUnavailable

此參數控制滾動更新過程當中，不可用的副本相佔 DESIRED 的最大比例。 maxUnavailable 能夠是具體的整數（好比 3），也能夠是百分百，向下取整。maxUnavailable 默認值爲 25%。

在上面的例子中，DESIRED 爲 10，那麼可用的副本數至少要爲：
10 - roundDown(10 * 25%) = 8

因此咱們看到 AVAILABLE 就是 8。

maxSurge 值越大，初始建立的新副本數量就越多；maxUnavailable 值越大，初始銷燬的舊副本數量就越多。

理想狀況下，咱們這個案例滾動更新的過程應該是這樣的：

1. 首先建立 3 個新副本使副本總數達到 13 個。

2. 而後銷燬 2 箇舊副本使可用的副本數降到 8 個。

3. 當這 2 箇舊副本成功銷燬後，可再建立 2 個新副本，使副本總數保持爲 13 個。

4. 當新副本經過 Readiness 探測後，會使可用副本數增長，超過 8。

5. 進而能夠繼續銷燬更多的舊副本，使可用副本數回到 8。

6. 舊副本的銷燬使副本總數低於 13，這樣就容許建立更多的新副本。

7. 這個過程會持續進行，最終全部的舊副本都會被新副本替換，滾動更新完成。

而咱們的實際狀況是在第 4 步就卡住了，新副本沒法經過 Readiness 探測。這個過程能夠在 kubectl describe deployment app 的日誌部分查看。

若是滾動更新失敗，能夠經過 kubectl rollout undo 回滾到上一個版本。

若是要定製 maxSurge 和 maxUnavailable，能夠以下配置：

小結

本章咱們討論了 Kubernetes 健康檢查的兩種機制：Liveness 探測和 Readiness 探測，並實踐了健康檢查在 Scale Up 和 Rolling Update 場景中的應用。

下節咱們開始討論 Kubernetes 如何管理數據。 

書籍：

1.《天天5分鐘玩轉Kubernetes》
https://item.jd.com/26225745440.html

2.《天天5分鐘玩轉Docker容器技術》
https://item.jd.com/16936307278.html

3.《天天5分鐘玩轉OpenStack》
https://item.jd.com/12086376.html