共計 900 個字符，預計需要花費 3 分鐘才能閱讀完成。

這期內容當中丸趣 TV 小編將會給大家帶來有關如何在 Rolling Update 中使用 Health Check，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

Health Check 另一個重要的應用場景是 Rolling Update。試想一下下面的情況：

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

正常情況下新副本需要 10 秒鐘完成準備工作，在此之前無法響應業務請求。

但由于人為配置錯誤，副本始終無法完成準備工作（比如無法連接后端數據庫）。

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

因為新副本本身沒有異常退出，默認的 Health Check 機制會認為容器已經就緒，進而會逐步用新副本替換現有副本，其結果就是：當所有舊副本都被替換后，整個應用將無法處理請求，無法對外提供服務。如果這是發生在重要的生產系統上，后果會非常嚴重。

如果正確配置了 Health Check，新副本只有通過了 Readiness 探測，才會被添加到 Service；如果沒有通過探測，現有副本不會被全部替換，業務仍然正常進行。

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

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

10 秒后副本能夠通過 Readiness 探測。

很顯然，由于新副本中不存在  /tmp/healthy，是無法通過 Readiness 探測的。驗證如下：

如果滾動更新失敗，可以通過  kubectl rollout undo  回滾到上一個版本。

小結

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

上述就是丸趣 TV 小編為大家分享的如何在 Rolling Update 中使用 Health Check 了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注丸趣 TV 行業資訊頻道。