昨天準備好環境了，今天先來聊聊為什麼需要 k8s。

Kubernetes（簡稱 K8s）: 用來管理大量 Container 的執行、調度和維運的平台。當服務從一台機器成長到需要跨多台機器、同時跑幾十甚至幾百個 Container 的時候，K8s 就是那個幫你統一管理這一切的工具。

但在談 K8s 能做什麼之前，先來看看只用 Docker 單機跑會遇到哪些問題 !

單機容器的三個極限

只用 Docker 跑單台機器，會依序撞到三道牆：可用性、擴展性、管理複雜度。

第一道：可用性

如果單台機器遇到斷電或當機，整個服務就跟著停擺。

Docker Compose 的 restart: on-failure 只能處理 Container 本身崩潰時自動重啟，但整台機器故障它完全無能為力。

第二道：擴展性

為了解決可用性問題，你會想多跑幾個 Container 來分攤負載、降低單點故障的風險。但這時新問題來了：

• 該如何動態決定要啟動幾個副本？
• 多個 Container 之間該怎麼分配連線請求？
• 流量退去後要怎麼自動縮減資源？

第三道：管理複雜度

為了突破前兩道牆，你可能手動多租幾台伺服器分散部署。但問題不是消失了，而是變得更難：

• 哪個 Container 正在哪台機器上運作？
• 某台機器掛了，上面的 Container 要怎麼自動轉移？
• 新版本怎麼跨機器做到零停機的滾動更新（Rolling Update）？

靠人工維護這些流程，在生產環境中出錯只是時間問題。

K8s 的三個核心能力

K8s 對應了上面三個問題，提供三個核心能力：

1. 自動調度（Scheduling）

你只需告訴 K8s「我要跑三個 FastAPI Container」，K8s 就會評估叢集中各節點的剩餘 CPU 與記憶體，自動將 Container 派發到最適當的機器上，不需要手動指定。

2. 自癒（Self-healing）

K8s 會持續監控所有 Container 與節點的健康狀態。Container 異常崩潰時會立即重啟；整台節點故障時，會自動將任務搬移到其他健康的節點繼續運行。

3. 水平擴縮容（Auto Scaling）

你可以設定彈性伸縮規則，例如「當平均 CPU 使用率超過 70%，就自動擴增 Container 數量」。流量高峰時自動擴容，離峰時自動縮容節省成本。

K8s 與 Docker 的關係

兩者分工不同，但相互依存：

┌─────────────────────────────────────┐
│             Kubernetes              │
│    （決定 Container 跑在哪裡、       │
│     管理生命週期、自動擴縮容）       │
│                                     │
│  ┌──────────┐  ┌──────────┐         │
│  │  Docker  │  │  Docker  │   ...   │
│  │Container │  │Container │         │
│  └──────────┘  └──────────┘         │
└─────────────────────────────────────┘

• Docker 負責把應用程式打包成 Container
• K8s 負責管理這些 Container 跑在哪裡、跑幾個、掛了怎麼辦。

K8s 站在 Docker 的肩膀上，把單機容器管理的能力延伸到跨機器的叢集層次。還是需要用 Docker 打包 Image，K8s 只是接手了「執行與調度」的部分。

什麼時候需要 K8s？

K8s 有一定的學習曲線和維運成本，不是所有情境都適合引入。

適合的情境：

• 服務需要高可用，任何一台機器掛掉都不能停服務
• 流量有明顯峰谷，需要自動擴縮容
• 同時管理多個微服務，需要統一的部署平台
• 團隊規模到了需要標準化部署流程的程度

暫時不需要的情境：

• 個人專案或小型內部工具，單台機器就夠用
• 還在摸索 product-market fit，架構頻繁變動
• 沒有足夠的人力維護叢集

小結

K8s 解決的不是「怎麼跑一個 Container」，而是「怎麼在生產環境中可靠地跑很多個 Container」。

明天來把 K8s 的架構全貌拆開來看，搞清楚每個元件各自的角色 !