溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
這期內容當中小編將會給大家帶來有關如何在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 場景中的應用。
上述就是小編為大家分享的如何在Rolling Update中使用Health Check了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注億速云行業資訊頻道。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
