Deployment Strategies - Common Deployment Strategies
Kubernetes 提供了多種部署策略來協助開發者和運維工程師順利地更新應用程式，同時最大化系統的穩定性與可靠性。 以下將詳細介紹六種常見的部署策略：Recreate、Rolling Update、Blue/Green、Canary、A/B Testing 和 Shadow。
Recreate Strategy
概述
Recreate 是最簡單的部署策略。在此策略下，舊版本的應用程式會被完全關閉，然後再啟動新版本的應用程式。
流程
- 停止所有舊版本的 Pod。
- 啟動所有新版本的 Pod。
優點
- 簡單直接，適合不需要零停機時間的應用。
- 在部署過程中，只會有一個版本的應用在運行，避免版本之間的潛在衝突。
- 在部署過程中，不會對主機產生額外的負擔。
缺點
- 在更新過程中會造成停機，可能影響使用者體驗。
範例
- 首先將舊的 v1-deployment 完全下線
kubectl.exe scale deployment v1-deployment --replicas=0
- 等到舊的完全停止後，我們再將新版本的應用部署上去，並且擴展到 3 個 pod
kubectl.exe set image deployment/v1-deployment v1-container=hello-world:v2.0.0
kubectl.exe scale deployment v1-deployment --replicas=3
這種部屬方式會導致舊版本停止到新版本啟動之間無法提供服務，一般不會在 Production 環境使用。
Rolling Update Strategy
概述
Rolling Update 是 Kubernetes 預設的部署策略，通過逐步替換舊版本的 Pod 來實現應用的更新，緩慢平和地釋出新的版本。
流程
- 按照設定的步驟，依序關閉舊版本的 Pod 並啟動新版本的 Pod。
- 在任何時間點，集群中會同時存在舊版本和新版本的 Pod。
調整參數
- 最大執行數：可以同時釋出的服務數量。
- 最大峰值：升級過程中最多可以比原先設定多出的服務數量。
- 最大不可用數：最多可以有幾個服務處在無法服務的狀態。
優點
- 相較於藍綠部署更加節省資源。
- 便於設定，服務不中斷。
缺點
- 若新版本存在問題，回滾需 要一定時間。
- 可能導致短暫的不一致性，無法控制流量且噴錯時，除錯的困難度較高。
Blue/Green Strategy
概述
Blue/Green 策略將兩套完整的環境（Blue 和 Green）分開運行，一個用於生產環境，另一個用於部署新版本， 等新版本服務完整開啟，並且在新版本滿足上線條件測試後，才將流量從負載均衡從舊版本切到新版本。
流程
- 部署新版本至 Green 環境，並進行測試。
- 測試完成後，切換流量至 Green 環境。
- 保留 Blue 環境作為備份，以便快速回滾。
優點
- 確保新版本的完全穩定後再對外提供服務。
- 回滾速度快。
- 避免新舊版本衝突，整個過程只會有一個版本存在。
缺點
- 需要更多資源來維持兩個環境，部署和管理的成本較高。
- 切換到新版本的瞬間，如果有未處理完成的業務時，會比較麻煩。
Canary Strategy
概述
Canary 策略通過將新版本逐步釋放給一部分用戶來測試其穩定性，他與藍綠部署不同的是它不是非黑即白的部屬放式，所以又稱灰度部屬。
流程
- 部署新版本給少數用戶，觀察系統指標和用戶反饋。
- 根據測試結果，逐步增加新版本的流量分配。
優點
- 能夠及早發現新版本的問題，降低全量部署的風險。
- 只向一小部分使用者釋出。
- 支持逐步推進更新過程。
缺點
- 需要監控和分析的額外工作。
- 配置流量分配的機制可能較為複雜。
- 只適用於相容跌代，如果重大版本不相容就沒辦法使用這種方式。
A/B Testing Strategy
概述
A/B Testing 策略專注於比較不同版本的效果，以了解哪個版本對使用者更具吸引力或更有效， 例如 google analytics 等網站分析工具，也會搭配負載均衡器實現 A/B 測試。
流程
- 同時部署兩個版本（A 和 B）。
- 按照特定條件（如地區、用戶群組）將流量分配給不同版本。
- 收集和分析數據，確定最佳版本。
優點
- 幫助優化應用程式的功能和性能。
- 能夠基於數據進行決策。
缺點
- 需要對數據收集和分析有較高的要求。
- 配置和實現可能較為複雜，需要更全面的負載均衡器，通常由雲端服務實現。
- 難以定位辨別，通常由雲端服務實現分散式追蹤。
Shadow Strategy
概述
Shadow 策略允許將流量複製到新版本以進行測試，而不會影響實際用戶。
非常理想的流程，但背後所需要實現的技術門檻和成本相當高，尤其特殊情況下會難以控制， 例如：一個下單請求，被同時轉向新舊版本，最終可能產生下單兩次的結果
流程
- 將用戶的請求同時發送到舊版本和新版本。
- 觀察新版本的性能和行為。
優點
- 不影響實際用戶，適合敏感應用。
- 能夠在真實環境中測試新版本。
缺點
- 需要額外的資源來處理影子流量。
- 複雜度較高，尤其是在同步處理和監控方面。
結論
選擇合適的 Kubernetes 部署策略取決於應用的需求、資源的可用性以及更新過程中允許的風險程度。 了解每種策略的特性和適用場景有助於最大化 應用的可用性和用戶體驗。