前言

終於進入 Deployment 系列文的最後一篇也是非常重要的一篇了，在 K8s 系列文中的第一篇文章提到 Deployment 是可以進行 Pod 內容更新，接下來就要好好談談 Deployment 是如何更新 Pod 的內容。

要如何更新 Deployment 內部的 Pod

大家都知道 Pod 為 K8s 最小的運行單位，所以更新 Pod 意思就是把內部運行的 container 進行更新，也就是說我們只要更新 Pod 的 image 就可以順利的讓 Pod 運行最新的內容， Deployment 就是運用這個原理才進行 Pod 的內容更新，方法也很簡單只要利用 set 這個參數就好，下 kubectl set -h 可以看到 set 這個參數真正的用法。

可以看到 set 後面還要再接 SUBCOMMAND 而這個 SUBCOMMAND 就是 Available Commands 的內容，由於我們要更新的是 image 所以這邊的 SUBCOMMAND 會是 image，這時候就可以很開心的下 kubectl set image deployment/deploymentName imageResource 結果卻發生錯誤了。

原因在於 image 不能單純給來源而已，必須要把這個 image 定義一個名字這樣才能套用到 Deployment 內，所以這邊稍微改寫一下整個指令變成 kubectl set image deployment/deploymentName imageName=imageResource，這裡筆者建議多加一個 --record 的參數，這樣就會記錄每次更新的時候到底是更新什麼內容進去，這樣日後要進行 rollback 的時候也比較容易知道要 rollback 回哪個 revision。

接下來可以查看 ReplicaSet 以及 Pod 在更新過程中的變化。

可以發現 strategy 為 RollingUpdate 的時候並不會把舊有的 Pod 移除反而會讓新舊 Pod 同時上線，以達到無停機服務的作用，但這樣在網頁中就有可能會同時出現新舊內容。

如果今天 strategy 設定為 Recreate 就會在更新的過程中出現 503 的錯誤。

Deployment 回朔版本

講完了更新之後接下來講講如何 rollback 回之前的版本，首先我們必須要用到 rollout 這個參數，下 kubectl rollout -h 之後可以看到 rollout 真正的用法，是不是覺得跟 set 用法很像呢XD

由於這邊我們要 rollback ，所以這邊的 SUBCOMMAND 會使用 undo，還記得筆者上面提到的 revision 嗎？其實筆者還是建議用 revision 的方式來決定要 rollback 到哪個版本去，所以整體寫法就會像這樣： kubectl rollout undo deployment/deploymentName --to-revision=revisionNumber

這邊如果想知道這個 Deployment 有哪些歷史的話也可以利用 history 這個 SUBCOMMAND 來查看，這樣就可以知道要用哪個 revision 了。

為何要捨棄 Replication Controller

由於現在練習的東西都比較簡單，所以用 Replication Controller 就可以達到控制 Pod 了，但其實真正實務上在使用 K8s 時用的架構可是會比練習的複雜很多，所以用 ReplicaSet 讓 selector 用更彈性的方式來選取 Pod 會是比較好的做法。

其實官網在 Replication Controller 後面有加這段文字：

NOTE: A Deployment that configures a ReplicaSet is now the recommended way to set up replication.

連官網自己都說用 ReplicaSet 來產生 Pod 的 replication 是比較推薦的做法了，所以讀者如果要玩 Pod 的 replication 還是建議用 Deployment 搭配 ReplicaSet 比較好。

小結

終於把整個 Deployment 介紹完了，相信內容真的很多很難消化，但 Deployment 是個非常重要的觀念。

接下來要講的東西都會基於 Deployment 的設定來做更深入的改寫，如果對於文章有任何問題都歡迎留言給我，那我們就下篇文章見嘍～