Kubernetes 實現灰度和藍綠發布
1. Kubernetes 中的部署策略
在本文中，我們將學習使用 Kubernetes 容器編排系統部署容器時的部署策略。在本文的最后，我們將學習如何在 Kubernetes 集群中使用不同的方式進行部署。如果您覺得這個話題很有趣，請繼續閱讀！本教程的代碼可在 Github上找到。
2. Kubernetes 快速介紹
容器化隨著時間的推移越來越流行，并徹底改變了構建、傳輸和維護應用程序的過程，因此需要有效地管理這些容器。引入了許多容器編排工具來管理這些容器在大型系統中的生命周期。
Kubernetes 就是這樣一種編排工具，它負責配置和部署、資源分配、負載平衡、服務發現、提供高可用性以及任何系統的其他重要方面。有了這個平臺，我們可以在開發的同時將我們的應用程序分解成更小的系統（稱為微服務）；然后，我們可以在部署時組合（或編排）這些系統。
云原生方法的采用增加了基于微服務架構的應用程序的開發。對于此類應用程序，組織面臨的最大挑戰之一是部署。在部署方面有一個適當的策略是必要的。在 Kubernetes 中，有多種發布應用程序的方式；在應用程序部署或更新期間，有必要選擇正確的策略來使您的基礎設施可靠。例如，在生產環境中，始終需要確保最終用戶不會遇到任何停機時間。在 Kubernetes 編排中，正確的策略確保正確管理不同版本的容器鏡像。綜上所述，本文將主要圍繞Kubernetes中的不同部署策略展開。
3. 先決條件
為了繼續閱讀本文，我們需要一些之前使用 Kubernetes 的經驗。如果不熟悉此平臺，請查看基本 Kubernetes 概念教程的分步介紹。在那里，您可以按照此處的說明學習所需的一切。如果需要，我們還建議您閱讀Kubernetes 文檔。
除此之外，我們還需要 kubectl，這是一個命令行界面 (CLI) 工具，使我們能夠從終端控制您的集群。如果您沒有此工具，請查看安裝 Kube Control (kubectl) 中的說明。我們還需要對 Linux 和 YAML 有基本的了解。
4. Kubernetes 中的部署是什么？
Deployment 是 Kubernetes 中的一個資源對象，它為我們的程序定義了所需的狀態。部署是聲明性的，這意味著我們不規定如何實現狀態。相反，我們聲明所需的狀態并允許deployment控制器以最有效的方式自動達到最終目標。deployment允許我們描述應用程序的生命周期，例如應用程序使用哪些Image，應該有多少 pod，以及應該更新它們的方式。
5. 使用 Kubernetes 部署的好處
手動更新容器化應用程序的過程可能既耗時又乏味。Kubernetes deployment使此過程自動化且可重復。部署完全由 Kubernetes 后端管理，整個更新過程在服務器端執行，無需客戶端交互。
此外，Kubernetes deployment controller始終監控 Pod 和節點的健康狀況。它可以替換出現故障的 pod以及跳過故障的節點，確保關鍵應用程序的連續性。
6. 部署策略
滾動更新部署Rolling Update
滾動部署是 Kubernetes 中的默認部署策略。它用新版本的 pod 一個一個地替換我們應用程序的先前版本的 pod，而沒有任何集群停機時間。滾動部署緩慢地用新版本應用程序的實例替換之前版本的應用程序實例。
使用 RollingUpdate 策略時，還有兩個選項可以讓我們微調更新過程：
- maxSurge：更新期間可以創建的 pod 數量超過所需的 pod 數量。這可以是副本計數的絕對數量或百分比。默認值為 25%。
- maxUnavailable：更新過程中可能不可用的 Pod 數。這可以是副本計數的絕對數量或百分比；默認值為 25%。
首先，我們創建rollingupdate.yaml部署模板。在下面的模板中，我們將maxSurge設置為 2，將maxUnavailable 設置為 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 命令創建部署。
- $ kubectl apply -f rollingupdate.yaml
一旦我們有了deployments模板，我們就可以通過創建服務來提供一種訪問部署實例的方法。請注意，我們正在使用版本nanoserver-1709部署映像hello-world。因此，在這種情況下，我們有兩個label，name= web-app-rollingupdate-strategy和version= nanoserver-1709。我們將這些設置為下面服務的標簽選擇器。將此保存到“ 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
現在創建服務,將創建一個可在集群外訪問的負載均衡器。
- $ kubectl apply -f service.yaml
運行“kubectl get deployments”檢查是否創建了 Deployment。如果 Deployment 仍在創建中，則輸出應類似于以下內容：
- $ kubectl get deployments
- NAME READY UP-TO-DATE AVAILABLE AGE
- rollingupdate-strategy 0/3 0 0 1s
如果我們幾秒鐘后再次運行" kubectl get 部署 "。輸出應與此類似：
- $ kubectl get deployments
- NAME READY UP-TO-DATE AVAILABLE AGE
- rollingupdate-strategy 3/3 0 0 7s
要查看 Deployment 創建的 ReplicaSet (rs)，請運行kubectl get rs。輸出應與此類似：
- $ kubectl get rs
- NAME DESIRED CURRENT READY AGE
- rollingupdate-strategy-87875f5897 3 3 3 18s
要查看為部署運行的 3 個 pod，請運行kubectl get pods。創建的 ReplicaSet 確保有三個 Pod 在運行。輸出應類似于以下內容。
- $ 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 命令更新現有運行部署的鏡像。
- $ kubectl set image deployment/rollingupdate-strategy web-app-rollingupdate-strategy=hello-world:nanoserver-1809 --record
輸出類似于以下內容。
- deployment.apps/rollingupdate-strategy image updated
我們現在正在使用版本nanoserver-1809部署映像hello-world。因此，在這種情況下，我們將不得不更新“service.yaml”中的標簽。標簽將更新為“version= nanoserver-1809 ”。我們將再次運行以下 kubectl 命令來更新服務，以便它可以選擇在新鏡像上運行的新 pod。
- $ kubectl apply -f service.yaml
要查看deployment的狀態，請運行下面的 kubectl 命令。
- $ kubectl rollout status deployment/rollingupdate-strategy
- Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
再次運行以驗證部署是否成功。
- $ kubectl rollout status deployment/rollingupdate-strategy
- deployment "rollingupdate-strategy" successfully rolled out
部署成功后，我們可以通過運行命令kubectl get deployments來查看Deployment。輸出類似于：
- $ kubectl get deployments
- NAME READY UP-TO-DATE AVAILABLE AGE
- rollingupdate-strategy 3/3 0 0 7s
運行kubectl get rs以查看Deployment是否已更新。新的 Pod 在一個新的 ReplicaSet 中創建并擴展到 3 個副本。舊的 ReplicaSet 縮減為 0 個副本。
- $ kubectl get rs
- NAME DESIRED CURRENT READY AGE
- rollingupdate-strategy-87875f5897 3 3 3 55s
- rollingupdate-strategy-89999f7895 0 0 0 12s
運行kubectl get pods它現在應該只顯示新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 命令在這里非常有用。我們可以用它來檢查我們的部署是如何進行的。默認情況下，該命令會等待部署中的所有 Pod 成功啟動。當部署成功時，命令退出并返回代碼為零以表示成功。如果部署失敗，該命令將以非零代碼退出。
- $ 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 中部署失敗，部署過程會停止，但失敗部署中的 pod 會保留下來。在部署失敗時，我們的環境可能包含來自舊部署和新部署的 pod。為了恢復到穩定的工作狀態，我們可以使用 rollout undo 命令來恢復工作 pod 并清理失敗的部署。
- $ kubectl rollout undo deployment rollingupdate-strategy
- deployment.extensions/rollingupdate-strategy
然后我們將再次驗證部署的狀態。
- $ kubectl rollout status deployment rollingupdate-strategy
- deployment "rollingupdate-strategy" successfully rolled out
為了讓 Kubernetes 知道應用程序何時準備就緒，它需要應用程序的一些幫助。Kubernetes 使用就緒探針來檢查應用程序的運行情況。一旦應用程序實例開始以肯定響應響應就緒探測，該實例就被認為可以使用了。就緒探針會告訴 Kubernetes 應用程序何時準備就緒，但不會告訴 Kubernetes 應用程序是否準備就緒。如果應用程序不斷失敗，它可能永遠不會對 Kubernetes 做出積極響應。
滾動部署通常會在縮小舊組件之前通過就緒檢查等待新 Pod 準備就緒。如果發生重大問題，可以中止滾動部署。如果出現問題，可以中止滾動更新或部署，而無需關閉整個集群。
重新創建部署
在重新創建部署中，我們在擴展新應用程序版本之前完全縮減現有應用程序版本。在下圖中，版本 1 表示當前應用程序版本，版本 2 表示新應用程序版本。在更新當前應用程序版本時，我們首先將版本 1 的現有副本縮減為零，然后與新版本并發部署副本。
下面的模板顯示了使用重新創建策略的部署：首先，我們通過將以下 yaml 保存到文件 recreate.yaml 來創建我們的重新創建部署
- 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 命令創建部署。
- $ kubectl apply -f recreate.yaml
一旦我們有了部署模板，我們就可以通過創建服務來提供一種訪問部署實例的方法。請注意，我們正在使用版本nanoserver-1809部署映像hello-world。所以在這種情況下，我們有兩個標簽，“name= web-app-recreate-strategy ”和“version= nanoserver-1809 ”。我們將這些設置為下面服務的標簽選擇器。將其保存到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
現在創建服務將創建一個可在集群外訪問的負載均衡器。
- $ kubectl apply -f service.yaml
重新創建方法在更新過程中涉及一些停機時間。對于可以處理維護窗口或中斷的應用程序，停機時間不是問題。但是，如果存在具有高服務級別協議 (SLA) 和可用性要求的關鍵任務應用程序，則選擇不同的部署策略將是正確的方法。Recreate 部署一般用于開發者的開發階段，因為它易于設置，并且應用程序狀態會隨著新版本完全更新。此外，我們不必并行管理多個應用程序版本，因此我們避免了數據和應用程序的向后兼容性挑戰。
藍綠部署
在藍/綠部署策略（有時也稱為紅/黑）中，藍色代表當前應用版本，綠色代表新應用版本。在這種情況下，一次只有一個版本處于活動狀態。在創建和測試綠色部署時，流量被路由到藍色部署。完成測試后，我們將流量路由到新版本。
部署成功后，我們可以保留藍色部署以備回滾或者回退。或者，可以在這些實例上部署較新版本的應用程序。在這種情況下，當前（藍色）環境用作下一個版本的暫存區。
這種技術可以消除我們在重新創建部署策略中遇到的停機時間。此外，藍綠部署降低了風險：如果我們在 Green 上的新版本發生意外，我們可以通過切換回 Blue 立即回滾到上一個版本。我們還可以避免版本問題；整個應用程序狀態在一次部署中更改。
藍綠部署成本高昂，因為它需要雙倍的資源。在將其發布到生產環境之前，應對整個平臺進行適當的測試。此外，處理有狀態的應用程序很困難。
首先，我們通過將以下 yaml 保存到“blue.yaml”文件來創建藍色部署：
- 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 命令創建部署。
- $ kubectl apply -f blue.yaml
一旦我們有了部署模板，我們就可以通過創建服務來提供一種訪問部署實例的方法。請注意，我們正在使用版本nanoserver-1809部署映像hello-world。所以在這種情況下，我們有兩個標簽，“name= blue-deployment ”和“ version= nanoserver-1709 ”。我們將這些設置為下面服務的標簽選擇器。將其保存到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
現在創建服務將創建一個可在集群外訪問的負載均衡器。
- $ kubectl apply -f service.yaml
我們現在有以下設置。
對于綠色部署，我們將在_藍色_部署的同時部署一個新部署。下面的模板是文件的內容：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標記名稱已更改為 2。因此我們使用兩個標簽進行了單獨部署，名稱= green-deployment和 version= nanoserver-1809。
- $ kubectl apply -f green.yaml
為了切換到_綠色_部署，我們將更新現有服務的選擇器。編輯 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 命令再次創建服務：
- $ kubectl apply -f service.yaml
因此得出結論，我們可以看到藍綠部署是全有或全無，不像滾動更新部署，我們無法逐步推出新版本。所有用戶將同時收到更新，但允許現有會話在舊實例上完成他們的工作。因此，一旦我們啟動更改，風險就比一切都應該工作的要高一些。它還需要分配更多的服務器資源，因為我們需要運行每個 Pod 的兩個副本。
幸運的是，回滾過程同樣簡單：我們只需再次撥動開關，先前的版本就被換回原位。那是因為舊版本仍在舊 Pod 上運行。只是流量不再被路由到他們。當我們確信新版本會繼續存在時，我們應該停用這些 pod。
金絲雀部署
Canary 更新策略是一個部分更新過程，它允許我們在真實用戶群上測試我們的新程序版本，而無需承諾全面推出。類似于藍/綠部署，但它們更受控制，并且它們使用更漸進的交付方式，其中部署是分階段進行的。有許多策略屬于金絲雀的保護傘，包括暗發布或 A/B 測試。
在金絲雀部署中，新版本的應用程序逐漸部署到Kubernetes集群，同時獲得極少量的實時流量（即，一部分實時用戶正在連接到新版本，而其余的仍在使用以前的版本） .在這種方法中，我們有兩個幾乎相同的服務器：一個用于所有當前活躍用戶，另一個帶有新功能，用于向一部分用戶推出然后進行比較。當沒有錯誤報告并且信心增加時，新版本可以逐漸推廣到基礎架構的其余部分。最后，所有實時流量都流向金絲雀，使金絲雀版本成為新的生產版本。
下圖顯示了進行金絲雀部署的最直接和最簡單的方法。新版本部署到服務器的子集。
在發生這種情況時，我們會觀察升級后的機器的運行情況。我們檢查錯誤和性能問題，并聽取用戶反饋。隨著我們對金絲雀越來越有信心，我們繼續在其余機器上安裝它，直到它們都運行最新版本。
在規劃金絲雀部署時，我們必須考慮各種因素：
1. 階段：我們將首先向金絲雀發送多少用戶，以及在多少階段。
2. 持續時間：我們計劃運行金絲雀多久？Canary 版本不同，因為我們必須等待足夠多的客戶端更新才能評估結果。這可能會在幾天甚至幾周內發生。
3. 指標：記錄哪些指標以分析進度，包括應用程序性能和錯誤報告？精心選擇的參數對于成功部署 Canary 至關重要。例如，衡量部署的一種非常簡單的方法是通過 HTTP 狀態代碼。我們可以有一個簡單的 ping 服務，當部署成功時返回 200。如果部署中存在問題，它將返回服務器端錯誤 (5xx)。
4. 評估：我們將使用什么標準來確定金絲雀是否成功
Canary 用于我們必須在應用程序后端測試新功能的場景。當我們對新版本不是 100% 有信心時，應該使用 Canary 部署；我們預測我們失敗的可能性很小。當我們進行重大更新時，通常會使用此策略，例如添加新功能或實驗性功能。
7.K8s 部署策略總結
總而言之，部署應用程序有多種不同的方式；當發布到開發/暫存環境時，重新創建或升級部署通常是一個不錯的選擇。在生產方面，藍/綠部署通常很合適，但需要對新平臺進行適當的測試。如果我們對平臺的穩定性以及發布新軟件版本可能產生的影響沒有信心，那么金絲雀版本應該是我們要走的路。通過這樣做，我們讓消費者測試應用程序及其與平臺的集成。在本文中，我們只觸及了 Kubernetes 部署功能的皮毛。通過將部署與所有其他 Kubernetes 功能相結合，用戶可以創建更強大的容器化應用程序以滿足任何需求。
