Kubernetes CKA課程筆記 64

Deployment Strategies — Rolling Update

考量到開發者透過ci/cd pipeline將應用程式打包為image

準備並佈署到K8s Cluster的版本為1.2(如下圖)

一般就是透過更新K8s Cluster內對應的Deployment元件

更新其佈署的Pod的image的版本tag

K8s Cluster偵測到Deployment元件異動後

就會執行舊版本的Pod移除,並運行新版本的Pod

但是到底是"移除"先執行? 還是"運行新版"先執行?

i.e.過程中是否有形成應用程式downtime?

並且假若新版本運行有問題,是否可能執行Deployment元件退版?

rollback回運行舊版本的image Pod?

另外在Default nameSpace執行以下指令時

kubectl get all

還會看到一些額外元件 — replicaset有何作用?

如上述,何謂ReplicaSet?

當在建立Deployment元件時,該元件將建立應用程式rollout

其過程會建立一個元件 — ReplicaSet

i.e.當建立Deployment元件過程中,連帶ReplicaSet在其背景下自動建立出來

並且ReplicaSet無時無刻專門負責處理Pod指定的replicas數量

例如在以下Configuration File內容下的Deployment元件:

經過Deployment建立ReplicaSet →ReplicaSet 建立Pod

至於更新image版本過程則有如下狀況:

• 除了既有的ReplicaSet 1(負責建立1.1的版本Pod)外
• 會建立出新的ReplicaSet 2(專門負責建立1.2的版本Pod)

• 並且最終1.1版的Pod會被移除
• 但是過程中到底是先移除舊的還是先建新的Pod
• 則是由Deployment Strategies控制

1.第一個是 Recreate Strategies:

• 這個策略很容易理解,考量到現在有1.2版的image要做重新佈署了
• 則連續動作會是如下:

先把舊的移除!

新版的才透過ReplicaSet 2佈署進去

• 如上所示,這個佈署策略存在downtime!

為了避免上述的downtime出現

就有另一種佈署策略 — Rolling Update Strategies

第二個是Rolling Update Strategies:

• 其執行的連續過程如下圖示:

1.開始更新時,ReplicaSet 2已經建立了

2.舊的一個Pod移除

3.一個新版本的Pod起來

4.下一個再移除

5.最後才建立完最後一個新版的Pod

• 上述過程就不存在downtime!!
• 最重要的是,這個佈署策略是"預設的"

後面範例會看到殘留的空的舊的ReplicaSet

並且Pod都屬於某個ReplicaSet

而ReplicaSet的名稱都是:[deployment name]-[隨機碼]

接著先來檢查目前既有的deployment元件的佈署策略,執行:

kubectl describe deployment {deployment 名稱}

如上,策略就是預設值的StrategyType為"RollingUpdate"

並且還有一行是:

RollingUpdateStrategy: 25% max unavailable,25% max surge

上述的意思就是可以依據比例的移除舊版Pod,並依據比例建立新版Pod

例如原本數量20個Pods更新image版本

則20*25%的舊Pods移除,並建立新20*25%數量Pods,以此類推直到建立完成

上述這個過程可以透過檢視Deployment Update Event來看到

(就在describe顯示的最下面)

剛剛執行的describe deployment指令後最底下

這邊我暫時先試著改寫一下目前這個nginx的deployment元件,並更新:

執行apply更新這個deployment元件:

確認看看ReplicaSet元件,在default的nameSpace下執行:

kubectl get all

查看該deployment元件的describe內的Event:

(舊的down/新的up)過程應該是並行的,只是有快有慢,不同時間寫完log

Rollout History(可參考筆記27):

• 當執行Deployment元件更新時,會建立"Revision"
• 可以執行以下指令確認建立的Revision執行:

kubectl rollout history deployment {deployment名稱}

Rollback:

這邊再簡單小改一下deployment元件:

並執行更新:

所以Revision共3代

並同時確認Pod與對應的ReplicaSet:

重複確認一下目前Pod的image版本,執行describe指令:

透過剛剛顯示的Revision,理當可以退版(Rollback)!!,其指令為:

kubectl rollout undo deployment {deployment名稱}

這邊我們就可以假設今天開發者佈署的就是剛剛的1.21版的nginx image

然後很不幸地,上線後發生問題,需要先退版本

就要嘗試退回使用前一版本image的Deployment元件

所以就要執行上述Undo指令:

執行後可以看看rollout狀態是否已經結束,執行:

kubectl rollout status deployment {deployment名稱}

顯示目前是已完成rollout的狀態!

再次重新確認ReplicaSet:

發現現在用舊的ReplicaSet!!! 比較新的那個14m的ReplicaSet的Pod數量歸零了

接著確認目前Pod版本:

最後再確認一下Revision狀況:

參考課程(reference)