概述

部署策略是 DevOps 實踐中的一個重要部分，它決定了如何將新版本的應用程式安全且高效地部署到生產環境中。選擇合適的部署策略可以最大限度地降低風險，減少成本，縮短停機時間，並確保新功能和修復能夠快速地交付給用戶。

選擇正確的部署策略是要依賴於我們的業務需求的，以下是一些在 DevOps 中常見的部署策略：

• Recreate：在新版本部署時，會將所有舊版本的實例停掉，然後一次性啟動所有新版本的實例。
• Rolling-update：逐步將舊版本的實例替換為新版本的實例，通常是一個一個或一小部分地進行。
• Blue/Green：同時運行兩個版本（藍色和綠色），其中一個是生產環境，另一個是準備環境。當新版本（綠色）準備好後，切換流量到新版本。
• Canary：將新版本部署到一小部分伺服器上，然後逐步擴展到所有伺服器，根據反饋調整部署策略
• A/B testing：部署多個版本（A 和 B），並根據不同的用戶群體或流量條件進行測試，對比性能和效果。
• Shadow：新版本和舊版本同時運行。所有流量先進入舊版本，再複製到新版本，但新版本的回應不對外。

接下來我們來認識每種策略的特點，以及在什麼場景下面適合哪種策略。

Recreate

Recreate（重建）部署策略是一種最簡單直接的部署方法。在這種策略中，所有舊版本的實例會被同時停止，然後一次性啟動所有新版本的實例。這意味著在新版本完全啟動之前，應用程序會有一段停機時間。

下圖是更新過程應用接收流量的示意圖：

特點：

• 簡單直接：實現簡單，沒有複雜的切換過程或多版本共存問題。
• 全量替換：所有舊版本實例同時停止，新版本實例同時啟動。

優點：

• 實現簡單：不需要考慮多版本共存的兼容性問題，只需關停舊版本並啟動新版本。
• 明確的過渡：舊版本和新版本之間有明確的切換點，易於管理和理解。
• 節省成本：不需要額外的資源來同時運行兩個版本。

缺點：

• 停機時間：在新版本啟動之前，應用會有一段不可用的時間，對於需要高可用性的應用程序不適合。
• 風險較高：如果新版本有問題，可能會導致整個應用的停機，需要快速回滾機制。

適用場景：

• 非關鍵應用：應用不需要24/7全天候運行，能夠容忍短暫的停機時間。
• 低流量時段：可以在系統使用量低的時段進行部署，將對用戶的影響降到最低。
• 開發和測試環境：開發和測試環境中，停機時間和風險相對可控。

Recreate 部署策略雖然簡單，但因其停機時間和風險較高，通常只適用於特定情況下的快速部署。

要在 Kubernetes 使用此策略，我們可以在 Deployment 資源中定義 spec.strategy.type 為 Recreate，使用該策略進行部署。

spec:
  replicas: 3
  strategy:
    type: Recreate

Rolling Update

Rolling Update（滾動更新）又被稱為 Ramped，是一種逐步替換應用程序舊版本實例為新版本實例的部署策略。與 Recreate 不同的是，滾動更新不會同時停止所有舊版本實例，而是分批次地進行替換，直到所有實例都被替換完成為止，這樣可以減少或避免應用程序的停機時間。

下圖是更新過程應用接收流量的示意圖：

特點：

• 分批更新：逐步將舊版本實例替換為新版本實例，通常一次更新一個或一小部分實例。
• 無縫過渡：在整個更新過程中，應用程序保持可用狀態。

優點：

• 最小化停機時間：因為應用程序一直保持部分實例在運行，減少了停機時間，甚至實現無停機更新。
• 風險可控：可以在每批次更新後進行檢查，如果發現問題，可以及時停止或回滾更新，降低風險。
• 資源利用率高：不需要額外的資源來同時運行兩個版本（如藍綠部署）。

缺點：

• 版本共存問題：在更新過程中，舊版本和新版本的實例會同時存在，可能會引發兼容性問題。
• 更新速度慢：逐步更新的過程需要一定的時間，相較於一次性更新需要更長的部署時間。

適用場景：

• 高可用應用：需要保持高可用性，不能容忍長時間停機的應用程序。
• 大規模應用：適合大型分佈式系統，能夠分批次逐步更新，確保穩定性。
• 業務關鍵應用：在更新過程中需要確保應用程序的穩定運行，並能夠快速響應問題。

滾動更新是一種在保證應用程序高可用性的前提下，逐步進行版本更新的策略，適合需要連續運行且無法承受長時間停機的應用程序。

要在 Kubernetes 使用此策略，可以在 Deployment 資源中定義 spec.strategy.type 為 RollingUpdate，然後定義關鍵參數：

spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 2        # 一次可以新增多少個Pod
      maxUnavailable: 1  # 滾動更新期間最大多少個Pod不可用

Blue/Green

Blue-Green Deployment（藍綠部署）也被稱為紅/黑部署，是一種用於減少停機時間並降低部署風險的部署策略。這種策略通過同時運行兩個環境（藍色和綠色）來實現無縫的版本切換。

下圖是更新過程應用接收流量的示意圖：

特點：

• 雙環境運行：同時維護兩個幾乎相同的環境，一個是當前活躍的生產環境（藍色），另一個是待切換的新版本環境（綠色）。
• 快速切換：當新版本準備好後，只需切換流量到新版本環境即可。

優點：

• 無縫切換：切換過程快速且無縫，幾乎不會影響用戶使用。
• 便於回滾：如果新版本有問題，可以迅速切換回舊版本，降低風險。
• 測試環境：新版本在切換之前，可以在綠色環境中進行完整的測試，確保其穩定性和兼容性。

缺點：

• 資源消耗大：需要同時維護兩個幾乎相同的環境，資源需求是單一環境的兩倍。
• 環境同步：需要確保兩個環境的配置和數據一致，增加了管理的複雜性。

適用場景：

• 關鍵應用：對於業務關鍵應用，需要保證極高的可用性和可靠性，不能接受長時間的停機。
• 頻繁部署：適合需要頻繁發布新版本且每次部署風險較高的應用。
• 充足資源：在資源充足且成本不是主要考量的情況下，使用藍綠部署可以最大化減少部署風險。

藍綠部署策略通過雙環境運行和快速切換流量，有效降低了新版本部署的風險，適合需要高可用性和穩定性的應用程序。

在 Kubernetes 中，我們可以用兩種方法來實現藍綠部署，通過單個 Service 對象或者 Ingress 控製器來實現藍綠部署，實際操作都是類似的，都是通過 label 標籤去控制。

同時部署新版本(綠) 與舊版本(藍) ，在新版本通過測試後，然後才更新 Kubernetes 中扮演負載平衡器角色的 Service 對象，通過替換 label selector 中的版本標籤來將流量傳送到新版本。

Canary 金絲雀

Canary Deployment（金絲雀部署）是一種漸進式的部署策略，通過將新版本先部署到少量伺服器上，然後根據實際效果逐步擴大部署範圍，以控制風險和驗證新版本的穩定性。

金絲雀部署是讓部分使用者訪問到新版本應用，

下圖是更新過程應用接收流量的示意圖：

特點：

• 漸進式部署：將新版本逐步推向更多伺服器，從小規模開始，逐步擴大。
• 風險控制：新版本問題可以在早期小範圍內被發現並修正，降低全量部署的風險。

優點：

• 風險最小化：初始階段的新版本僅影響一小部分用戶，可以快速識別並修復潛在問題。
• 用戶反饋：可以在小範圍內收集生產環境的用戶反饋，確保新版本在全量部署前的品質。
• 靈活性高：部署過程中可以根據反饋調整策略，靈活應對問題。

缺點：

• 實現複雜：需要精細的監控和流量管理，技術實現相對複雜。
• 版本共存問題：新舊版本共存期間，可能會有兼容性問題，需要確保向後兼容。

適用場景：

• 大規模應用：適合大型應用程序，能夠分批次逐步更新，確保穩定性。
• 頻繁部署：需要頻繁發布新版本且每次部署風險較高的應用。
• 用戶反饋：希望在全量部署前獲取用戶反饋和數據，以保證新版本的品質。

金絲雀部署策略通過漸進式的部署方式，有效降低了新版本上線的風險，適合需要高可靠性和逐步驗證的應用程序。

在 Kubernetes 中，可以使用兩個具有相同 Pod 標籤的 Deployment 來實現金絲雀部署。新版本的副本和舊版本的一起發佈。在一段時間後如果沒有檢測到錯誤，則可以擴展新版本的副本數量並刪除舊版本的應用。

如果需要按照具體的百分比來進行金絲雀發佈，需要儘可能的啟動多的 Pod 副本，這樣計算流量百分比的時候才方便。比如，如果你想將 1% 的流量傳送到版本 B，那麼我們就需要有一個運行版本 B 的 Pod 和 99 個運行版本 A 的 Pod，當然如果你對具體的控制策略不在意的話也就無所謂了，如果你需要更精確的控制策略，建議使用服務網格（如 Istio），它們可以更好地控制流量。

A/B testing

A/B Testing （A/B 測試）部署策略是一種通過同時運行兩個或多個版本應用，透過如地理位置、Header、Cookie、User Agent、語言等條件，來決定使用者將要訪問的應用版本。來測試和比較其效果的部署方法。這種策略通常用於優化產品性能、用戶體驗和業務指標，是一種基於統計數據而不是部署策略來製定業務決策的技術。然而，它是相關的，並且可以透過向金絲雀部署添加額外的功能來實現。

下圖是更新過程應用接收流量的示意圖：

特點：

• 多版本同時運行：同時運行兩個或多個版本（如版本 A 和版本 B），並將用戶分配到不同版本進行測試。
• 數據驅動決策：根據不同版本的表現和數據分析結果來決定最終使用哪個版本。

優點：

• 用戶反饋直接：可以直接從真實用戶處獲得反饋，了解不同版本的實際效果。
• 精確分析：能夠精確比較不同版本在特定指標上的表現，如轉化率、點擊率、用戶留存等。
• 低風險：只影響一部分用戶，風險較低，便於在測試中發現並修正問題。

缺點：

• 實現複雜：需要精確的流量分配和數據分析，技術實現相對複雜。
• 用戶體驗差異：不同版本的用戶體驗可能會有所差異，需要管理好用戶預期和反應。

適用場景：

• 產品優化：適合需要不斷優化用戶體驗和業務指標的產品。
• 新功能測試：在推出新功能或設計變更時，用於測試其效果和用戶接受度。
• 數據驅動決策：需要通過數據分析來做出產品決策的場景。

在 Kubernetes 中並不原生支援，需要額外的一些高級元件來完成改設定（比如 Istio、Linkerd、Traefik、或者自訂 Nginx/Haproxy 等）

要使用這些細粒度的控制，仍然還是建議使用 Istio ，可以根據權重或 HTTP 頭等來動態請求路由控制流量轉發。

Shadow

Shadow Deployment（影子部署）是一種部署策略，允許在不影響實際生產流量的情況下，將生產環境中的流量複製到新版本應用程序中，以進行真實環境下的測試。這種方法能夠在不影響用戶體驗的前提下，驗證新版本的性能和功能。

下圖是更新過程應用接收流量的示意圖：

特點：

• 流量複製：將真實的生產流量複製到新版本的應用程序中，並行執行。
• 無影響測試：新版本的響應不會返回給用戶，因此不會影響實際的用戶體驗。

優點：

• 真實環境測試：可以在真實的生產環境中測試新版本，獲取準確的性能和功能數據。
• 零風險：新版本的任何問題都不會影響到用戶，因為其響應不會被用戶看到或使用。
• 全面驗證：可以在部署到所有用戶之前，全面驗證新版本的兼容性和穩定性。

缺點：

• 資源消耗：需要額外的資源來運行影子實例，與生產環境並行。
• 實現複雜：需要精確的流量複製和管理，技術實現較為複雜。
• 延遲和負載：流量複製可能導致額外的延遲和負載，需考慮系統承受能力。

適用場景：

• 性能測試：需要在真實流量下測試新版本性能的情況。
• 兼容性驗證：新版本可能會對現有系統產生影響，需要全面驗證其兼容性。
• 高風險更新：新版本變更較大或風險較高，需要在不影響用戶的情況下進行全面測試。

該技術的設置相當複雜，並且需要特殊要求，特別是對於出口流量。例如，對於一個電商平台，如果您想對支付服務進行影子測試，最終可能會導致客戶為其訂單支付兩次費用。在這種情況下，您可以透過建立複製來自提供者的回應的模擬服務來解決這個問題。

小結

根據上述策略的特性以及優缺點，我們可以簡單的為應用場景對應的策略做個結論：

• 開發/測試環境：recreate 或 rolling update 是節省成本和麻煩的理想選擇。
• 生產環境：rolling update 或 blue/green 適合一般，但新版本的提前測試非常重要。
• 不兼容的新版本：blue/green 最為合適。
• 真實環境測試：canary 可將使用者影響降至最低。
• 特定使用者群體測試新功能：A/B testing 他就是為這個情境而生。

參考

• https://www.qikqiak.com/post/k8s-deployment-strategies
• ContainerSolutions/k8s-deployment-strategies: Kubernetes deployment strategies explained (github.com)