Kubernetes 實(shí)現(xiàn)灰度和藍(lán)綠發(fā)布

1Kubernetes 中的部署策略

在本文^[1]中，我們將學(xué)習(xí)使用 Kubernetes 容器編排系統(tǒng)部署容器時(shí)的部署策略。在本文的最后，我們將學(xué)習(xí)如何在 Kubernetes 集群中使用不同的方式進(jìn)行部署。如果您覺得這個(gè)話題很有趣，請(qǐng)繼續(xù)閱讀！本教程的代碼可在 Github上找到^[2]

2Kubernetes 快速介紹

容器化隨著時(shí)間的推移越來越流行，并徹底改變了構(gòu)建、傳輸和維護(hù)應(yīng)用程序的過程，因此需要有效地管理這些容器。引入了許多容器編排工具來管理這些容器在大型系統(tǒng)中的生命周期。

Kubernetes 就是這樣一種編排工具，它負(fù)責(zé)配置和部署、資源分配、負(fù)載平衡、服務(wù)發(fā)現(xiàn)、提供高可用性以及任何系統(tǒng)的其他重要方面。有了這個(gè)平臺(tái)，我們可以在開發(fā)的同時(shí)將我們的應(yīng)用程序分解成更小的系統(tǒng)（稱為微服務(wù)）；然后，我們可以在部署時(shí)組合（或編排）這些系統(tǒng)。

云原生方法的采用增加了基于微服務(wù)架構(gòu)的應(yīng)用程序的開發(fā)。對(duì)于此類應(yīng)用程序，組織面臨的最大挑戰(zhàn)之一是部署。在部署方面有一個(gè)適當(dāng)?shù)牟呗允潜匾摹Ｔ?Kubernetes 中，有多種發(fā)布應(yīng)用程序的方式；在應(yīng)用程序部署或更新期間，有必要選擇正確的策略來使您的基礎(chǔ)設(shè)施可靠。例如，在生產(chǎn)環(huán)境中，始終需要確保最終用戶不會(huì)遇到任何停機(jī)時(shí)間。在 Kubernetes 編排中，正確的策略確保正確管理不同版本的容器鏡像。綜上所述，本文將主要圍繞Kubernetes中的不同部署策略展開。

3先決條件

為了繼續(xù)閱讀本文，我們需要一些之前使用 Kubernetes 的經(jīng)驗(yàn)。如果不熟悉此平臺(tái)，請(qǐng)查看基本 Kubernetes 概念^[3]教程的分步介紹^[4]。在那里，您可以按照此處的說明學(xué)習(xí)所需的一切。如果需要，我們還建議您閱讀Kubernetes 文檔^[5]。

除此之外，我們還需要 kubectl，這是一個(gè)命令行界面 (CLI) 工具，使我們能夠從終端控制您的集群。如果您沒有此工具，請(qǐng)查看安裝 Kube Control (kubectl) 中的說明。我們還需要對(duì) Linux 和 YAML 有基本的了解。

4Kubernetes 中的部署是什么？

Deployment 是 Kubernetes 中的一個(gè)資源對(duì)象，它為我們的程序定義了所需的狀態(tài)。部署是聲明性的，這意味著我們不規(guī)定如何實(shí)現(xiàn)狀態(tài)。相反，我們聲明所需的狀態(tài)并允許deployment控制器以最有效的方式自動(dòng)達(dá)到最終目標(biāo)。deployment允許我們描述應(yīng)用程序的生命周期，例如應(yīng)用程序使用哪些Image，應(yīng)該有多少 pod，以及應(yīng)該更新它們的方式。

5使用 Kubernetes 部署的好處

手動(dòng)更新容器化應(yīng)用程序的過程可能既耗時(shí)又乏味。Kubernetes deployment使此過程自動(dòng)化且可重復(fù)。部署完全由 Kubernetes 后端管理，整個(gè)更新過程在服務(wù)器端執(zhí)行，無需客戶端交互。

此外，Kubernetes deployment controller始終監(jiān)控 Pod 和節(jié)點(diǎn)的健康狀況。它可以替換出現(xiàn)故障的 pod以及跳過故障的節(jié)點(diǎn)，確保關(guān)鍵應(yīng)用程序的連續(xù)性。

6部署策略

滾動(dòng)更新部署Rolling Update

滾動(dòng)部署是 Kubernetes 中的默認(rèn)部署策略。它用新版本的 pod 一個(gè)一個(gè)地替換我們應(yīng)用程序的先前版本的 pod，而沒有任何集群停機(jī)時(shí)間。滾動(dòng)部署緩慢地用新版本應(yīng)用程序的實(shí)例替換之前版本的應(yīng)用程序?qū)嵗?/span>

使用 RollingUpdate 策略時(shí)，還有兩個(gè)選項(xiàng)可以讓我們微調(diào)更新過程：

1. maxSurge：更新期間可以創(chuàng)建的 pod 數(shù)量超過所需的 pod 數(shù)量。這可以是副本計(jì)數(shù)的絕對(duì)數(shù)量或百分比。默認(rèn)值為 25%。
2. maxUnavailable：更新過程中可能不可用的 Pod 數(shù)。這可以是副本計(jì)數(shù)的絕對(duì)數(shù)量或百分比；默認(rèn)值為 25%。

首先，我們創(chuàng)建rollingupdate.yaml部署模板。在下面的模板中，我們將maxSurge設(shè)置為 2，將maxUnavailable 設(shè)置為 1。

apiVersion:?apps/v1
kind:?Deployment
metadata:
??name:?rollingupdate-strategy
??version:?nanoserver-1709
spec:
??strategy:
????type:?RollingUpdate
????rollingUpdate:
??????maxSurge:?2
??????maxUnavailable:?1
??selector:
????matchLabels:
??????app:?web-app-rollingupdate-strategy
??????version:?nanoserver-1709
??replicas:?3
??template:
????metadata:
??????labels:
????????app:?web-app-rollingupdate-strategy
????????version:?nanoserver-1709
????spec:
??????containers:
????????-?name:?web-app-rollingupdate-strategy
??????????image:?hello-world:nanoserver-1709

然后我們可以使用 kubectl 命令創(chuàng)建部署。

$?kubectl?apply?-f?rollingupdate.yaml

一旦我們有了deployments模板，我們就可以通過創(chuàng)建服務(wù)來提供一種訪問部署實(shí)例的方法。請(qǐng)注意，我們正在使用版本nanoserver-1709部署映像hello-world。因此，在這種情況下，我們有兩個(gè)label，name= web-app-rollingupdate-strategy和version= nanoserver-1709。我們將這些設(shè)置為下面服務(wù)的標(biāo)簽選擇器。將此保存到“ service.yaml ”文件。

apiVersion:?v1
kind:?Service
metadata:?
??name:?web-app-rollingupdate-strategy
??labels:?
????name:?web-app-rollingupdate-strategy
????version:?nanoserver-1709
spec:
??ports:
????-?name:?http
??????port:?80
??????targetPort:?80
??selector:?
????name:?web-app-rollingupdate-strategy
????version:?nanoserver-1709
??type:?LoadBalancer

現(xiàn)在創(chuàng)建服務(wù),將創(chuàng)建一個(gè)可在集群外訪問的負(fù)載均衡器。

$?kubectl?apply?-f?service.yaml

運(yùn)行kubectl get deployments檢查是否創(chuàng)建了 Deployment。如果 Deployment 仍在創(chuàng)建中，則輸出應(yīng)類似于以下內(nèi)容：

$?kubectl?get?deployments

NAME?????????????????????????????READY???UP-TO-DATE???AVAILABLE???AGE
rollingupdate-strategy???0/3?????0????????????0???????????1s

如果我們幾秒鐘后再次運(yùn)行kubectl get 部署。輸出應(yīng)與此類似：

$?kubectl?get?deployments

NAME?????????????????????????????READY???UP-TO-DATE???AVAILABLE???AGE
rollingupdate-strategy???3/3?????0????????????0???????????7s

要查看 Deployment 創(chuàng)建的 ReplicaSet (rs)，請(qǐng)運(yùn)行kubectl get rs。輸出應(yīng)與此類似：

$?kubectl?get?rs

NAME????????????????????????????????????DESIRED???CURRENT???READY???AGE
rollingupdate-strategy-87875f5897???3?????????3?????????3???????18s

要查看為部署運(yùn)行的 3 個(gè) pod，請(qǐng)運(yùn)行kubectl get pods。創(chuàng)建的 ReplicaSet 確保有三個(gè) Pod 在運(yùn)行。輸出應(yīng)類似于以下內(nèi)容。

$?kubectl?get?pods

NAME??????????????????????????????????????READY?????STATUS????RESTARTS???AGE???????
rollingupdate-strategy-87875f5897-55i7o???1/1???????Running???0??????????12s???????
rollingupdate-strategy-87875f5897-abszs???1/1???????Running???0??????????12s???????
rollingupdate-strategy-87875f5897-qazrt???1/1???????Running???0??????????12s

讓我們更新rollingupdate.yaml部署模板以使用hello-world:nanoserver-1809鏡像而不是hello-world:nanoserver-1709鏡像。然后使用 kubectl 命令更新現(xiàn)有運(yùn)行部署的鏡像。

$?kubectl?set?image?deployment/rollingupdate-strategy?web-app-rollingupdate-strategy=hello-world:nanoserver-1809?--record

輸出類似于以下內(nèi)容。

deployment.apps/rollingupdate-strategy?image?updated

我們現(xiàn)在正在使用版本nanoserver-1809部署映像hello-world。因此，在這種情況下，我們將不得不更新“service.yaml”中的標(biāo)簽。標(biāo)簽將更新為“version= nanoserver-1809 ”。我們將再次運(yùn)行以下 kubectl 命令來更新服務(wù)，以便它可以選擇在新鏡像上運(yùn)行的新 pod。

$?kubectl?apply?-f?service.yaml

要查看deployment的狀態(tài)，請(qǐng)運(yùn)行下面的 kubectl 命令。

$?kubectl?rollout?status?deployment/rollingupdate-strategy

Waiting?for?rollout?to?finish:?2?out?of?3?new?replicas?have?been?updated...

再次運(yùn)行以驗(yàn)證部署是否成功。

$?kubectl?rollout?status?deployment/rollingupdate-strategy

deployment?"rollingupdate-strategy"?successfully?rolled?out

部署成功后，我們可以通過運(yùn)行命令kubectl get deployments來查看 Deployment 。輸出類似于：

$?kubectl?get?deployments

NAME?????????????????????????????READY???UP-TO-DATE???AVAILABLE???AGE
rollingupdate-strategy???3/3?????0????????????0???????????7s

運(yùn)行kubectl get rs以查看 Deployment 是否已更新。新的 Pod 在一個(gè)新的 ReplicaSet 中創(chuàng)建并擴(kuò)展到 3 個(gè)副本。舊的 ReplicaSet 縮減為 0 個(gè)副本。

$?kubectl?get?rs

NAME????????????????????????????????????DESIRED???CURRENT???READY???AGE
rollingupdate-strategy-87875f5897???3?????????3?????????3???????55s
rollingupdate-strategy-89999f7895???0?????????0?????????0???????12s

運(yùn)行kubectl get pods它現(xiàn)在應(yīng)該只顯示新 ReplicaSet 中的新 Pod。

$?kubectl?get?pods

NAME??????????????????????????????????????READY?????STATUS????RESTARTS???AGE???????
rollingupdate-strategy-89999f7895-55i7o???1/1???????Running???0??????????12s???????
rollingupdate-strategy-89999f7895-abszs???1/1???????Running???0??????????12s???????
rollingupdate-strategy-89999f7895-qazrt???1/1???????Running???0??????????12s

kubectl 的 rollout 命令在這里非常有用。我們可以用它來檢查我們的部署是如何進(jìn)行的。默認(rèn)情況下，該命令會(huì)等待部署中的所有 Pod 成功啟動(dòng)。當(dāng)部署成功時(shí)，命令退出并返回代碼為零以表示成功。如果部署失敗，該命令將以非零代碼退出。

$?kubectl?rollout?status?deployment?rollingupdate-strategy

Waiting?for?deployment?"rollingupdate-strategy"?rollout?to?finish:?0?of?3?updated?replicas?are?available…
Waiting?for?deployment?"rollingupdate-strategy"?rollout?to?finish:?1?of?3?updated?replicas?are?available…
Waiting?for?deployment?"rollingupdate-strategy"?rollout?to?finish:?2?of?3?updated?replicas?are?available…

deployment?"rollingupdate-strategy"?successfully?rolled?out

如果在 Kubernetes 中部署失敗，部署過程會(huì)停止，但失敗部署中的 pod 會(huì)保留下來。在部署失敗時(shí)，我們的環(huán)境可能包含來自舊部署和新部署的 pod。為了恢復(fù)到穩(wěn)定的工作狀態(tài)，我們可以使用 rollout undo 命令來恢復(fù)工作 pod 并清理失敗的部署。

$?kubectl?rollout?undo?deployment?rollingupdate-strategy

deployment.extensions/rollingupdate-strategy

然后我們將再次驗(yàn)證部署的狀態(tài)。

$?kubectl?rollout?status?deployment?rollingupdate-strategy

deployment?"rollingupdate-strategy"?successfully?rolled?out

為了讓 Kubernetes 知道應(yīng)用程序何時(shí)準(zhǔn)備就緒，它需要應(yīng)用程序的一些幫助。Kubernetes 使用就緒探針來檢查應(yīng)用程序的運(yùn)行情況。一旦應(yīng)用程序?qū)嵗_始以肯定響應(yīng)響應(yīng)就緒探測(cè)，該實(shí)例就被認(rèn)為可以使用了。就緒探針會(huì)告訴 Kubernetes 應(yīng)用程序何時(shí)準(zhǔn)備就緒，但不會(huì)告訴 Kubernetes 應(yīng)用程序是否準(zhǔn)備就緒。如果應(yīng)用程序不斷失敗，它可能永遠(yuǎn)不會(huì)對(duì) Kubernetes 做出積極響應(yīng)。

滾動(dòng)部署通常會(huì)在縮小舊組件之前通過就緒檢查等待新 Pod 準(zhǔn)備就緒。如果發(fā)生重大問題，可以中止?jié)L動(dòng)部署。如果出現(xiàn)問題，可以中止?jié)L動(dòng)更新或部署，而無需關(guān)閉整個(gè)集群。

重新創(chuàng)建部署

在重新創(chuàng)建部署中，我們?cè)跀U(kuò)展新應(yīng)用程序版本之前完全縮減現(xiàn)有應(yīng)用程序版本。在下圖中，版本 1 表示當(dāng)前應(yīng)用程序版本，版本 2 表示新應(yīng)用程序版本。在更新當(dāng)前應(yīng)用程序版本時(shí)，我們首先將版本 1 的現(xiàn)有副本縮減為零，然后與新版本并發(fā)部署副本。

下面的模板顯示了使用重新創(chuàng)建策略的部署：首先，我們通過將以下 yaml 保存到文件 recreate.yaml 來創(chuàng)建我們的重新創(chuàng)建部署

apiVersion:?apps/v1
kind:?Deployment
metadata:
??name:?recreate-strategy
spec:
??strategy:
????type:?Recreate
??selector:
????matchLabels:
??????app:?web-app-recreate-strategy
??????version:?nanoserver-1809
??replicas:?3
??template:
????metadata:
??????labels:
????????app:?web-app-recreate-strategy
????spec:
??????containers:
????????-?name:?web-app-recreate-strategy
??????????image:?hello-world:nanoserver-1809

然后我們可以使用 kubectl 命令創(chuàng)建部署。

$?kubectl?apply?-f?recreate.yaml

一旦我們有了部署模板，我們就可以通過創(chuàng)建服務(wù)來提供一種訪問部署實(shí)例的方法。請(qǐng)注意，我們正在使用版本nanoserver-1809部署映像hello-world。所以在這種情況下，我們有兩個(gè)標(biāo)簽，“name= web-app-recreate-strategy ”和“version= nanoserver-1809 ”。我們將這些設(shè)置為下面服務(wù)的標(biāo)簽選擇器。將其保存到service.yaml文件中。

apiVersion:?v1
kind:?Service
metadata:?
??name:?web-app-recreate-strategy
??labels:?
????name:?web-app-recreate-strategy
????version:?nanoserver-1809
spec:
??ports:
????-?name:?http
??????port:?80
??????targetPort:?80
??selector:?
????name:?web-app-recreate-strategy
????version:?nanoserver-1809
??type:?LoadBalancer

現(xiàn)在創(chuàng)建服務(wù)將創(chuàng)建一個(gè)可在集群外訪問的負(fù)載均衡器。

$?kubectl?apply?-f?service.yaml

重新創(chuàng)建方法在更新過程中涉及一些停機(jī)時(shí)間。對(duì)于可以處理維護(hù)窗口或中斷的應(yīng)用程序，停機(jī)時(shí)間不是問題。但是，如果存在具有高服務(wù)級(jí)別協(xié)議 (SLA) 和可用性要求的關(guān)鍵任務(wù)應(yīng)用程序，則選擇不同的部署策略將是正確的方法。Recreate 部署一般用于開發(fā)者的開發(fā)階段，因?yàn)樗子谠O(shè)置，并且應(yīng)用程序狀態(tài)會(huì)隨著新版本完全更新。此外，我們不必并行管理多個(gè)應(yīng)用程序版本，因此我們避免了數(shù)據(jù)和應(yīng)用程序的向后兼容性挑戰(zhàn)。

藍(lán)綠部署

在藍(lán)/綠部署策略（有時(shí)也稱為紅/黑）中，藍(lán)色代表當(dāng)前應(yīng)用版本，綠色代表新應(yīng)用版本。在這種情況下，一次只有一個(gè)版本處于活動(dòng)狀態(tài)。在創(chuàng)建和測(cè)試綠色部署時(shí)，流量被路由到藍(lán)色部署。完成測(cè)試后，我們將流量路由到新版本。

部署成功后，我們可以保留藍(lán)色部署以備回滾或者回退。或者，可以在這些實(shí)例上部署較新版本的應(yīng)用程序。在這種情況下，當(dāng)前（藍(lán)色）環(huán)境用作下一個(gè)版本的暫存區(qū)。

這種技術(shù)可以消除我們?cè)谥匦聞?chuàng)建部署策略中遇到的停機(jī)時(shí)間。此外，藍(lán)綠部署降低了風(fēng)險(xiǎn)：如果我們?cè)?Green 上的新版本發(fā)生意外，我們可以通過切換回 Blue 立即回滾到上一個(gè)版本。我們還可以避免版本問題；整個(gè)應(yīng)用程序狀態(tài)在一次部署中更改。

藍(lán)綠部署成本高昂，因?yàn)樗枰p倍的資源。在將其發(fā)布到生產(chǎn)環(huán)境之前，應(yīng)對(duì)整個(gè)平臺(tái)進(jìn)行適當(dāng)?shù)臏y(cè)試。此外，處理有狀態(tài)的應(yīng)用程序很困難。

首先，我們通過將以下 yaml 保存到“blue.yaml”文件來創(chuàng)建藍(lán)色部署：

apiVersion:?apps/v1
kind:?Deployment
metadata:
??name:?blue-deployment
spec:
??selector:
????matchLabels:
??????app:?blue-deployment
??????version:?nanoserver-1709
??replicas:?3
??template:
????metadata:
??????labels:
????????app:?blue-deployment
????????version:?nanoserver-1709
????spec:
??????containers:
????????-?name:?blue-deployment
??????????image:?hello-world:nanoserver-1709

然后我們可以使用 kubectl 命令創(chuàng)建部署。

$?kubectl?apply?-f?blue.yaml

一旦我們有了部署模板，我們就可以通過創(chuàng)建服務(wù)來提供一種訪問部署實(shí)例的方法。請(qǐng)注意，我們正在使用版本nanoserver-1809部署映像hello-world。所以在這種情況下，我們有兩個(gè)標(biāo)簽，“name= blue-deployment ”和“version= nanoserver-1709 ”。我們將這些設(shè)置為下面服務(wù)的標(biāo)簽選擇器。將其保存到service.yaml文件中。

Gitlab+Jenkins+k8s+Helm 的自動(dòng)化部署實(shí)踐

apiVersion:?v1
kind:?Service
metadata:?
??name:?blue-green-service
??labels:?
????name:?blue-deployment
????version:?nanoserver-1709
spec:
??ports:
????-?name:?http
??????port:?80
??????targetPort:?80
??selector:?
????name:?blue-deployment
????version:?nanoserver-1709
??type:?LoadBalancer

現(xiàn)在創(chuàng)建服務(wù)將創(chuàng)建一個(gè)可在集群外訪問的負(fù)載均衡器。

$?kubectl?apply?-f?service.yaml

我們現(xiàn)在有以下設(shè)置。

對(duì)于綠色部署，我們將在藍(lán)色部署的同時(shí)部署一個(gè)新部署。下面的模板是文件的內(nèi)容：green.yaml

apiVersion:?apps/v1
kind:?Deployment
metadata:
??name:?green-deployment
spec:
??selector:
????matchLabels:
??????app:?green-deployment
??????version:?nanoserver-1809
??replicas:?3
??template:
????metadata:
??????labels:
????????app:?green-deployment
????????version:?nanoserver-1809
????spec:
??????containers:
????????-?name:?green-deployment
??????????image:?hello-world:nanoserver-1809

請(qǐng)注意，鏡像hello-world:nanoserver-1809標(biāo)記名稱已更改為 2。因此我們使用兩個(gè)標(biāo)簽進(jìn)行了單獨(dú)部署，名稱= green-deployment和 version= nanoserver-1809。

$?kubectl?apply?-f?green.yaml

為了切換到綠色部署，我們將更新現(xiàn)有服務(wù)的選擇器。編輯 service.yaml 并將選擇器版本更改為2并將名稱更改為green-deployemnt。這將使它與綠色“部署”上的 pod 相匹配。

apiVersion:?v1
kind:?Service
metadata:?
??name:?blue-green-service
??labels:?
????name:?green-deployment
????version:?nanoserver-1809
spec:
??ports:
????-?name:?http
??????port:?80
??????targetPort:?80
??selector:?
????name:?green-deployment
????version:?nanoserver-1809
??type:?LoadBalancer

我們使用 kubectl 命令再次創(chuàng)建服務(wù)：

$?kubectl?apply?-f?service.yaml

因此得出結(jié)論，我們可以看到藍(lán)綠部署是全有或全無，不像滾動(dòng)更新部署，我們無法逐步推出新版本。所有用戶將同時(shí)收到更新，但允許現(xiàn)有會(huì)話在舊實(shí)例上完成他們的工作。因此，一旦我們啟動(dòng)更改，風(fēng)險(xiǎn)就比一切都應(yīng)該工作的要高一些。它還需要分配更多的服務(wù)器資源，因?yàn)槲覀冃枰\(yùn)行每個(gè) Pod 的兩個(gè)副本。

幸運(yùn)的是，回滾過程同樣簡(jiǎn)單：我們只需再次撥動(dòng)開關(guān)，先前的版本就被換回原位。那是因?yàn)榕f版本仍在舊 Pod 上運(yùn)行。只是流量不再被路由到他們。當(dāng)我們確信新版本會(huì)繼續(xù)存在時(shí)，我們應(yīng)該停用這些 pod。

金絲雀部署

Canary 更新策略是一個(gè)部分更新過程，它允許我們?cè)谡鎸?shí)用戶群上測(cè)試我們的新程序版本，而無需承諾全面推出。類似于藍(lán)/綠部署，但它們更受控制，并且它們使用更漸進(jìn)的交付方式，其中部署是分階段進(jìn)行的。有許多策略屬于金絲雀的保護(hù)傘，包括暗發(fā)布或 A/B 測(cè)試。

在金絲雀部署中，新版本的應(yīng)用程序逐漸部署到Kubernetes集群，同時(shí)獲得極少量的實(shí)時(shí)流量（即，一部分實(shí)時(shí)用戶正在連接到新版本，而其余的仍在使用以前的版本） .在這種方法中，我們有兩個(gè)幾乎相同的服務(wù)器：一個(gè)用于所有當(dāng)前活躍用戶，另一個(gè)帶有新功能，用于向一部分用戶推出然后進(jìn)行比較。當(dāng)沒有錯(cuò)誤報(bào)告并且信心增加時(shí)，新版本可以逐漸推廣到基礎(chǔ)架構(gòu)的其余部分。最后，所有實(shí)時(shí)流量都流向金絲雀，使金絲雀版本成為新的生產(chǎn)版本。

下圖顯示了進(jìn)行金絲雀部署的最直接和最簡(jiǎn)單的方法。新版本部署到服務(wù)器的子集。

在發(fā)生這種情況時(shí)，我們會(huì)觀察升級(jí)后的機(jī)器的運(yùn)行情況。我們檢查錯(cuò)誤和性能問題，并聽取用戶反饋。隨著我們對(duì)金絲雀越來越有信心，我們繼續(xù)在其余機(jī)器上安裝它，直到它們都運(yùn)行最新版本。

在規(guī)劃金絲雀部署時(shí)，我們必須考慮各種因素：

1. 階段：我們將首先向金絲雀發(fā)送多少用戶，以及在多少階段。
2. 持續(xù)時(shí)間：我們計(jì)劃運(yùn)行金絲雀多久？Canary 版本不同，因?yàn)槲覀儽仨毜却銐蚨嗟目蛻舳烁虏拍茉u(píng)估結(jié)果。這可能會(huì)在幾天甚至幾周內(nèi)發(fā)生。
3. 指標(biāo)：記錄哪些指標(biāo)以分析進(jìn)度，包括應(yīng)用程序性能和錯(cuò)誤報(bào)告？精心選擇的參數(shù)對(duì)于成功部署 Canary 至關(guān)重要。例如，衡量部署的一種非常簡(jiǎn)單的方法是通過 HTTP 狀態(tài)代碼。我們可以有一個(gè)簡(jiǎn)單的 ping 服務(wù)，當(dāng)部署成功時(shí)返回 200。如果部署中存在問題，它將返回服務(wù)器端錯(cuò)誤 (5xx)。
4. 評(píng)估：我們將使用什么標(biāo)準(zhǔn)來確定金絲雀是否成功

Canary 用于我們必須在應(yīng)用程序后端測(cè)試新功能的場(chǎng)景。當(dāng)我們對(duì)新版本不是 100% 有信心時(shí)，應(yīng)該使用 Canary 部署；我們預(yù)測(cè)我們失敗的可能性很小。當(dāng)我們進(jìn)行重大更新時(shí)，通常會(huì)使用此策略，例如添加新功能或?qū)嶒?yàn)性功能。

7K8s 部署策略總結(jié)

總而言之，部署應(yīng)用程序有多種不同的方式；當(dāng)發(fā)布到開發(fā)/暫存環(huán)境時(shí)，重新創(chuàng)建或升級(jí)部署通常是一個(gè)不錯(cuò)的選擇。在生產(chǎn)方面，藍(lán)/綠部署通常很合適，但需要對(duì)新平臺(tái)進(jìn)行適當(dāng)?shù)臏y(cè)試。如果我們對(duì)平臺(tái)的穩(wěn)定性以及發(fā)布新軟件版本可能產(chǎn)生的影響沒有信心，那么金絲雀版本應(yīng)該是我們要走的路。通過這樣做，我們讓消費(fèi)者測(cè)試應(yīng)用程序及其與平臺(tái)的集成。在本文中，我們只觸及了 Kubernetes 部署功能的皮毛。通過將部署與所有其他 Kubernetes 功能相結(jié)合，用戶可以創(chuàng)建更強(qiáng)大的容器化應(yīng)用程序以滿足任何需求。

?推薦閱讀?
31天拿下Kubernetes含金量最高的CKA+CKS證書！
作業(yè)幫 | Kubernetes 原生調(diào)度器優(yōu)化實(shí)踐
這6個(gè) Linux 命令，每個(gè)都很炫酷！
Gitlab+Jenkins+k8s+Helm 的自動(dòng)化部署實(shí)踐
一名運(yùn)維小哥對(duì)運(yùn)維規(guī)則的10個(gè)總結(jié)，收藏起來
終于明白了 DevOps 與 SRE 的區(qū)別！
Kubernetes上生產(chǎn)環(huán)境后，99%都會(huì)遇到這2個(gè)故障
K8s kubectl 常用命令總結(jié)（建議收藏）
Kubernetes 的這些核心資源原理，你一定要了解
我在創(chuàng)業(yè)公司的 “云原生” 之旅
基于Nginx實(shí)現(xiàn)灰度發(fā)布與AB測(cè)試
編寫 Dockerfile 最佳實(shí)踐
12年資深運(yùn)維老司機(jī)的成長(zhǎng)感悟
搭建一套完整的企業(yè)級(jí) K8s 集群（二進(jìn)制方式）


點(diǎn)亮，服務(wù)器三年不宕機(jī)