应用编排与管理
本節(jié)課程要點
需求來源
背景問題
首先，我們來看一下背景問題。如下圖所示：如果我們直接管理集群中所有的 Pod，應用 A、B、C 的 Pod，其實是散亂地分布在集群中。
現(xiàn)在有以下的問題：
- 首先，如何保證集群內(nèi)可用 Pod 的數(shù)量？也就是說我們應用 A 四個 Pod 如果出現(xiàn)了一些宿主機故障，或者一些網(wǎng)絡(luò)問題，如何能保證它可用的數(shù)量？
- 如何為所有 Pod 更新鏡像版本？我們是否要某一個 Pod 去重建新版本的 Pod？
- 然后在更新過程中，如何保證服務的可用性？
- 以及更新過程中，如果發(fā)現(xiàn)了問題，如何快速回滾到上一個版本？
Deployment：管理部署發(fā)布的控制器
這里就引入了我們今天課程的主題：Deployment 管理部署發(fā)布的控制器。
可以看到我們通過 Deployment 將應用 A、B、C 分別規(guī)劃到不同的 Deployment 中，每個 Deployment 其實是管理的一組相同的應用 Pod，這組 Pod 我們認為它是相同的一個副本，那么 Deployment 能幫我們做什么事情呢？
首先，Deployment 定義了一種 Pod 期望數(shù)量，比如說應用 A，我們期望 Pod 數(shù)量是四個，那么這樣的話，controller 就會持續(xù)維持 Pod 數(shù)量為期望的數(shù)量。當我們與 Pod 出現(xiàn)了網(wǎng)絡(luò)問題或者宿主機問題的話，controller 能幫我們恢復，也就是新擴出來對應的 Pod，來保證可用的 Pod 數(shù)量與期望數(shù)量一致；
配置 Pod 發(fā)布方式，也就是說 controller 會按照用戶給定的策略來更新 Pod，而且更新過程中，也可以設(shè)定不可用 Pod 數(shù)量在多少范圍內(nèi)；
如果更新過程中發(fā)生問題的話，即所謂“一鍵”回滾，也就是說你通過一條命令或者一行修改能夠?qū)?Deployment 下面所有 Pod 更新為某一個舊版本 。
用例解讀
Deployment 語法
下面我們用一個簡單的用例來解讀一下如何操作 Deployment。
上圖可以看到一個最簡單的 Deployment 的 yaml 文件。
“apiVersion：apps/v1”，也就是說 Deployment 當前所屬的組是 apps，版本是 v1。“metadata”是我們看到的 Deployment 元信息，也就是往期回顧中的 Labels、Selector、Pod.image，這些都是在往期中提到的知識點。
Deployment 作為一個 K8s 資源，它有自己的 metadata 元信息，這里我們定義的 Deployment.name 是 nginx.Deployment。Deployment.spec 中首先要有一個核心的字段，即 replicas，這里定義期望的 Pod 數(shù)量為三個；selector 其實是 Pod 選擇器，那么所有擴容出來的 Pod，它的 Labels 必須匹配 selector 層上的 image.labels，也就是 app.nginx。
就如上面的 Pod 模板 template 中所述，這個 template 它其實包含了兩部分內(nèi)容：
一部分是我們期望 Pod 的 metadata，其中包含了 labels，即跟 selector.matchLabels 相匹配的一個 Labels；
第二部分是 template 包含的一個 Pod.spec。這里 Pod.spec 其實是 Deployment 最終創(chuàng)建出來 Pod 的時候，它所用的 Pod.spec，這里定義了一個 container.nginx，它的鏡像版本是 nginx:1.7.9。
下面是遇到的新知識點：
- 第一個是 replicas，就是 Deployment 中期望的或者終態(tài)數(shù)量；
- 第二個是 template，也就是 Pod 相關(guān)的一個模板。
查看 Deployment 狀態(tài)
當我們創(chuàng)建出一個 Deployment 的時候，可以通過 kubectl get deployment，看到 Deployment 總體的一個狀態(tài)。如下圖所示：
上圖中可以看到：
- DESIRED：期望的 Pod 數(shù)量是 3 個；
- CURRENT：當前實際 Pod 數(shù)量是 3 個；
- UP-TO-DATE：其實是到達最新的期望版本的 Pod 數(shù)量；
- AVAILABLE：這個其實是運行過程中可用的 Pod 數(shù)量。后面會提到，這里 AVAILABLE 并不簡單是可用的，也就是 Ready 狀態(tài)的，它其實包含了一些可用超過一定時間長度的 Pod；
- AGE：deployment 創(chuàng)建的時長，如上圖 Deployment 就是已經(jīng)創(chuàng)建了 80 分鐘。
查看 Pod
最后我們可以查看一下 Pod。如下圖所示：
上圖中有三個 Pod，Pod 名字格式我們不難看到。
最前面一段：nginx-deployment，其實是 Pod 所屬 Deployment.name；中間一段：template-hash，這里三個 Pod 是一樣的，因為這三個 Pod 其實都是同一個 template 中創(chuàng)建出來的。
最后一段，是一個 random 的字符串，我們通過 get.pod 可以看到，Pod 的 ownerReferences 即 Pod 所屬的 controller 資源，并不是 Deployment，而是一個 ReplicaSet。這個 ReplicaSet 的 name，其實是 nginx-deployment 加上 pod.template-hash，后面會提到。所有的 Pod 都是 ReplicaSet 創(chuàng)建出來的，而 ReplicaSet 它對應的某一個具體的 Deployment.template 版本。
更新鏡像
接下來我們可以看一下，如何對一個給定的 Deployment 更新它所有Pod的鏡像版本呢？這里我們可以執(zhí)行一個 kubectl 命令：
kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1
首先 kubectl 后面有一個 set image 固定寫法，這里指的是設(shè)定鏡像；其次是一個 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。
最后，指定我們這個容器期望更新的鏡像版本，這里指的是 nginx: 1.9.1。如下圖所示：當執(zhí)行完這條命令之后，可以看到 deployment 中的 template.spec 已經(jīng)更新為 nginx: 1.9.1。
快速回滾
如果我們在發(fā)布過程中遇到了問題，也支持快速回滾。通過 kubectl 執(zhí)行的話，其實是“kubectl rollout undo”這個命令，可以回滾到 Deployment 上一版本；通過“rollout undo”加上“to-revision”來指定可以回滾到某一個具體的版本。
DeploymeStatus
最后我們來看一下 DeploymeStatus。前面的課程我們學習到，每一個資源都有它的 spec.Status。這里可以看一下，deploymentStatus 中描述的三個其實是它的 conversion 狀態(tài)，也就是 Processing、Complete 以及 Failed。
以 Processing 為例：Processing 指的是 Deployment 正在處于擴容和發(fā)布中。比如說 Processing 狀態(tài)的 deployment，它所有的 replicas 及 Pod 副本全部達到最新版本，而且是 available，這樣的話，就可以進入 complete 狀態(tài)。而 complete 狀態(tài)如果發(fā)生了一些擴縮容的話，也會進入 processing 這個處理工作狀態(tài)。
如果在處理過程中遇到一些問題：比如說拉鏡像失敗了，或者說 readiness probe 檢查失敗了，就會進入 failed 狀態(tài)；如果在運行過程中即 complete 狀態(tài)，中間運行時發(fā)生了一些 pod readiness probe 檢查失敗，這個時候 deployment 也會進入 failed 狀態(tài)。進入 failed 狀態(tài)之后，除非所有點 replicas 均變成 available，而且是 updated 最新版本，deployment 才會重新進入 complete 狀態(tài)。
操作演示
Deployment 創(chuàng)建及狀態(tài)
下面我們來進行操作演示：這里連接一個阿里云服務集群。我們可以看到當前集群已經(jīng)有幾個可用的 node。
首先創(chuàng)建對應的 deployment。可以看到 deployment 中的 desired、current、up-to-date 以及 available 已經(jīng)都達到了可用的期望狀態(tài)。
Deployment 的結(jié)構(gòu)
這里看到 spec 中的 replicas 是三個，selector 以及 template labels中定義的標簽都是 app：nginx，spec 中的 image 是我們期望的 nginx: 1.7.9；status 中的 available.replicas，readReplicas 以及 updatedReplicas 都是 3 個。
Pod 狀態(tài)
我們可以再選擇一個 Pod 看一下狀態(tài)：
可以看到：Pod 中 ownerReferences 的功能是 ReplicaSet；pod.spec.container 里的鏡像是 1.7.9。這個 Pod 已經(jīng)是 Running 狀態(tài)，而且它的 conditions.status 是“true”，表示它的服務已經(jīng)可用了。
更新升級
當前只有最新版本的 replicaset，那么現(xiàn)在嘗試對 deployment 做一次升級。
“kubectl set image”這個操作命令，后面接 “deployment”，加 deployment.name，最后指定容器名，以及我們期望升級的鏡像版本。
接下來我們看下 deployment 中的 template 中的 image 已經(jīng)更新為 1.9.1。
這個時候我們再 get pod 看一下狀態(tài)。
三個 pod 已經(jīng)升級為新版本，pod 名字中的 pod-template-hash 也已更新。
可以看到：舊版本 replicaset 的 spec 數(shù)量以及 pod 數(shù)量是都是 0，新版本的 pod 數(shù)量是 3 個。
假設(shè)又做了一次更新，這個時候 get.pod 其實可以看到：當前的 pod 其實是有兩個舊版本的處于 running，另一個舊版本是在刪除中；而兩個新版本的 pod，一個已經(jīng)進入 running，一個還在 creating 中。
這時我們可用的 pod 數(shù)量即非刪除狀態(tài)的 pod 數(shù)量，其實是 4 個，已經(jīng)超過了 replica 原先在 deployment 設(shè)置的數(shù)量 3 個。這個原因是我們在 deployment 中有 maxavailable 和 maxsugar 兩個操作，這兩個配置可以限制我們在發(fā)布過程中的一些策略。在后面架構(gòu)設(shè)計中會講到這個問題。
** **
歷史版本保留 revisionHistoryLimit
上圖看到，我們當前最新版本的 replicaset 是 3 個 pod，另外還有兩個歷史版本的 replicaset，那么會不會存在一種情況：就是隨著 deployment 持續(xù)的更新，這個舊版本的 replicaset 會越積越多呢？其實 deployment 提供了一個機制來避免這個問題：在 deployment spec 中，有一個 revisionHistoryLimit，它的默認值為 10，它其實保證了保留歷史版本的 replicaset 的數(shù)量，我們嘗試把它改為 1。
由上面第二張圖，可以看到兩個 replicaset，也就是說，除了當前版本的 replicaset 之外，舊版本的 replicaset 其實只保留了一個。
回滾
最后再嘗試做一下回滾。首先再來看一下 replicaset，這時發(fā)現(xiàn)舊版本的 replicaset 數(shù)量從 0 個增到 2 個，而新版本的 replicaset 數(shù)量從 3 個削減為 1 個，表示它已經(jīng)開始在做回滾的操作。然后再觀察一下， 舊版本的數(shù)量已經(jīng)是 3 個，即已經(jīng)回滾成功，而新版本的 pod 數(shù)量變?yōu)?0 個。
我們最后再 get pod 看一下：
這時，3 個 pod.template-hash 已經(jīng)更新為舊版本的 hash，但其實這 3 個 pod 都是重新創(chuàng)建出來的，而并非我們在前一版本中創(chuàng)建的 3 個 pod。換句話說，也就是我們回滾的時候，其實是創(chuàng)建了 3 個舊版本的 pod，而并非把先前的 3 個 pod 找回來。
架構(gòu)設(shè)計
管理模式
我們來看一下架構(gòu)設(shè)計。首先簡單看一下管理模式：Deployment 只負責管理不同版本的 ReplicaSet，由 ReplicaSet 來管理具體的 Pod 副本數(shù)，每個 ReplicaSet 對應 Deployment template 的一個版本。在上文的例子中可以看到，每一次修改 template，都會生成一個新的 ReplicaSet，這個 ReplicaSet 底下的 Pod 其實都是相同的版本。
如上圖所示：Deployment 創(chuàng)建 ReplicaSet，而 ReplicaSet 創(chuàng)建 Pod。他們的 OwnerRef 其實都對應了其控制器的資源。
Deployment 控制器
我們先簡單看一下控制器實現(xiàn)原理。
首先，我們所有的控制器都是通過 Informer 中的 Event 做一些 Handler 和 Watch。這個地方 Deployment 控制器，其實是關(guān)注 Deployment 和 ReplicaSet 中的 event，收到事件后會加入到隊列中。而 Deployment controller 從隊列中取出來之后，它的邏輯會判斷 Check Paused，這個 Paused 其實是 Deployment 是否需要新的發(fā)布，如果 Paused 設(shè)置為 true 的話，就表示這個 Deployment 只會做一個數(shù)量上的維持，不會做新的發(fā)布。
如上圖，可以看到如果 Check paused 為 Yes 也就是 true 的話，那么只會做 Sync replicas。也就是說把 replicas sync 同步到對應的 ReplicaSet 中，最后再 Update Deployment status，那么 controller 這一次的 ReplicaSet 就結(jié)束了。
那么如果 paused 為 false 的話，它就會做 Rollout，也就是通過 Create 或者是 Rolling 的方式來做更新，更新的方式其實也是通過 Create/Update/Delete 這種 ReplicaSet 來做實現(xiàn)的。
ReplicaSet 控制器
當 Deployment 分配 ReplicaSet 之后，ReplicaSet 控制器本身也是從 Informer 中 watch 一些事件，這些事件包含了 ReplicaSet 和 Pod 的事件。從隊列中取出之后，ReplicaSet controller 的邏輯很簡單，就只管理副本數(shù)。也就是說如果 controller 發(fā)現(xiàn) replicas 比 Pod 數(shù)量大的話，就會擴容，而如果發(fā)現(xiàn)實際數(shù)量超過期望數(shù)量的話，就會刪除 Pod。
上面 Deployment 控制器的圖中可以看到，Deployment 控制器其實做了更復雜的事情，包含了版本管理，而它把每一個版本下的數(shù)量維持工作交給 ReplicaSet 來做。
擴/縮容模擬
下面來看一些操作模擬，比如說擴容模擬。這里有一個 Deployment，它的副本數(shù)是 2，對應的 ReplicaSet 有 Pod1 和 Pod2。這時如果我們修改 Deployment replicas， controller 就會把 replicas 同步到當前版本的 ReplicaSet 中，這個 ReplicaSet 發(fā)現(xiàn)當前有 2 個 Pod，不滿足當前期望 3 個，就會創(chuàng)建一個新的 Pod3。
發(fā)布模擬
我們再模擬一下發(fā)布，發(fā)布的情況會稍微復雜一點。這里可以看到 Deployment 當前初始的 template，比如說 template1 這個版本。template1 這個 ReplicaSet 對應的版本下有三個 Pod：Pod1，Pod2，Pod3。
這時修改 template 中一個容器的 image， Deployment controller 就會新建一個對應 template2 的 ReplicaSet。創(chuàng)建出來之后 ReplicaSet 會逐漸修改兩個 ReplicaSet 的數(shù)量，比如它會逐漸增加 ReplicaSet2 中 replicas 的期望數(shù)量，而逐漸減少 ReplicaSet1 中的 Pod 數(shù)量。
那么最終達到的效果是：新版本的 Pod 為 Pod4、Pod5和Pod6，舊版本的 Pod 已經(jīng)被刪除了，這里就完成了一次發(fā)布。
回滾模擬
來看一下回滾模擬，根據(jù)上面的發(fā)布模擬可以知道 Pod4、Pod5、Pod6 已經(jīng)發(fā)布完成。這時發(fā)現(xiàn)當前的業(yè)務版本是有問題的，如果做回滾的話，不管是通過 rollout 命令還是通過回滾修改 template，它其實都是把 template 回滾為舊版本的 template1。
這個時候 Deployment 會重新修改 ReplicaSet1 中 Pod 的期望數(shù)量，把期望數(shù)量修改為 3 個，且會逐漸減少新版本也就是 ReplicaSet2 中的 replica 數(shù)量，最終的效果就是把 Pod 從舊版本重新創(chuàng)建出來。
發(fā)布模擬的圖中可以看到，其實初始版本中 Pod1、Pod2、Pod3 是舊版本，而回滾之后其實是 Pod7、Pod8、Pod9。就是說它的回滾并不是把之前的 Pod 重新找出來，而是說重新創(chuàng)建出符合舊版本 template 的 Pod。
spec 字段解析
最后再來簡單看一些 Deployment 中的字段解析。首先看一下 Deployment 中其他的 spec 字段：
MinReadySeconds：Deployment 會根據(jù) Pod ready 來看 Pod 是否可用，但是如果我們設(shè)置了 MinReadySeconds 之后，比如設(shè)置為 30 秒，那 Deployment 就一定會等到 Pod ready 超過 30 秒之后才認為 Pod 是 available 的。Pod available 的前提條件是 Pod ready，但是 ready 的 Pod 不一定是 available 的，它一定要超過 MinReadySeconds 之后，才會判斷為 available；
revisionHistoryLimit：保留歷史 revision，即保留歷史 ReplicaSet 的數(shù)量，默認值為 10 個。這里可以設(shè)置為一個或兩個，如果回滾可能性比較大的話，可以設(shè)置數(shù)量超過 10；
paused：paused 是標識，Deployment 只做數(shù)量維持，不做新的發(fā)布，這里在 Debug 場景可能會用到；
progressDeadlineSeconds：前面提到當 Deployment 處于擴容或者發(fā)布狀態(tài)時，它的 condition 會處于一個 processing 的狀態(tài)，processing 可以設(shè)置一個超時時間。如果超過超時時間還處于 processing，那么 controller 將認為這個 Pod 會進入 failed 的狀態(tài)。
升級策略字段解析
最后來看一下升級策略字段解析。
Deployment 在 RollingUpdate 中主要提供了兩個策略，一個是 MaxUnavailable，另一個是 MaxSurge。這兩個字段解析的意思，可以看下圖中詳細的 comment，或者簡單解釋一下：
- MaxUnavailable：滾動過程中最多有多少個 Pod 不可用；
- MaxSurge：滾動過程中最多存在多少個 Pod 超過預期 replicas 數(shù)量。
上文提到，ReplicaSet 為 3 的 Deployment 在發(fā)布的時候可能存在一種情況：新版本的 ReplicaSet 和舊版本的 ReplicaSet 都可能有兩個 replicas，加在一起就是 4 個，超過了我們期望的數(shù)量三個。這是因為我們默認的 MaxUnavailable 和 MaxSurge 都是 25%，默認 Deployment 在發(fā)布的過程中，可能有 25% 的 replica 是不可用的，也可能超過 replica 數(shù)量 25% 是可用的，最高可以達到 125% 的 replica 數(shù)量。
這里其實可以根據(jù)用戶實際場景來做設(shè)置。比如當用戶的資源足夠，且更注重發(fā)布過程中的可用性，可設(shè)置 MaxUnavailable 較小、MaxSurge 較大。但如果用戶的資源比較緊張，可以設(shè)置 MaxSurge 較小，甚至設(shè)置為 0，這里要注意的是 MaxSurge 和 MaxUnavailable 不能同時為 0。
理由不難理解，當 MaxSurge 為 0 的時候，必須要刪除 Pod，才能擴容 Pod；如果不刪除 Pod 是不能新擴 Pod 的，因為新擴出來的話，總共的 Pod 數(shù)量就會超過期望數(shù)量。而兩者同時為 0 的話，MaxSurge 保證不能新擴 Pod，而 MaxUnavailable 不能保證 ReplicaSet 中有 Pod 是 available 的，這樣就會產(chǎn)生問題。所以說這兩個值不能同時為 0。用戶可以根據(jù)自己的實際場景來設(shè)置對應的、合適的值。
本節(jié)總結(jié)
本節(jié)課的主要內(nèi)容就到此為止了，這里為大家簡單總結(jié)一下。
- Deployment 是 Kubernetes 中常見的一種 Workload，支持部署管理多版本的 Pod；
- Deployment 管理多版本的方式，是針對每個版本的 template 創(chuàng)建一個 ReplicaSet，由 ReplicaSet 維護一定數(shù)量的 Pod 副本，而 Deployment 只需要關(guān)心不同版本的 ReplicaSet 里要指定多少數(shù)量的 Pod；
- 因此，Deployment 發(fā)布部署的根本原理，就是 Deployment 調(diào)整不同版本 ReplicaSet 里的終態(tài)副本數(shù)，以此來達到多版本 Pod 的升級和回滾。
總結(jié)
