Part 01、升級策略 

K8S中通過spect.strategy來定義新的 Pod 替換為舊的Pod的策略。策略類型分為：重建策略（Recreate）或滾動升級策略（RollingUpdate），默認為 RollingUpdate。

Recreate -- 在創建出新的Pod之前會先刪掉所有已存在的Pod。

RollingUpdate -- 可以指定maxSurge和maxUnavailable來控制滾動升級過程。

• maxSurge：用來指定升級期間可以超過預期Pod數量的最大值，該值可以是一個絕對數（例如：5）或一個預期 Pod 的百分比（例如：10%），默認為 25%。通過百分比計算的絕對值向上取整。
• maxUnavailable：用來指定升級期間不可用的最大 Pod 數量。該值可以是一個絕對數（例如：5）或一個預期 Pod 的百分比（例如：10%），默認為 25%。通過百分比計算的絕對值向下取整。

在業務中我們默認使用滾動升級策略，通過合理配置maxSurge和maxUnavailable實現業務高可用。

Part 02、健康檢查 

K8S中通過探針對容器執行定期診斷來判斷容器的狀態，通常使用存活性探針（liveness probes）和就緒性探針（readiness probes）根據容器狀態進行后續處理。

• livenessProbe：探測容器是否正在運行。如果存活探測失敗，則 kubelet 會殺死容器，并且容器將受到其重啟策略的影響。如果容器不提供存活探針，則默認狀態為 Success。
• readinessProbe：探測容器是否準備好服務請求。如果就緒探測失敗，端點控制器將從與 Pod 匹配的所有Service的端點中刪除該Pod的IP地址。初始延遲之前的就緒狀態默認為 Failure。如果容器不提供就緒探針，則默認狀態為 Success。

在業務中我們經常同時使用這兩種探針，通過存活性探針判斷容器是否需要重啟以實現自愈，通過就緒性探針判斷容器是否已經準備好對外提供服務。

Part 03、K8S滾動升級原理

K8S通過Deployment創建副本，Deployment是一個三級結構：Deployment控制Replicaset（副本集），Replicaset控制Pod。根據Deployment的這個結構特性，一個Deployment下可存在不同的Replicaset，那就表示一個Deployment下可以有不同鏡像版本的Pod同時存在。

升級過程中Deployment自動創建Replicaset，Replicaset通過滾動升級策略中maxSurge、maxUnavailable兩個參數來精準地控制每次滾動的Pod數量。再結合健康檢查中的存活性探針（liveness probes）和就緒性探針（readiness probes）來精準判斷Pod何時啟動成功以及何時準備好服務請求，確保升級過程中可用的Pod都是可正常提供服務的。

具體過程如下圖所示。

K8S滾動升級過程

Part 04、總結

本文中介紹了K8S中的升級策略和健康檢查，通過配置升級策略和健康檢查實現滾動升級來確保微服務的平滑部署，但滾動升級也對業務設計提出了更高的要求，需要業務在設計中做到前后版本兼容，否則滾動升級過程中新舊版本同時存在期間服務調用可能會導致業務失敗、臟數據等問題，業務要根據自身特性與需求選擇適合的升級方案。

引用：

kubernetes中文文檔：

???http://docs.kubernetes.org.cn/317.html???