平台要用 Docker Compose，還是 Kubernetes？Kubernetes 有排程、自我修復、服務發現與擴展能力，但這些能力背後，也需要持續投入時間。所以我會先想團隊現在需要什麼，再想之後誰來維護。

本篇名詞小筆記

• Docker Compose：用 YAML 定義並啟動多個容器，常用於單機開發、測試與小型部署。
• Kubernetes：容器編排平台，提供多節點排程、自我修復、服務發現、滾動更新與擴展。
• Image：容器映像，包含執行應用程式所需的程式、依賴與檔案系統。
• Secret：需要受控保存的敏感設定，例如密碼、Token、金鑰與憑證。

今天要解決的問題

如果服務都跑在一台主機上，部署的服務組合也不常變動，我會先確認 Docker Compose 夠不夠用；等到需要把服務分散到多台主機，某台掛掉時還要能自動移到別台，再評估 Kubernetes。判斷時我會同時看兩件事：這個需求是不是已經出現，以及團隊有沒有能力長期維護。下表是我對照的條件。

架構師視角：需求與維運能力要同時成立

圖 Day 27-1：Compose 或 Kubernetes。

看這張決策樹時，先問有沒有多節點與自動排程的需求，再確認團隊有沒有維運能力。需求已經出現、能力卻不足時，圖上會先回到 Docker Compose，同時把能力缺口列出來，再評估要補人、安排訓練，還是改用其他方案。

不論選哪個平台，健康檢查、備份與監控都還是要做，所以圖上兩條路最後都接到同一格。容器掛掉能自動重啟，不代表資料救得回來，也不代表重啟後應用的處理結果是對的，這兩件事要另外驗證。

工程師視角：兩種方式都要完成的基本工作

下面這份清單，選 Compose 或 Kubernetes 都要做：image 版本、健康檢查、資源限制、secret、持久化資料的備份、Log 與回復演練。先把這些做好，再考慮增加平台能力。

單一容器如果一直吃記憶體，同一台主機上的其他服務可能跟著受影響，所以資源限制要實際設定並測過。Kubernetes 也一樣：有沒有設 limit、超過時容器會被怎麼處理，都要自己確認，不能因為換了平台就假設已經有保護。

Compose 很適合先用來建立可重複的開發與整合測試環境。之後就算改用 Kubernetes，timeout 與冪等這些處理，Kubernetes 本身也不會替應用程式做，Day 19、Day 23 的做法仍然用得上。

策略取捨與限制

兩種方式都有需要維護的部分，Kubernetes 另外還要安排叢集本身的管理，這些時間都要算進去。所以評估成本時，我會把日常維護、升級測試與故障處理一起列出來。

驗證方式與衡量指標

如果導入了 Kubernetes，也要回頭用這些指標檢查：需要人工介入的事件有沒有變少？故障恢復時間有沒有縮短？要是這兩項都沒有明顯改善，花在維護上的時間卻變多了，就把不需要多節點的服務移回 Compose，只把真正需要的留在 Kubernetes。

今天先整理到這裡

我目前的選擇是先用 Compose：服務的需求它應付得來，團隊也維護得動。等多節點的需求真的出現，再依今天的條件重新評估 Kubernetes。下一篇，再用 ADR（架構決策紀錄）把這個決定和理由留下來。

參考資料

1. Docker, Docker Compose，查閱日期：2026-10-10。
2. Kubernetes, Kubernetes Concepts，查閱日期：2026-10-10。
3. Kubernetes, Resource Management for Pods and Containers，查閱日期：2026-10-10。