上次我們說(shuō)到自己手動(dòng)的做使用 RS 的方式來(lái)升級(jí) pod ，感覺(jué)還是蠻復(fù)雜的，并且容易弄錯(cuò)，實(shí)際生產(chǎn)過(guò)程中，肯定不會(huì)這樣來(lái)弄，很危險(xiǎn)

那么今天我們來(lái)分享 Deployment 的方式來(lái)顯示的升級(jí)應(yīng)用吧

Deployment 的方式升級(jí)應(yīng)用

對(duì)于之前的操作方式有沒(méi)有感覺(jué)還是比較繁瑣的，還需要自己去切換流量，自己去創(chuàng)建新的 RS ，甚至最后還要將舊的 RS 刪除掉，甚是麻煩

我們來(lái)玩一個(gè)更加高階的資源，也是比較容易的，為了接下來(lái)的案例清晰，我們就把上述的 RS 全部刪除掉，留下 Service 后續(xù)可以使用

Deployment 是使用應(yīng)用程序聲明的方式來(lái)升級(jí)應(yīng)用，而不是通過(guò) RS 或者 RC 了

實(shí)際上創(chuàng)建一個(gè) Deployment ?資源，其實(shí)也會(huì)創(chuàng)建一個(gè) RS 資源，那么 Deployment ? 是拿來(lái)做啥的呢？我們可以理解為協(xié)調(diào)資源的

實(shí)踐 demo

創(chuàng)建一個(gè) deploy ，mydeploy.yaml

apiVersion:?apps/v1
kind:?Deployment
metadata:
??name:?newkubia
spec:
??replicas:?3
??selector:
????matchLabels:
??????app:?newkubia
??template:
????metadata:
??????name:?newkubia
??????labels:
????????app:?newkubia
????spec:
??????containers:
??????-?image:?xiaomotong888/newkubia:v1
????????name:?newkubia


• 咱們創(chuàng)建一個(gè) deployment

• 命名為 newkubia

• 副本數(shù)為 3 個(gè)

• 匹配的pod 標(biāo)簽是 newkubia

• RS 控制的模板是 創(chuàng)建出來(lái)的 容器名為 newkubia

• 標(biāo)簽也是 newkubia

kubectl create -f mydeploy.yaml --record

現(xiàn)在我們通過(guò)上述指令來(lái)創(chuàng)建一個(gè) Deployment，和其他資源一樣，Deployment 我們可以縮寫(xiě)為 deploy

此處的?--record?是什么意思呢？帶上這個(gè)參數(shù) deploy 會(huì)記錄我們歷史版本

當(dāng)然，我們也可以使用如下指令來(lái)查看 deploy 的狀態(tài)

kubectl rollout status deploy newkubia

當(dāng)然對(duì)于?kubectl describe ?, edit , get?都是適用于?deploy?的

我們可以在來(lái)看看，是不是創(chuàng)建了一個(gè) RS

上面的這些 pod 其實(shí)也都是這個(gè) RS 來(lái)創(chuàng)建出來(lái)的我們通過(guò) RS 和 pod 的名字就可以辨別出來(lái)

上述例子中：

RS：

newkubia-6597db5b9c

pod：

newkubia-6597db5b9c-*

這個(gè)隨機(jī)字符串，實(shí)際上是 Deployment 和 RS 中的 pod 模板放在一起計(jì)算出來(lái)的哈希值

我們將第一個(gè)例子用到的?Service?標(biāo)簽修改為?newkubia，進(jìn)入 任意一個(gè) pod ，訪問(wèn)一下服務(wù)地址，看看效果

如我們所期望的，也是我們想要的效果

使用 Deployment 的方式升級(jí)應(yīng)用

對(duì)于使用 Deployment 升級(jí)應(yīng)用，我們需要知道 Deployment ?涉及 2 個(gè)升級(jí)策略：

• RollingUpdate

滾動(dòng)升級(jí)，這個(gè)策略會(huì)漸進(jìn)式的刪除舊的 pod，同時(shí)創(chuàng)建新的 pod，整個(gè)過(guò)程，都保持咱們的服務(wù)是可用的，deploy 升級(jí)默認(rèn)是使用這種策略

• Recreate

會(huì)一次性刪除掉舊的 pod ，然后創(chuàng)建新的 pod，這種策略和之前我們說(shuō)到過(guò)的方式，效果上咱們的服務(wù)會(huì)中斷一段時(shí)間，這個(gè)時(shí)間具體是多久，就看你的手速了

為了我們?cè)谏?jí) deploy 的時(shí)候，能夠肉眼看出升級(jí)過(guò)程，我們將最小的準(zhǔn)備時(shí)間設(shè)置大一點(diǎn)，這樣我們可以看得清楚一些，

可以?kubectl edit deploy newkubia?，在 deploy spec 下面 添加 minReadySeconds: 10?，保存即可

當(dāng)然 k8s 還提供另外一個(gè) patch 的方式來(lái)簡(jiǎn)單修改 yaml 中的少許字段：

kubectl patch deploy newkubia -p '{"spec":{"minReadySeconds":10}}'

kubectl?set?image?deploy?newkubia?newkubia=xiaomotong888/newkubia:vv2


通過(guò)圖中的效果，我們確實(shí)清晰可以看到 pod 是在滾動(dòng)升級(jí)的，效果是先創(chuàng)建了一個(gè)新版本的 pod，運(yùn)行正常后，會(huì)殺掉一個(gè)舊的 pod，再創(chuàng)建一個(gè)新版本的 pod，最終直到滾動(dòng)升級(jí) ok

我們還是進(jìn)入到任意容器內(nèi)，訪問(wèn) SVC ，查看效果如何

可以看到，正常訪問(wèn)到的 SVC ，響應(yīng)的 v2 版本，再次說(shuō)明咱們升級(jí)是成功的

整個(gè)過(guò)程中，我們沒(méi)有手動(dòng)設(shè)置過(guò) Deployment 的升級(jí)策略，前面有說(shuō)到過(guò)默認(rèn)是?RollingUpdate?，我們可以查看一下咱創(chuàng)建的 deploy 的詳情

整個(gè)升級(jí)過(guò)程中，我們就執(zhí)行了一條 deploy 升級(jí)命令，是不是超級(jí)簡(jiǎn)單，不需要自己手動(dòng)去增刪 RS，也不需要去修改 Service 管控的標(biāo)簽， Deployment 一鍵幫助我們完成，是不是很高效

說(shuō)一說(shuō)回滾

咱們不僅只會(huì)升級(jí)，若升級(jí)的程序有啥問(wèn)題，那么豈不是還需要再次升級(jí)一個(gè)舊的版本？

如何升級(jí)呢？還是和剛才升級(jí)的方式一致嗎？當(dāng)然不是

咱們升級(jí)那么簡(jiǎn)單，回滾也是可以那么簡(jiǎn)單

回滾的話，我們可以直接執(zhí)行：

kubectl?rollout?undo?deploy?newkubia

查看?deploy?執(zhí)行過(guò)程狀態(tài)
kubectl?rollout?status?deploy?newkubia


回滾成功，我們來(lái)檢查一下 ?rs ?和 pod ，這里可以注意下 pod 的名字和 RS 的名字的特征

那么如何指定版本回滾呢？

指定版本回滾也是可以滴，咱們可以通過(guò)如下指令查看 deploy 管理升級(jí)記錄（有升級(jí)記錄，是因?yàn)槲覀冏铋_(kāi)始創(chuàng)建 deploy 的時(shí)候，指定了?--record）

kubectl?rollout?history?deploy?newkubia


指定版本回滾

kubectl?rollout?undo?deploy?newkubia?--to-revision=xx


指定版本回滾也是回滾成功了，這里我們可以繼續(xù)和上述方式一樣檢查 rs 和 pod 的特征，然后再 進(jìn)入到 pod 中，訪問(wèn) Service 的地址，看看效果是否是我們期望的

看到這里，會(huì)不會(huì)有這些疑問(wèn)呢？

• 為什么我們升級(jí) v2 版本之后 之前的 RS 還在？

• 為什么 deploy 會(huì)有升級(jí)記錄？

這里來(lái)統(tǒng)一分享一下理解：

deploy 會(huì)有升級(jí)記錄，是因?yàn)槲覀冊(cè)趧?chuàng)建 deploy 的時(shí)候，指定了?--record，因此 deploy 在升級(jí)版本的時(shí)候會(huì)記錄信息

升級(jí)新的版本之后，就的 RS 還在，這個(gè)就不難理解了，這個(gè)是為了我們回滾或者跳轉(zhuǎn)到指定版本的時(shí)候，能夠直接使用原有的 RS，底層去修改副本數(shù)就可以了

整個(gè)過(guò)程的管理方式是這樣的：

deploy 管理多個(gè) RS，RS 管理多個(gè) pod

deploy 管理多個(gè)版本 RS ，我們可以理解為是這樣的：

一開(kāi)始 deploy 管理著 1 個(gè) RS1，RS1 管理著多個(gè) pod：v1

當(dāng)我們進(jìn)行升級(jí) v2 版本的時(shí)候，deploy 便會(huì)創(chuàng)建 RS2，并且 RS2 管理著 Pod：v2，RS1 仍然繼續(xù)保留

當(dāng)我們進(jìn)行回滾的時(shí)候，也是類(lèi)似的，但是不會(huì)創(chuàng)建新的 RS，會(huì)直接使用我們要回滾的版本對(duì)應(yīng)的 RS，例如回滾到 v1 版本

今天就到這里，學(xué)習(xí)所得，若有偏差，還請(qǐng)斧正

歡迎點(diǎn)贊，關(guān)注，收藏

朋友們，你的支持和鼓勵(lì)，是我堅(jiān)持分享，提高質(zhì)量的動(dòng)力

好了，本次就到這里

技術(shù)是開(kāi)放的，我們的心態(tài)，更應(yīng)是開(kāi)放的。擁抱變化，向陽(yáng)而生，努力向前行。

我是阿兵云原生，歡迎點(diǎn)贊關(guān)注收藏，下次見(jiàn)~