1. Kubernetes 中的部署策略

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

2. Kubernetes 快速介紹

容器化隨著時(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ā)。對于此類應(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)，請查看基本 Kubernetes 概念教程的分步介紹。在那里，您可以按照此處的說明學(xué)習(xí)所需的一切。如果需要，我們還建議您閱讀Kubernetes 文檔。

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

4. Kubernetes 中的部署是什么？

Deployment 是 Kubernetes 中的一個(gè)資源對象，它為我們的程序定義了所需的狀態(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ū)嵗?/p>

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

1.  maxSurge：更新期間可以創(chuàng)建的 pod 數(shù)量超過所需的 pod 數(shù)量。這可以是副本計(jì)數(shù)的絕對數(shù)量或百分比。默認(rèn)值為 25%。
2.  maxUnavailable：更新過程中可能不可用的 Pod 數(shù)。這可以是副本計(jì)數(shù)的絕對數(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í)例的方法。請注意，我們正在使用版本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)，請運(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，請運(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)，請運(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)就緒探測，該實(shí)例就被認(rèn)為可以使用了。就緒探針會(huì)告訴 Kubernetes 應(yīng)用程序何時(shí)準(zhǔn)備就緒，但不會(huì)告訴 Kubernetes 應(yīng)用程序是否準(zhǔn)備就緒。如果應(yīng)用程序不斷失敗，它可能永遠(yuǎn)不會(huì)對 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)建部署中，我們在擴(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í)例的方法。請注意，我們正在使用版本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í)間。對于可以處理維護(hù)窗口或中斷的應(yīng)用程序，停機(jī)時(shí)間不是問題。但是，如果存在具有高服務(wù)級別協(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)建和測試綠色部署時(shí)，流量被路由到藍(lán)色部署。完成測試后，我們將流量路由到新版本。

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

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

藍(lán)綠部署成本高昂，因?yàn)樗枰p倍的資源。在將其發(fā)布到生產(chǎn)環(huán)境之前，應(yīng)對整個(gè)平臺(tái)進(jìn)行適當(dāng)?shù)臏y試。此外，處理有狀態(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í)例的方法。請注意，我們正在使用版本nanoserver-1809部署映像hello-world。所以在這種情況下，我們有兩個(gè)標(biāo)簽，“name= blue-deployment ”和“ version= nanoserver-1709 ”。我們將這些設(shè)置為下面服務(wù)的標(biāo)簽選擇器。將其保存到service.yaml文件中。 

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è)置。

對于綠色部署，我們將在_藍(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   

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

金絲雀部署

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

在金絲雀部署中，新版本的應(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)行金絲雀部署的最直接和最簡單的方法。新版本部署到服務(wù)器的子集。

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

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

    1. 階段：我們將首先向金絲雀發(fā)送多少用戶，以及在多少階段。

    2. 持續(xù)時(shí)間：我們計(jì)劃運(yùn)行金絲雀多久？Canary 版本不同，因?yàn)槲覀儽仨毜却銐蚨嗟目蛻舳烁虏拍茉u估結(jié)果。這可能會(huì)在幾天甚至幾周內(nèi)發(fā)生。

    3. 指標(biāo)：記錄哪些指標(biāo)以分析進(jìn)度，包括應(yīng)用程序性能和錯(cuò)誤報(bào)告？精心選擇的參數(shù)對于成功部署 Canary 至關(guān)重要。例如，衡量部署的一種非常簡單的方法是通過 HTTP 狀態(tài)代碼。我們可以有一個(gè)簡單的 ping 服務(wù)，當(dāng)部署成功時(shí)返回 200。如果部署中存在問題，它將返回服務(wù)器端錯(cuò)誤 (5xx)。

    4. 評估：我們將使用什么標(biāo)準(zhǔn)來確定金絲雀是否成功

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

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

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