主持人 > 博客 > 管理 > Kubernetes 中的部署策略：滾動、重新創建、藍/綠、金絲雀、深色（A/B 測試）

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

筆記翻譯： Weaveworks 的概述介紹了最受歡迎的應用程式部署策略，並展示如何使用 Kubernetes Flagger 運算子來實現最先進的策略。它以簡單的語言編寫，並包含視覺化圖表，即使是新手工程師也能理解問題。

Kubernetes 中的部署策略：滾動、重新創建、藍/綠、金絲雀、深色（A/B 測試）
該圖取自 另一則評論 容器解決方案中製定的推出策略

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

更短、更頻繁的部署具有以下優點：

  • 上市時間縮短。
  • 新功能更快到達用戶手中。
  • 用戶回饋更快到達開發團隊。這意味著團隊可以更快地添加功能並解決問題。
  • 開發人員士氣提升：開發中的功能越多，使用就越有趣。


但隨著發布頻率的增加，對應用程式的可靠性或使用者體驗產生負面影響的可能性也會增加。這就是為什麼營運和 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"
...

金絲雀（金絲雀部署）

金絲雀部署與藍綠部署類似，但具有更好的控制和使用 進步 循序漸進的方法。這種類型包括幾種不同的策略，包括「秘密」發布和 A/B 測試。

當需要嘗試一些新功能時（通常是在應用程式的後端），可以使用此策略。該方法的本質是創建兩個幾乎相同的伺服器：一個為幾乎所有用戶提供服務，另一個具有新功能，僅為一小部分用戶提供服務，然後對它們的工作結果進行比較。如果一切順利，新版本將逐步推廣到整個基礎架構。

雖然這個策略可以專門使用 Kubernetes 來實現，用新的 pod 取代舊的 pod，但使用像 Istio 這樣的服務網格要方便且簡單得多。

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

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

有關使用 Istio 實施金絲雀部署的逐步指南，請參閱 使用 Istio 的 GitOps 工作流程. (筆記。 翻譯。：我們也將有關金絲雀部署的資料翻譯成 Istio 這裡.)

使用 Wea​​lworks 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 的漸進式交付.

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

黑暗（隱藏）或 A/B 部署

隱形部署是金絲雀策略的另一種變體（順便說一句，Flagger 也可以使用它）。隱形部署和金絲雀部署之間的差異在於，隱形部署處理前端，而不是像金絲雀部署那樣處理後端。

這些部署的另一個名稱是 A/B 測試。新功能並未向所有用戶提供，而是僅向有限的一部分用戶提供。通常，這些使用者不知道他們是先鋒測試人員（因此稱為「隱形部署」）。

使用功能開關 （功能切換） 和其他工具，您可以監控使用者如何與新功能交互，他們是否參與其中，或者他們是否發現新使用者介面令人困惑，以及其他類型的指標。

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

Flagger 和 A/B 部署

除了基於權重的路由之外，Flagger 還可以根據 HTTP 參數將流量路由到金絲雀伺服器。在 A/B 測試中，您可以使用 HTTP 標頭或 cookie 來定位特定的使用者群。這對於需要會話綁定到伺服器的前端應用程式尤其有效 （會話親和力）。更多資訊可以在 Flagger 文件中找到。

作者表示感謝 斯特凡·普羅丹，Weaveworks 工程師（也是 Flagger 的創建者），了解所有這些令人驚嘆的部署模式。

譯者PS

另請閱讀我們的博客：

來源： www.habr.com

添加評論