🥇Kubernetes 中的部署策略：滾動、重新創建、藍/綠、金絲雀、黑暗（A/B 測試）| ProHoster

註：翻譯： Weaveworks 的這篇概述介紹了最受歡迎的應用程式部署策略，並展示如何使用 Kubernetes Flagger Operator 實現最先進的策略。它以簡單易懂的語言編寫，並包含視覺化圖表，即使是新手工程師也能輕鬆理解。

Kubernetes 中的部署策略：滾動、重新創建、藍/綠、金絲雀、深色（A/B 測試）
該圖取自另一則評論 Container Solutions 制定的推廣策略

如今，開發雲端原生應用程式的最大挑戰之一是加快部署速度。借助微服務方法，開發人員已經能夠使用完全模組化的應用程式並進行設計，從而允許不同的團隊同時編寫程式碼並對應用程式進行更改。

更短、更頻繁的部署具有以下好處：

上市時間縮短了。
新功能可以更快傳達給使用者。
使用者回饋可以更快地傳達給開發團隊，這意味著團隊可以更快地添加功能和解決問題。
開發人員的士氣提高了：開發的功能越多，開發這些功能就越有趣。

但隨著發布頻率的增加，對應用程式可靠性或使用者體驗產生負面影響的可能性也會增加。因此，對於營運和 DevOps 團隊來說，建立流程和管理部署策略至關重要，這樣才能最大限度地降低產品和使用者的風險。（您可以在此處了解有關 CI/CD 管線自動化的更多資訊。）這裡.)

在本文中，我們將討論 Kubernetes 中的各種部署策略，包括滾動部署和更高級的技術，例如金絲雀部署及其變體。

部署策略

根據您的目標，您可以使用幾種不同類型的部署策略。例如，您可能希望將變更部署到特定環境以進行進一步測試，或部署到部分使用者/用戶端，或者您可能希望在發布功能之前進行有限的使用者測試。公開.

滾動（逐步，“滾動”部署）

這是 Kubernetes 中的標準部署策略。它會逐步地以執行新版本的 Pod 取代執行舊版應用程式的 Pod，整個過程不會造成叢集停機。

Kubernetes 中的部署策略：滾動、重新創建、藍/綠、金絲雀、深色（A/B 測試）

Kubernetes 等待新的 Pod 準備好運行（透過使用準備情況測試)，然後再捲動更新舊鏡像。如果出現問題，可以中斷此類滾動更新，而無需停止整個叢集。在描述部署類型的 YAML 檔案中，新映像將取代舊鏡像：

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: awesomeapp
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: awesomeapp
    spec:
      containers:
        - name: awesomeapp
          image: imagerepo-user/awesomeapp:new
          ports:
            - containerPort: 8080

滾動更新的參數可以在清單檔案中指定：

spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
       maxSurge: 25%
       maxUnavailable: 25%  
  template:
  ...

重新創建

在這種最簡單的部署類型中，舊的 pod 會被一次性全部殺死，並替換為新的 pod：

Kubernetes 中的部署策略：滾動、重新創建、藍/綠、金絲雀、深色（A/B 測試）

相應的宣言如下：

spec:
  replicas: 3
  strategy:
    type: Recreate
  template:
  ...

藍/綠（藍綠部署）

藍綠部署策略（有時也稱為紅/黑）涉及同時部署應用程式的舊版本（綠色）和新版本（藍色）。部署兩個版本後，一般使用者可以存取綠色版本，而 QA 團隊可以透過單獨的服務或直接連接埠轉送存取藍色版本進行自動化測試：

Kubernetes 中的部署策略：滾動、重新創建、藍/綠、金絲雀、深色（A/B 測試）

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: awesomeapp-02
spec:
  template:
    metadata:
      labels:
        app: awesomeapp
        version: "02"

一旦藍色（新）版本經過測試並批准發布，服務就會切換到該版本，並且綠色（舊）版本將被淘汰：

apiVersion: v1
kind: Service
metadata:
  name: awesomeapp
spec:
  selector:
    app: awesomeapp
    version: "02"
...

Canary（金絲雀部署）

金絲雀捲與藍綠類似，但控制和使用效果更好。進步分階段方法。這種類型包含幾種不同的策略，包括「隱形」發布和 A/B 測試。

這種策略通常用於測試應用程式後端的新功能。其核心是創建兩台幾乎完全相同的伺服器：一台服務幾乎所有用戶，另一台包含新功能，僅服務一小部分用戶。之後，將兩台伺服器的運行結果進行比較。如果一切順利，新版本將逐步推廣到整個基礎架構。

雖然可以單獨使用 Kubernetes 來實現此策略，用新的 pod 取代舊的 pod，但使用像 Istio 這樣的服務網格會更方便和簡單。

例如，您可能在 Git 中有兩個不同的清單：一個帶有標籤 0.1.0 的常規清單，以及一個帶有標籤 0.2.0 的金絲雀清單。透過更改 Istio 虛擬閘道清單中的權重，您可以控制這兩個部署之間的流量分配方式：

Kubernetes 中的部署策略：滾動、重新創建、藍/綠、金絲雀、深色（A/B 測試）

有關使用 Istio 實現金絲雀部署的逐步指南，請查看本文使用 Istio 的 GitOps 工作流程. (筆記。翻譯。：我們也翻譯了有關 Istio 中金絲雀發布的內容這裡.)

使用 Wealworks Flagger 進行金絲雀部署

Weaveworks 旗手使您能夠輕鬆有效地管理金絲雀發布。

Flagger 實現了這項工作的自動化。它使用 Istio 或 AWS App Mesh 來路由和切換流量，並使用 Prometheus 指標來分析結果。此外，金絲雀部署的分析還可以透過 Webhook 進行補充，用於驗收測試、負載測試以及任何其他類型的檢查。

基於 Kubernetes 部署以及必要時的水平 pod 擴充 (HPA)，Flagger 創建了一系列物件（Kubernetes 部署、ClusterIP 服務以及 Istio 或 App Mesh 虛擬服務）來執行分析並實現金絲雀部署：

Kubernetes 中的部署策略：滾動、重新創建、藍/綠、金絲雀、深色（A/B 測試）

實現控制迴路 （控制迴路）Flagger 會逐步將流量切換到金絲雀伺服器，同時測量關鍵效能指標，例如 HTTP 請求成功率、平均請求時間以及 Pod 健康狀況。根據 KPI 分析，金絲雀伺服器會進行擴容或縮容，並將結果發佈到 Slack。此過程的描述和演示可參見文章 App Mesh 的漸進式交付.