企业官网建设流程全解析

Kubernetes 是否适合部署 RAG 系统？什么时候需要它？

码海寻道 · 大模型、智能体与 RAG 工程组件系列第 54 篇

Kubernetes 能提供服务发现、滚动更新、故障恢复和自动扩缩容，但它也带来集群、网络、存储、监控和发布治理成本。RAG 系统是否需要 Kubernetes，应该由规模、可用性和团队能力决定。

一、先判断问题是什么

如果当前痛点是：

• 单机资源不够；
• API 和 Worker 需要独立扩容；
• 服务需要跨节点故障恢复；
• 发布需要滚动更新；
• 高峰流量变化明显；
• 团队已有 Kubernetes 平台；

那么可以评估 Kubernetes。如果只是想“让服务跑起来”，Docker Compose 可能已经足够。

二、RAG 组件并不都适合直接放进集群

无状态服务：API、前端、Worker 状态服务：PostgreSQL、Redis、Milvus、对象存储 外部服务：模型 API、托管数据库、S3/OSS

无状态服务通常容易部署和扩容；数据库和向量库需要持久卷、备份、升级和故障恢复经验。可以选择托管服务，而不是为了“全 Kubernetes”自行维护全部状态组件。

还要区分“在集群里运行”和“由团队负责运维”。PostgreSQL、Milvus、MinIO 等状态服务即使使用 Helm 部署，也需要专门的备份、容量、升级、故障和恢复责任人；没有这些能力时，托管服务往往比自行部署更稳妥。

三、Deployment、Service 和 Ingress

apiVersion:apps/v1kind:Deploymentmetadata:name:rag-apispec:replicas:2selector:matchLabels:app:rag-apitemplate:metadata:labels:app:rag-apispec:containers:-name:apiimage:registry.example.com/rag-api:2026.08.12ports:-containerPort:8000readinessProbe:httpGet:{path:/health/ready,port:8000}livenessProbe:httpGet:{path:/health/live,port:8000}resources:requests:{cpu:"500m",memory:"512Mi"}limits:{cpu:"2",memory:"2Gi"}

Deployment 管理 Pod 副本，Service 提供稳定访问，Ingress 或 Gateway 处理外部流量。镜像必须使用明确版本，不能依赖latest。

四、健康探针怎么设计？

Startup Probe

给启动慢的服务准备时间，避免刚启动就被误杀。

Readiness Probe

决定 Pod 是否接收流量。数据库不可用时，可以暂时不接收请求，但要避免依赖抖动导致全量摘除。

Liveness Probe

判断进程是否失活，需要足够保守，不能把业务下游短暂故障直接变成重启循环。

探针接口要轻量、可超时、不可依赖昂贵的全链路请求。Startup 保护慢启动，Readiness 控制是否接流量，Liveness 只处理进程级死锁；三者混用容易造成启动风暴或依赖抖动。

五、HPA 不是自动解决一切

HPA 可以根据 CPU、内存或自定义指标调整副本数。对 RAG，更有价值的指标可能是：

• API 并发请求；
• SSE 活跃连接数；
• Worker 队列深度；

HPA 指标还应结合最老任务年龄、下游 429、数据库连接池和向量库写入延迟。扩容前先确认模型配额、数据库连接和对象存储带宽，否则只是把瓶颈向下游转移。

• Embedding 任务积压；
• P95 延迟。

扩容 API 不一定能解决模型供应商限流；扩容 Worker 不一定能解决 Embedding 配额或向量库写入瓶颈。

六、RAG 服务如何拆分扩容

rag-api：面向用户，关注延迟和连接 rag-worker-parse：解析和 OCR，关注 CPU rag-worker-embed：Embedding，关注上游配额和批量 rag-worker-index：写入向量库，关注吞吐

不同 Worker 使用不同 Deployment、队列和资源限制，避免批量建库拖垮在线问答。

七、状态服务的选择

PostgreSQL、Redis、Milvus 和对象存储不应只因为“可以部署”就直接放进同一个集群。要评估：

• 存储类和 IOPS；
• 备份与恢复；
• 跨可用区；
• 升级和回滚；
• 运维团队经验；
• 数据合规与成本。

对小团队，API 和 Worker 上 Kubernetes、数据库使用托管服务，可能是更实际的组合。

八、滚动发布和回滚

发布前检查：

• 数据库迁移是否向后兼容；
• 新旧 API 是否能共存；
• Embedding/向量 Schema 是否兼容；
• Prompt 和模型版本是否可回滚；
• 新版本指标是否正常。

不要把代码回滚误认为数据和索引也能自动回滚。向量重建、文档版本和数据库迁移需要独立方案。

发布建议采用分批或金丝雀方式，并同时比较新旧版本的错误率、P95、Token 成本、召回质量和权限拦截情况。迁移、索引和配置变更要有明确的前向兼容窗口，不能只验证 Pod 能否启动。

九、什么时候不建议 Kubernetes？

• 只有单台服务器和低并发；
• 团队没有集群运维能力；
• 没有明确的弹性或高可用需求；
• 主要依赖托管模型和数据库；
• 复杂度收益无法覆盖成本。

这时使用 Docker Compose、托管容器平台或虚拟机部署，可能更容易交付和排障。

结语

Kubernetes 适合需要多服务编排、独立扩缩容、滚动更新和高可用治理的 RAG 系统，但它不是生产化的同义词。先区分无状态服务和状态组件，再由指标和团队能力决定是否引入。

下一篇将从零设计一个企业文档问答系统的总体架构和技术选型。

参考资料

1. Kubernetes 官方文档：Deployments
2. Kubernetes 官方文档：Probes
3. Kubernetes 官方文档：Horizontal Pod Autoscaling

本文为“码海寻道”原创技术文章。Kubernetes 版本、Ingress 实现和云厂商能力存在差异，生产部署请进行容量与故障演练。