[Day 27] RAG 從 Docker Compose 走向 Kubernetes

當 RAG 系統不再只需要一個 Container

當系統開始面對更多使用者時，新的問題也會逐漸浮現：

• 同時運行多個 Application Container，要如何管理
• 某個 Container 異常停止，如何自動恢復
• 流量突然增加，如何自動擴展服務
• 更新系統時，如何避免服務中斷
• 多個服務分散在不同主機上，要如何進行服務發現與資源管理

這些問題已經不只是 Container 的問題，而是進入了 Container Orchestration 的範疇

因此，今天要從 Docker Compose 進一步認識 Kubernetes，了解如何將 RAG 系統從單機部署，逐步發展成可擴展、可復原的 Production 架構

什麼是 Container Orchestration

Container Orchestration 是指透過一套管理機制，自動部署、調度、擴展與維護多個 Container

當使用者數量增加時，我們可能需要啟動多個 RAG API Instances，當某個 Instance 故障時，也需要將流量導向其他 Instance

如果所有事情都依賴人工操作，系統管理的複雜度就會隨著服務規模增加

Container Orchestration 的目的是將這些工作交由平台自動管理

Docker Compose 與 Kubernetes 有什麼不同

兩者都能管理 Container，但適合的部署規模與管理需求不同

這並不代表 Docker Compose 不適合正式環境

對於規模較小、部署架構單純的服務，Compose 仍然是實用的選擇

當系統需要多節點調度、自動擴展、狀態管理與更完整的部署策略時，Kubernetes 就更有優勢

核心差異：Docker Compose 著重於定義與啟動一組服務，Kubernetes 則進一步管理服務在叢集中的運行狀態

認識 Kubernetes

Kubernetes 常簡稱為 K8s，是一套開源的容器編排平台

在開始部署 RAG 系統前，先理解幾個重要概念

Cluster 叢集

Cluster 是 Kubernetes 的整體運行環境，由 Control Plane 與一個或多個 Worker Node 組成

• Control Plane： 管理叢集狀態、排程與資源配置
• Worker Node： 實際運行應用程式的節點

Control Plane 會協調整個叢集，讓實際運行狀態盡可能符合我們設定的期望狀態

Node：節點

Node 是叢集中的工作節點，可以是實體機器或虛擬機器

當服務需要更多運算資源時，可以透過增加節點擴充叢集容量，但實際能否擴展，也取決於底層基礎設施與叢集設定

最小部署單位

Pod 是 Kubernetes 中最小的可部署單位

一個 Pod 可以包含一個或多個共享網路環境的 Container

需要注意，Pod 不等於 Container

Pod 是 Kubernetes 管理的部署單位，而 Container 是實際執行應用程式的環境

Deployment：管理應用程式

Deployment 用來定義應用程式應該如何運行

Kubernetes 會持續協調 Pod 的實際數量

如果其中一個 Pod 發生故障，控制器會嘗試建立替代 Pod，讓系統回到設定的狀態

Service：提供穩定的服務入口

Pod 可能因故障或重新部署而被替換，因此不適合讓其他服務直接依賴某個 Pod 的 IP

Service 可以為一組符合標籤條件的 Pod 提供穩定的網路入口，並將流量導向符合條件的後端 Pod

這樣一來，呼叫端不需要知道目前有哪些 Pod 正在運行

ConfigMap 與 Secret：管理設定和機密

應用程式通常需要資料庫位址、模型設定、API Key 等資訊

• ConfigMap： 儲存一般設定，例如服務名稱、非機密環境變數
• Secret： 儲存密碼、Token 或 API Key 等機密資料

兩者可以讓設定與 Container Image 分離，降低環境切換時的維護成本

但要注意，Kubernetes Secret 並不代表資料自動獲得完整加密保護

正式環境仍應配置適當的存取權限、加密機制與機密管理策略

HPA：自動水平擴展

HPA (Horizontal Pod Autoscaler) 可以依據 CPU、記憶體或已配置的自訂指標，調整 Deployment 的 Pod 數

這可以避免固定配置過多資源，也有助於服務應付流量變化

不過，RAG 系統不應只看 CPU 使用率

LLM API 的延遲、併發請求、佇列長度、供應商 Rate Limit，都可能成為系統瓶頸

若要依據這些指標自動擴展，還需要額外的監控、指標收集與自訂指標整合

RAG 系統如何導入 Kubernetes

當我們把它部署到 Kubernetes，就需要將應用程式、服務入口、共享資料與外部 API 分別規劃

這裡有幾個重要設計原則：

1. RAG API 儘量保持 Stateless
2. Redis 與 Vector Database 應採用共享服務
3. LLM API 通常是外部服務
4. 擴展 RAG API 不代表所有元件都會同步擴展

因此，導入 Kubernetes 不只是把 Docker 指令換成 YAML，而是重新思考應用程式如何部署、通訊、復原與擴展

此外，Readiness Probe 與 Liveness Probe 的用途不同：

• Readiness 失敗時，Pod 通常會被排除於 Service 的可用後端之外
• Liveness 失敗達到設定條件時，Kubernetes 會重新啟動容器

不要把兩者都設成只檢查外部 LLM API 是否可連線，否則外部供應商暫時故障時，可能造成大量 Pod 不必要地重啟

Kubernetes 的 Deployment 支援 Rolling Update，能逐步替換 Pod，減少一次關閉所有舊實例所造成的服務中斷

不過，Rolling Update 不等於保證零停機，實際效果仍取決於 Readiness Probe、更新策略、應用程式的啟動與關閉行為，以及外部相依服務的狀態

對 RAG 系統而言，更新時也要注意：

• Embedding Model 是否改變
• Vector Database Schema 是否相容
• Prompt Version 是否需要切換
• Cache Key 是否包含知識庫與模型版本
• 新版是否通過 RAG Evaluation Regression Test

如果新版程式需要不相容的資料庫結構，單純以 Container Image 也不一定能完整還原服務，因此資料遷移策略需獨立規劃

Kubernetes 如何提升 RAG 系統的可靠性

Kubernetes 提供多種機制協助維持服務狀態，但它無法自動解決所有應用程式問題

這些機制也有各自的限制

例如，Pod 能正常回應 HTTP 200，不代表 RAG 回答一定正確；Service 能正常分配流量，也不代表 Vector Search 的結果具有足夠的相關性

因此，Kubernetes 必須與先前建立的 Evaluation、Observability、Alerting、Tracing 和 Cost Tracking 搭配使用

服務成功啟動，不代表系統就能長期穩定運作

下一篇將探討如何定義 SLI、SLO 與 SLA，設計錯誤預算，並將系統可用性、回應延遲與 RAG 回答品質納入可靠性管理

讓智慧助理不只是能上線，更能持續提供可衡量、可追蹤、可信賴的服務