【學習筆記】應用與編排管理：Deployment
- 需求來源
-
- 背景問題
- Deployment：管理部署釋出的控制器
- 架構設計
-
- 管理模式
- Deployment 控制器
- ReplicaSet 控制器
- 釋出模拟
- spec 字段解析
- 更新政策字段解析
需求來源
背景問題
現在存在三個應用，分别對應一些 Pod，那麼我們可以直接管理叢集中所有的 Pod 嗎？
如果管理所有的 Pod，那麼如何保證叢集裡可用 Pod 數量？如何為所有 Pod 更新鏡像版本？更新的過程中，如何保證服務可用性？更新的過程中，發現問題如何快速復原？
Deployment：管理部署釋出的控制器
可以通過 Deployment 将三個應用分别規劃到不同的 Deployment，每個 Deployment 管理一組相同的應用 Pod，這組 Pod 是相同的一個副本。
Deployment 可以實作以下功能：
- Deployment 定義了 Pod 期望數量；
- 配置 Pod 釋出方式，即 controller 會按照使用者給定的政策來更新 Pod，而且更新過程中，可以設定不可用 Pod 數量在多少範圍内；
- 更新過程中發現問題可以復原。
架構設計
管理模式
Deployment 隻管理不同版本的 ReplicaSet，由 ReplicaSet 來管理具體的 Pod 副本數，每個 ReplicaSet 對應 Deployment template 的一個版本。
Deployment 控制器
控制器通過 Informer 中的 Event 做一些 Handler 和 Watch，收到事件後會加入到隊列中。而 Deployment controller 從隊列中取出來之後，它的邏輯會判斷 Check Paused，如果 Paused 設定為 true 的話，就表示這個 Deployment 隻會做一個數量上的維持，不會做新的釋出，如果為 false 的話，就會做 Rollout。
ReplicaSet 控制器
當 Deployment 配置設定 ReplicaSet 之後，ReplicaSet 控制器本身也是從 Informer 中 watch 一些事件，這些事件包含了 ReplicaSet 和 Pod 的事件。從隊列中取出之後，ReplicaSet controller 的邏輯很簡單，就隻管理副本數。
釋出模拟
Deployment 目前初始版本為 template1，底下有三個 Pod：Pod1、Pod2、Pod3。
這時修改 template 中一個容器的 image，Deployment controller 就會建立一個對應 template2 的 ReplicaSet。建立出來之後 ReplicaSet 會逐漸修改兩個 ReplicaSet 的數量，比如逐漸增加 ReplicaSet2 中 replicas 的期望數量，逐漸減少 ReplicaSet1 中的 Pod 數量。
spec 字段解析
- MinReadySeconds：Deployment 會根據 Pod ready 來看 Pod 是否可用，但是如果我們設定了 MinReadySeconds 之後，比如設定為 30 秒，那 Deployment 就一定會等到 Pod ready 超過 30 秒之後才認為 Pod 是 available 的。Pod available 的前提條件是 Pod ready，但是 ready 的 Pod 不一定是 available 的，它一定要超過 MinReadySeconds 之後，才會判斷為 available；
- revisionHistoryLimit：保留曆史 revision，即保留曆史 ReplicaSet 的數量，預設值為 10 個。這裡可以設定為一個或兩個，如果復原可能性比較大的話，可以設定數量超過 10；
- paused：paused 是辨別，Deployment 隻做數量維持，不做新的釋出，這裡在 Debug 場景可能會用到；
- progressDeadlineSeconds：前面提到當 Deployment 處于擴容或者釋出狀态時，它的 condition 會處于一個 processing 的狀态，processing 可以設定一個逾時時間。如果超過逾時時間還處于 processing，那麼 controller 将認為這個 Pod 會進入 failed 的狀态。
更新政策字段解析
Deployment 在 RollingUpdate 中主要提供了兩個政策，一個是 MaxUnavailable，另一個是 MaxSurge。
- MaxUnavailable：滾動過程中最多有多少個 Pod 不可用；
- MaxSurge：滾動過程中最多存在多少個 Pod 超過預期 replicas 數量。
上文提到，ReplicaSet 為 3 的 Deployment 在釋出的時候可能存在一種情況：新版本的 ReplicaSet 和舊版本的 ReplicaSet 都可能有兩個 replicas，加在一起就是 4 個，超過了我們期望的數量三個。這是因為我們預設的 MaxUnavailable 和 MaxSurge 都是 25%，預設 Deployment 在釋出的過程中，可能有 25% 的 replica 是不可用的，也可能超過 replica 數量 25% 是可用的，最高可以達到 125% 的 replica 數量。
這裡其實可以根據使用者實際場景來做設定。比如當使用者的資源足夠，且更注重釋出過程中的可用性，可設定 MaxUnavailable 較小、MaxSurge 較大。但如果使用者的資源比較緊張，可以設定 MaxSurge 較小，甚至設定為 0，這裡要注意的是 MaxSurge 和 MaxUnavailable 不能同時為 0。
@山東·威海 2020.05.19