● 前言

延續 Day 11 的 Minikube 實作，今天把雲端常見的四種部署策略用最精簡的方式梳理：何時用、怎麼做、怎麼回滾。

● 四種部署策略

1. 滾動部署 (Rolling Update)

• 概念：一批一批替換 Pod，零停機、預設最常用
• 適用時機：小改動、高頻率上線；新舊版本可同時存在
• 缺點：回滾要等批次完成；務必設好 readinessProbe

2. 重新創建 (Recreate)

• 概念：先砍掉全部舊 Pod，再創建新 Pod；中間會有停機
• 適用時機：新舊版本無法並存（如相依資源衝突）且可接受短暫停機
• 缺點：務必安排維護視窗；檢查資料遷移是否已完成

3. 藍綠部署 (Blue-Green)

• 概念：同時維持兩套完整環境（Blue/Green），以 Service 切換流量
• 適用時機：大改版、需快速切換/回滾、風險隔離
• 缺點：基礎設施成本較高；共用資料時要注意雙版本 schema 相容

4. 金絲雀 (Canary)

• 概念：先讓少量流量走新版本，觀察指標穩定再逐步放量
• 適用時機：對穩定性極敏感、需要以資料驅動控制風險
• 缺點：需要流量治理能力（Ingress 權重、或 Service Mesh/Argo Rollouts），並配合 SLO/告警

● 注意事項

• Health probes 一定要有：
  • readinessProbe 防止未就緒先收流量
  • livenessProbe 自動自癒
• 資料庫相容性：
  • 先做向前/向後相容的 migration
  • 若不可並存就選 Recreate 或藍綠
• 把回滾當日常：
  • 確保每次上線都能在 1–2 指令內回滾

● 總結

Kubernetes 的部署策略並沒有「唯一正解」，而是根據場景取捨：

▪ Rolling Update → 適合大部分日常小改動
▪ Recreate → 當新舊版本無法共存時的最後手段
▪ Blue-Green → 成本較高，但能快速切換與回滾
▪ Canary → 最謹慎，也最依賴監控與流量治理

📌 最重要的是：每次上線都要能快速回滾，這才是真正的安全網。

在 Day 11 我們已經成功把應用程式部署到 Minikube 的 Pod 中，但 Pod 本身只是「內部可見」。

👉 下一篇

Day 13｜要讓外部世界能真正訪問服務，就需要 Service 與 Ingress