Kubernetes 在 AI 部署裡做什麼？
原題
下列何者為 Kubernetes 在 AI 模型部署與運行中的核心功能？
白話
Kubernetes（通常縮寫成 K8s）是一套用來管理「容器（container）」的工具。
這題問你：當公司把 AI 模型上線提供服務時，Kubernetes 主要負責什麼事？
先自己選一個答案，再看完整解析。
一句話總結
Kubernetes 是 AI 模型上線後的「服務管家」，核心是管理與協調模型服務的部署、擴展與運行環境，讓模型在多台機器上穩定跑、流量大了自動加機器、壞了自動重啟。
情境
先感受問題：模型訓練好了，然後呢？
假設「智慧信貸」公司的工程師王俊訓練好了一個信用評分模型，準確率 92%。
但問題來了：訓練好的模型只是一個檔案，怎麼讓它變成一個能被 App 即時查詢的服務？
他把模型包進一個「容器（container）」，容器就像一個完整的迷你電腦環境，裡面有 Python、套件、模型本身，隨時可以啟動。
但下一個問題更難：
- 每天查詢量不穩定，早上 1,000 次、晚上可能 50,000 次，一台機器不夠用，要自動開更多
- 容器當機了要自動重啟，不能讓服務中斷
- 更新模型版本時，要讓舊版繼續跑，新版慢慢接手（滾動更新）
這些「讓很多容器在很多機器上穩定協作」的工作，就是 Kubernetes 的工作。
舊方法
沒有 Kubernetes 的時代，怎麼管模型服務
在 Kubernetes 出現前，工程師要自己扛起五件痛苦的事：
- 手動登入每台機器部署：有 10 台伺服器就要 SSH 登進去 10 次，一台一台啟動容器，超慢、超容易出錯。
- 自己寫腳本監控服務存活：容器掛掉，沒有人知道，要等使用者報錯才察覺，再手動重啟。
- 流量暴增時手動加機器：凌晨流量突然暴增，工程師要半夜爬起來手動開機器、部署容器、設定負載均衡。
- 更新模型版本超危險：舊版服務要先下線，新版部署好才能上線，中間有一段時間完全沒有服務（停機）。
- 資源浪費嚴重：為了應付流量高峰，平常都要留足夠多的機器待命，閒置時在燒錢。
新方法
Kubernetes 怎麼把這些都自動化
王俊把信用評分模型的容器交給 Kubernetes 管，只需要寫一份設定檔說明「我需要 3 個副本、流量超過 80% CPU 時自動擴展」。
Kubernetes 接手後：
- 自動部署：把容器分配到適合的機器上啟動，不用手動登入
- 自動重啟：某個容器掛了，幾秒內自動重啟一個新的，使用者完全不知道
- 自動擴縮（Autoscaling）：晚上查詢量暴增，Kubernetes 自動多開 10 個容器；流量退潮後自動縮回 3 個，節省費用
- 滾動更新（Rolling Update）：新模型版本部署時，先開幾個新版容器，確認沒問題後再逐步替換舊版，服務不中斷
- 負載均衡：把 App 進來的查詢請求，均勻分配給多個容器，不讓任何一個過載
這就是選項 B 講的：管理與協調模型服務的部署、擴展與運行環境。
本題沒有程式碼，但 Kubernetes 的背景知識在 MLOps 領域非常重要。
Kubernetes 的架構由幾個核心概念組成：
Pod：Kubernetes 的最小部署單位，一個 Pod 裡面有一個或多個容器。AI 模型服務通常每個 Pod 裡放一個模型推論容器。
Deployment：描述「我要幾個 Pod 副本、容器映像檔是哪個版本、更新策略是什麼」的設定物件。Kubernetes 會確保實際運行的 Pod 數量和 Deployment 設定一致。
Service：給外部流量一個固定的入口（IP 位址 + 連接埠），自動把請求轉發給後面的 Pod，實現負載均衡。
HPA（Horizontal Pod Autoscaler，水平 Pod 自動縮放器）：監控 CPU、記憶體或自訂指標（如每秒查詢數），根據規則自動增減 Pod 數量。
在 AI 推論服務的典型架構裡：
App / API Gateway
↓
Kubernetes Service（負載均衡）
↓ ↓ ↓
Pod 1 Pod 2 Pod 3 （各跑一個模型推論容器）
GPU or CPU GPU or CPU GPU or CPU
流量暴增 → HPA 自動新增 Pod 4, 5, 6
流量退潮 → HPA 自動縮回 Pod 1, 2, 3Kubernetes 本身不做：訓練（那是 Kubeflow / MLflow 的工作）、資料儲存（那是 MinIO / S3 的工作）、GPU 計算（那是 CUDA / NVIDIA 驅動的工作）。它做的是「讓這些東西的容器穩定地跑在一起」。
錯選項
為什麼其他選項是錯的
A自動化管理模型的訓練流程與參數調校
字面在說什麼
說 Kubernetes 能幫你跑模型訓練、調整超參數（Hyperparameter），讓訓練流程自動化。
為什麼不對
Kubernetes 是容器編排（container orchestration）工具，它管的是「讓容器跑起來並保持穩定」，不理解 AI 模型訓練的流程。管理訓練流程和超參數調校是 Kubeflow、MLflow、Weights & Biases 等 MLOps 工具的專職工作。Kubernetes 可以作為它們的底層基礎設施，但功能本身不是 Kubernetes 的。
誰會選錯
聽過「Kubernetes 很萬能」但沒細究它具體做什麼的人。Kubernetes 不懂 AI，它只管容器的生死和分配，不管容器裡跑的是訓練還是推論。
C提供 AI 模型的資料儲存與版本控管功能
字面在說什麼
說 Kubernetes 能儲存訓練資料、管理模型的不同版本（v1.0、v2.0 等）。
為什麼不對
資料儲存是物件儲存（S3、MinIO、GCS）或資料庫的工作。模型版本控管是 MLflow Model Registry、DVC、Weights & Biases 的工作。Kubernetes 本身的「儲存」只是掛載磁碟（Persistent Volume）讓容器能讀寫本地資料，不負責 AI 相關的版本管理邏輯。
誰會選錯
把 Kubernetes 和整個 MLOps 平台混為一談的人。Kubernetes 是基礎設施層，在它上面才跑著各種 MLOps 工具，但功能要分清楚。
D負責深度學習推論的 GPU 加速運算
字面在說什麼
說 Kubernetes 本身負責用 GPU 做深度學習的計算加速。
為什麼不對
GPU 計算是由 CUDA 驅動程式和 AI 框架（PyTorch、TensorFlow）負責的。Kubernetes 只是協調哪個 Pod 可以使用 GPU 資源，把 GPU 分配給對應的容器，但計算本身完全不是 Kubernetes 做的。這就像說「停車場負責開車」，停車場負責分配車位，不負責開車。
誰會選錯
看到「AI 推論」就聯想到「GPU」，再聯想到「Kubernetes 管 GPU」的人。管理（分配資源）和執行（跑計算）是兩件事，Kubernetes 做前者。
變形題
同個考點下次怎麼變形
Docker 和 Kubernetes 都常常一起出現，是同一個東西嗎？
答案
不同層次的工具。Docker 負責「建立和跑單個容器」，是製作容器的工具。Kubernetes 負責「管理很多容器在很多機器上如何協作」，是容器的調度系統。比喻：Docker 是一台車，Kubernetes 是城市的交通管理系統（紅綠燈、停車場、路線規劃）。實務上用 Docker 打包 AI 模型，再交給 Kubernetes 統一管理部署。
既然 Kubernetes 這麼強，是不是所有 AI 服務都要用？
答案
小型服務或開發初期不需要。Kubernetes 本身有很高的學習曲線和維運成本（管理 cluster 本身就需要專業人員）。如果只是一個內部工具、每天只有幾百次查詢，用單台機器跑 Docker 容器就夠了。Kubernetes 的效益在於：多台機器、需要高可用性（不能停機）、流量波動大、需要自動擴縮的場景。
Kubeflow 聽起來和 Kubernetes 很像，是進化版嗎？
答案
Kubeflow 是跑在 Kubernetes 上面的 MLOps 平台，專門為機器學習工作流設計。Kubernetes 提供底層的容器調度能力，Kubeflow 在上面加了 AI 特有的功能：模型訓練 Pipeline 管理、超參數搜尋、模型服務（KServe）、實驗追蹤。選擇關係：Kubernetes 是基礎，Kubeflow 是 AI 專用的上層應用。
Kubernetes 不是 AI 專用的工具，電商、金融都在用，AI 場景有什麼特別？
答案
核心概念相同，但 AI 場景有幾個特殊需求。第一是 GPU 資源分配：一般 Web 服務用 CPU，AI 推論服務需要 GPU，Kubernetes 有 GPU 資源調度的設定（nvidia.com/gpu 資源請求）。第二是模型版本管理：需要和 Model Registry 整合，支援 A/B 測試（新舊模型各承接部分流量）。第三是大 Pod 啟動時間：AI 模型容器往往好幾 GB，啟動慢，需要針對性的健康檢查設定。
服務上線後，怎麼知道 Kubernetes 管得好不好？
答案
幾個關鍵監控指標。Pod 可用率（Available Pods / Desired Pods），應該接近 100%。服務回應時間（P50 / P95 / P99 latency），AI 推論服務通常目標是 P99 在 200ms 以內。自動擴縮觸發頻率，太頻繁代表資源規劃不足。容器重啟次數（CrashLoopBackOff），多代表程式碼或資源有問題。這些指標通常透過 Prometheus + Grafana 監控。
延伸
想再往下看，這 5 個
- 模型部署（Model Deployment）
將訓練完成的模型上線為可查詢服務的過程，Kubernetes 是現代模型部署的核心容器編排工具，正解考點。 - 容器化技術（Containerization）
把應用程式與依賴打包成可攜帶執行環境的技術，Kubernetes 管理的最小單位 Pod 即由容器組成。 - 機器學習維運（Machine Learning Operations）
涵蓋模型訓練到生產的完整工程實踐，Kubernetes 是 MLOps 基礎設施層的核心，負責容器編排與擴縮。 - 自動擴展（Auto Scaling）
Kubernetes 透過 HPA 根據流量自動增減 Pod 數量，是 AI 推論服務應對流量波動的關鍵能力。 - 模型服務化（Model Serving）
讓訓練完的模型以 API 形式提供即時推論的工程實作，Kubernetes 確保模型服務穩定運行和負載均衡。