概述#

軟體迭代速度愈來愈快，從每兩週上線一次到一天上線數次都不再罕見。對 Server 守護者而言，好的部署策略幾乎決定了一次發布是平穩落地還是線上事故。它影響的不只是技術，更牽動推出時機、行銷節奏與風險控管：能否盡量不中斷服務、戰略性試水溫、必要時快速回滾舊版本，全都仰賴這套思考。

下面整理六種常見的部署策略。值得強調的是，這些策略並非 Kubernetes 獨有，任何能落實精神的做法都能算實現了該策略；只是 Kubernetes 在容器調度、彈性擴縮上的優勢，讓它能輕鬆優雅地完成這些任務。

1. 重建部署（Recreate）#

Recreate 直接把舊版本全部下線，再啟動新版本。代表服務一定會有一段停機時間，長度取決於應用關閉與啟動的耗時。

優點：

• 設定簡單。
• 線上同一時間只存在一個版本。
• 部署過程不會給主機額外負擔。

缺點：

• 對使用者影響大，停機時間無法避免。

2. 滾動部署（Rolling Update，又稱 Ramped）#

Rolling Update 像水緩緩流向低處：新版本一邊建起、舊版本一邊收尾，逐批替換不中斷。可以透過幾個參數調整速率與穩定性：

• 最大執行數：同時釋出的服務數量。
• 最大峰值（maxSurge）：升級過程能比設定值多出多少 Pod。
• 最大不可用數（maxUnavailable）：可容忍多少 Pod 處於不可用。

優點：

• 比藍綠部署省資源。
• 設定簡單，服務不中斷。

缺點：

• 釋出與回滾耗時，例如 100 個服務每次更新 10 個、每次 5 分鐘，更新到第 80 個才出錯就麻煩了。
• 部署期間新舊版本同時在線，較難精準控制流量並排錯。

3. 藍綠部署（Blue-Green Deployment）#

藍綠部署會先把新版本完整跑起來，等通過上線測試後，再把負載均衡器的流量從舊版本切到新版本。

優點：

• 即時釋出與回滾。
• 同一時間對外只看見一個版本，避免新舊衝突。
• 服務不中斷。

缺點：

• 部署完成前需要雙倍資源，提高成本。新版本未過驗收時舊版本也得繼續維持。
• 切換瞬間若有未處理完的交易需要額外處理。

4. 金絲雀部署（Canary Deployment）#

金絲雀部署不是非黑即白的切換，又稱為灰度發布（Canary Release）。它能把新版本緩慢推給一小部分使用者，確認沒問題後再全面推進，減少新功能直接進入生產環境的風險。例如 90% 流量留在舊版本、10% 導向新版本，常用於缺乏完整測試或對新版本穩定性沒把握的情境。

「金絲雀」一詞源自 17 世紀礦工會帶金絲雀下井，因為牠對瓦斯極度敏感，能在人類察覺前發出警訊。

優點：

• 容易監控與除錯。
• 只暴露給少數使用者，風險可控。
• 可以快速回滾、快速迭代。

缺點：

• 完整釋出期間較長。
• 只適用於可相容的迭代，大版本不相容時無法採用。

5. A/B 測試（A/B Testing）#

A/B 測試嚴格說是基於統計資訊做業務決策的技術，與業務結合非常緊密；但它經常與金絲雀部署搭配實作。除了根據權重分流之外，A/B 測試還能依 Cookie、User Agent、地區等條件鎖定特定使用者群，常用於驗證頁面版型、按鈕顏色、互動方式等使用者體驗差異，底層邏輯通常一致。Google Analytics 等分析工具搭配雲端負載均衡可以協助實作。

優點：

• 多版本並行運作。
• 完整掌控流量分布。

缺點：

• 需要更全面的負載均衡（通常仰賴雲端服務）。
• 分散追蹤與定位較困難（同樣常仰賴雲端解法）。

6. 影子部署（Shadow）#

影子部署會在原版本旁邊完整跑起新版本，並把流入舊版本的請求複製一份送到新版本，藉此觀察新版本在真實流量下的表現，直到符合上線條件才正式切換。

優點：

• 用真實流量驗證新版本，但不影響使用者體驗。
• 等到應用穩定且符合條件才正式發布。

缺點：

• 與藍綠部署一樣需要雙倍資源。
• 設定複雜，容易遇到意料之外的副作用，例如同筆下單請求被新舊兩版本各處理一次。

小結#

了解每種策略背後的精神之後，就能根據業務情境選擇合適的組合。接下來幾章會回到 Kubernetes 實戰，分別示範如何用 Deployment、Service 與 Ingress 落實 Recreate、Rolling Update、Blue-Green、Canary 等策略。

原文出處#

• GitHub：https://github.com/MikeHsu0618/2022-ithelp/tree/main/Day12
• iThome：https://ithelp.ithome.com.tw/articles/10289496