Kotaemon自动扩缩容配置：HPA基于QPS动态调整副本数
在企业级智能对话系统日益普及的今天，客服、虚拟助手等场景对系统的稳定性与响应能力提出了前所未有的高要求。想象一下：一场大促活动刚刚开始，成千上万的用户同时涌入客服通道发起咨询——如果后台服务无法快速应对这种流量洪峰，轻则响应延迟，重则服务雪崩。
传统的静态部署模式早已力不从心。固定数量的Pod面对波峰波谷明显的请求模式，要么资源长期闲置造成浪费，要么在高峰期不堪重负。而云原生时代给出的答案是：弹性伸缩。
Kubernetes 的 Horizontal Pod Autoscaler（HPA）正是实现这一目标的核心组件。它不再依赖人工干预或预设时间表，而是通过实时监控工作负载，动态增减应用实例，真正做到了“按需分配”。尤其对于像 Kotaemon 这类以检索增强生成（RAG）为核心的AI框架，其请求特征高度波动——一次复杂查询可能涉及向量检索、上下文拼接和大模型推理，耗时远高于普通API调用。在这种背景下，单纯依靠CPU或内存指标来驱动扩缩容往往会失真：短暂的高CPU使用率未必代表持续负载压力，反而可能导致误扩或震荡。
那么，有没有一种更贴近业务本质的伸缩依据？答案就是QPS（Queries Per Second）——每秒请求数。作为衡量系统吞吐能力最直接的业务指标，QPS 能够精准反映用户访问强度，成为驱动 HPA 决策的理想信号源。
将 QPS 与 HPA 结合，并应用于 Kotaemon 这样的生产级 RAG 框架，实际上构建了一个“感知-反馈-调节”的闭环控制系统。这个过程不仅仅是技术组件的堆叠，更是从架构设计到运维实践的一次深度协同。
要让这套机制跑起来，首先得解决一个问题：Kubernetes 原生并不知道什么是“QPS”。HPA 默认支持 CPU 和内存这类资源指标，但要让它理解业务层面的请求速率，就需要借助自定义指标体系。这正是 Prometheus + Prometheus Adapter 架构的价值所在。
整个数据链路可以概括为四个关键环节：
埋点采集
在 Kotaemon 应用入口处植入监控逻辑。例如，在 FastAPI 中间件中统计每次/query或/chat接口的调用次数。这里不需要复杂的分析，只需一个简单的计数器（Counter），记录累计请求数即可。暴露指标
使用 Prometheus 客户端库启动一个独立的 metrics 服务端口（如:8001/metrics）。这个端点会以文本格式输出当前所有监控指标，供外部抓取。由于它是独立于主服务运行的，即使主应用出现性能瓶颈，也不会影响指标上报。指标聚合
Prometheus Server 定期从各个 Kotaemon Pod 抓取/metrics数据。通过 PromQL 查询rate(http_requests_total[1m])，即可计算出过去一分钟内的平均请求速率，也就是我们所说的 QPS。rate()函数不仅能平滑瞬时波动，还能自动处理计数器重置问题，是非常成熟稳定的指标提取方式。注册为K8s指标
最后一步是让 Kubernetes “认识”这个QPS指标。Prometheus Adapter 作为中间桥梁，将 Prometheus 中的http_requests_total映射为 Kubernetes 可识别的自定义指标http_requests_per_second。一旦完成注册，该指标就可以被 HPA 直接引用。
完成上述准备后，就可以定义 HPA 策略了。以下是一个典型的配置示例：
apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: kotaemon-hpa namespace: ai-apps spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: kotaemon-deployment minReplicas: 2 maxReplicas: 10 metrics: - type: Pods pods: metric: name: http_requests_per_second target: type: AverageValue averageValue: "100" behavior: scaleUp: stabilizationWindowSeconds: 60 policies: - type: Percent value: 100 periodSeconds: 15 scaleDown: stabilizationWindowSeconds: 300 policies: - type: Percent value: 10 periodSeconds: 60这个配置看似简单，实则蕴含了大量工程经验。比如minReplicas: 2不只是为了容错，更是为了避免在低流量时段因单个异常请求导致频繁启停；而maxReplicas: 10则是对成本和集群容量的硬性约束。
更值得注意的是behavior字段的设计。扩容策略允许每15秒最多翻倍副本数——这是为了应对突发流量，确保系统能迅速“踩下油门”；而缩容则设置了长达5分钟的冷却窗口，且每次最多只减少10%。这种“快扩慢缩”的设计理念，有效防止了因短时负载下降导致的服务抖动，保障了用户体验的连续性。
在实际架构中，这套机制通常嵌入在一个更完整的系统流程里：
[用户客户端] ↓ HTTPS [Nginx Ingress] ↓ Service (ClusterIP) [Kotaemon Pod x N] ←→ [HPA Controller] ↓ 依赖调用 [向量数据库] ←→ [LLM Gateway] ↓ 指标上报 [Prometheus] ←→ [Prometheus Adapter] ↓ 可视化 [Grafana]Ingress 负责统一接入并负载均衡，Service 实现服务发现，Prometheus 持续抓取各 Pod 的 metrics，Adapter 将其转化为 K8s 自定义指标，最终由 HPA 控制器读取并决策是否扩缩。整个过程完全自动化，无需人工介入。
这种架构带来的好处是实实在在的。我们曾观察到某客户系统在晚间 QPS 从白天的 200+ 下降到不足 30，HPA 在确认趋势稳定后逐步将副本从 8 缩减至 2，节省了近 75% 的计算资源。而在次日早高峰来临前，随着请求量回升，新副本又迅速拉起，整个过程平滑无感。
当然，落地过程中也有一些细节值得推敲。例如，Kotaemon 启动时需要加载大模型或初始化向量索引，冷启动时间较长。如果不加以控制，HPA 扩容的新 Pod 可能在未就绪时就被注入流量，反而加剧延迟。因此，合理的readinessProbe配置必不可少，建议结合/health接口设置适当的初始延迟和探测间隔。
另一个常见误区是过度依赖单一指标。虽然 QPS 是核心驱动因素，但在某些情况下仍需辅助判断。例如，当 QPS 较低但 CPU 持续高位，可能是某个请求触发了低效算法或死循环；反之，QPS 很高但 CPU 利用率低，可能说明存在I/O等待或外部依赖瓶颈。因此，在生产环境中，建议采用多维指标协同策略，甚至可引入 KEDA 实现基于消息队列长度的事件驱动伸缩，进一步提升灵活性。
回到最初的问题：如何让智能对话系统既扛得住流量冲击，又不至于“空转烧钱”？答案已经清晰——通过 QPS 驱动的 HPA 自动扩缩容，Kotaemon 不仅实现了资源利用与服务质量之间的精细平衡，更迈出了运维智能化的关键一步。这种以业务指标为核心、自动化响应为手段的技术范式，正在重新定义现代 AI 应用的部署标准。
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
