課程文字：https://edu.aliyun.com/lesson_1651_18354?spm=5176.10731542.0.0.349620behMwqhU#_18354
Deployment：管理部署發佈的控制器
主要作用
- 定義一種pod的期望數量
- 配置pod發佈方式
- 更新中發生問題，可以一鍵回滾
Deployment的yaml文件
- kubectl get deployment 命令可查看deployment總體情況
- kubectl get pod可以查看到部署的情況：Pod 的 ownerReferences 即 Pod 所屬的 controller 資源，並不是 Deployment，而是一個 ReplicaSet。這個 ReplicaSet 的 name，其實是 nginx-deployment 加上 pod.template-hash，所有的 Pod 都是 ReplicaSet 創建出來的，而 ReplicaSet 它對應的某一個具體的 Deployment.template 版本。
更新鏡像
- kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1
- kubectl 後面有一個 set image 固定寫法，這裏指的是設定鏡像；其次是一個 deployment.v1.apps，這裏也是一個固定寫法，表明要操作的資源類型，deployment 是資源名、v1 是資源版本、apps 是資源組，這裏也可以簡寫爲 deployment 或者 deployment.apps，比如說寫爲 deployment 的時候，默認將使用 apps 組 v1 版本。
- 更新的 deployment 的 name，nginx-deployment；再往後的 nginx 其實指的是 template，也就是 Pod 中的 container.name；這裏我們可以注意到：一個 Pod 中，其實可能存在多個 container，需要指定想要更新的鏡像的 container.name，就是 nginx。
快速回滾
- 回滾的時候，其實是創建了 3 箇舊版本的 pod，而並非把先前的 3 個 pod 恢復。
- 發佈會新建replicaSet，回滾不會
DeploymentStatus
- Processing 指的是 Deployment 正在處於擴容和發佈中。Processing 狀態的 deployment，它所有的 replicas 及 Pod 副本全部達到最新版本，而且是 available，這樣的話，就可以進入 complete 狀態。而 complete 狀態如果發生了一些擴縮容的話，也會進入 processing 這個處理工作狀態。
Deployment和ReplicaSet的關係
Deployment控制器
- 原理：所有的控制器都是通過 Informer 中的 Event 做一些 Handler 和 Watch。這個地方 Deployment 控制器，其實是關注 Deployment 和 ReplicaSet 中的 event，收到事件後會加入到隊列中。而 Deployment controller 從隊列中取出來之後，它的邏輯會判斷 Check Paused，這個 Paused 其實是 Deployment 是否需要新的發佈，如果 Paused 設置爲 true 的話，就表示這個 Deployment 只會做一個數量上的維持，不會做新的發佈。
- Check paused 爲 Yes 也就是 true 的話，那麼只會做 Sync replicas。也就是說把 replicas sync 同步到對應的 ReplicaSet 中，最後再 Update Deployment status，那麼 controller 這一次的 ReplicaSet 就結束了。
- paused 爲 false 的話，它就會做 Rollout，也就是通過 Create 或者是 Rolling 的方式來做更新，更新的方式其實也是通過 Create/Update/Delete 這種 ReplicaSet 來做實現的。
ReplicaSet控制器
- 當 Deployment 分配 ReplicaSet 之後，ReplicaSet 控制器本身也是從 Informer 中 watch 一些事件，這些事件包含了 ReplicaSet 和 Pod 的事件。從隊列中取出之後，ReplicaSet controller 的邏輯很簡單，就只管理副本數。也就是說如果 controller 發現 replicas 比 Pod 數量大的話，就會擴容，而如果發現實際數量超過期望數量的話，就會刪除 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。這兩個字段解析的意思，可以看下圖中詳細的 comment，或者簡單解釋一下：
- MaxUnavailable：滾動過程中最多有多少個 Pod 不可用；
- MaxSurge：滾動過程中最多存在多少個 Pod 超過預期 replicas 數量。
- 比如當用戶的資源足夠，且更注重發佈過程中的可用性，可設置 MaxUnavailable 較小、MaxSurge 較大。但如果用戶的資源比較緊張，可以設置 MaxSurge 較小，甚至設置爲 0，這裏要注意的是 MaxSurge 和 MaxUnavailable 不能同時爲 0。
- 兩者同時爲 0 的話，MaxSurge 保證不能新擴 Pod，而 MaxUnavailable 不能保證 ReplicaSet 中有 Pod 是 available 的，這樣就會產生問題。所以說這兩個值不能同時爲 0。用戶可以根據自己的實際場景來設置對應的、合適的值。
自測題目
https://gitchat.csdn.net/columnTopic/5d75e21809afba1228a0522c
通過 Deployment 不能實現以下功能：（單選題）C
- A. 應用擴縮容
- B. 應用發佈回滾
- C. 應用重啓
- D. 應用副本數量維持
一個 Deployment 中，哪些 labels/selector 必須一致：（單選題）C
- A. deployment.Labels 與 deployment.Spec.Template.Labels一致
- B. deployment.Labels 與 deployment.Spec.Selector 一致
- C. deployment.Spec.Selector 與 deployment.Spec.Template.Labels 一致
- D. deployment.Labels、deployment.Spec.Selector、deployment.Spec.Template.Labels 三者都要一致
創建 Deployment 描述文件中寫的 template，用處不包括：（單選題）D
- A. 聲明 Pod 的掛載目錄
- B. 計算 ReplicaSet 的 hash
- C. 指定鏡像版本
- D. 指定期望數量
以下哪個明顯不是 deployment 擴容出來的 pod name ？（單選題）B
- A. nginx-deployment-77964d65f-5h52m
- B. nginx-deployment-676cc869
- C. nginx-deployment-6987cdb55b-r4tnr
- D. nginx-deployment-5c689d88bb-vqf4b
以下關於 revision 歷史版本說法正確的是：（單選題）B
- A. 使用 deployment 可以 rollout 回滾到任何一個歷史上的版本
- B. pod-template-hash 標識了 pod 的 revision 版本
- C. revisionHistoryLimit 字段不設置默認沒有數量限制
- D. 更新了 deployment 任意字段，最新 revision 會發生變化
以下關於 paused 說法錯誤的是：（單選題）D
- A. 可以在 deployment 發佈的過程中修改 paused 字段
- B. paused 默認值爲 false
- C. paused 不可以用來暫停擴縮容操作
- D. deployment controller 在發佈出現問題時會自動設置 paused
關於 MaxUnavailable 以下說法正確的是：（單選題）B
- A. MaxUnavailable 不可以設置爲 0，否則無法發佈 （可以設置爲0，必須刪除舊的，創建新的）
- B. MaxUnavailable 可以設置超過 replicas
- C. MaxUnavailable 可以和 MaxSurge 同時設置爲 0 （不可以同時爲0）
- D. MaxUnavailable 可以設置超過 100% （升級更新的字段，最多100%）
Deployment 與 ReplicaSet 的關係與以下哪組資源最像？（單選題）C
- A. Pod 與 Node
- B. Pod 與 Container
- C. ReplicaSet 與 Pod
- D. Deployment 與 Pod
指定 Deployment 回滾到某個歷史版本執行成功的過程中，不會發生以下哪些事件：（多選題）BC
- A. Pod 創建和銷燬
- B. ReplicaSet 創建和銷燬
- C. Deployment 期望數量變化
- D. Deployment template 變化
以下關於 Deployment 的說法正確的有哪些?（多選題）AC
- A. Deployment 下 running 的 Pod 數量可能大於 replicas 數量
- B. Deployment 更新鏡像時一定會創建一個 ReplicaSet
- C. Deployment 回滾時會創建一個 ReplicaSet
- D. 滾動發佈的時候 MaxUnavailable 和 MaxSurge 可以同時設爲 0