WrenAI 搭配 K8s HPA 弹性伸缩，把低谷期账单省掉 40-60%-编程实验室

WrenAI 搭配 K8s HPA 弹性伸缩，把低谷期账单省掉 40-60%

【免费下载链接】WrenAIGenBI (Generative BI) for AI agents, an open-source, governed text-to-SQL through an open context layer that turns natural-language questions into trusted dashboards, charts, and SQL across 20+ data sources, such as BigQuery, Snowflake, PostgreSQL, ClickHouse, Amazon Redshift, Databricks and more.项目地址: https://gitcode.com/GitHub_Trending/wr/WrenAI

早上九点，报表任务一起跑，平时 5-10 倍的 Text-to-SQL 请求一次性砸在 WrenAI 上，查询队列排到爆，LLM 推理的 pod 先顶不住。应对这种峰值，最笨的办法是把副本翻一倍，可账单就得全天候开着。你真正想要的，是让 HPA（Horizontal Pod Autoscaler，一个按指标自动加减 pod 副本数的组件）替你做弹性伸缩：高峰加副本，闲下来缩回去。

先认识 WrenAI 的三个组件和分工

WrenAI 是一个数据库 RAG 加 Text-to-SQL 的工具，把自然语言问题变成可信赖的 SQL、图表和看板，接得住 PostgreSQL、BigQuery、Snowflake、ClickHouse 等 20 多种数据源。服务拆成三块：

wren-ai-service是"大脑"，负责把自然语言翻译成 SQL，背着 LLM 推理和向量检索，峰值时资源吃得最狠
wren-engine是"手"，执行生成出来的 SQL，把结果捞回来
wren-ui是"脸"，你在这里提问、看图表

图中中部的 "Open Context Layer" 就是 WrenAI 的内核：MDL 语义建模、Memory（schema 索引加 NL-SQL 召回）、Governed access 都挂在它上面。落到 Kubernetes 上，需要被加副本、缩副本的正是这一层。

一句话看懂 HPA：餐厅经理临时叫人 🍜

把餐厅想象成平时只有两个服务员的店。客流突然坐满一百桌，经理立刻从备班池里调来五个人；散了场，再把人送走。HPA 就是这位"经理"：它隔一段时间看一眼 pod 的 CPU、内存利用率，超过阈值就加副本，持续低位就缩副本。

关键参数是 stabilizationWindowSeconds，大白话说就是"冷静期"。经理不会看到一瞬间的爆满就叫人，得确认热度持续了一阵才动手。没有这个窗口，副本会跟着每一次瞬时毛刺上下蹦。

WrenAI 的负载恰好是"瞬时爆满"这一型：一条复杂查询进来，LLM 推理和向量检索把 CPU、内存瞬间拉高，查询结束又回落。固定副本数两头都难受——常开则资源空转、账单持续上涨，中小企业最先扛不住；配少了，每天早上九点必堵。

3 步把 HPA 跑起来

第 1 步：配好 resources，否则 HPA 不认

HPA 算利用率要拿"requests"当分母。容器没配 requests，利用率就算不出来，HPA 永远纹丝不动。所以先在 deployment/kustomizations/base/deploy-wren-ai-service.yaml 里把资源段补齐：

resources: requests: cpu: 1000m memory: 2048Mi limits: cpu: 2000m memory: 4096Mi

带 LLM 推理的 wren-ai-service，内存建议不低于 4GB，不然复杂查询一来就是 OOM，扩出来的副本越多越乱。

第 2 步：写 HPA 清单

在 deployment/kustomizations/base/ 下新增 hpa-wren-ai-service.yaml，指向目标 Deployment。下面这份以 CPU 利用率 70% 作为扩容条件，再补一条同类型内存指标、阈值 80% 即可覆盖两个维度：

apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: wren-ai-service-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: wren-ai-service-deployment minReplicas: 1 maxReplicas: 10 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 70 behavior: scaleUp: stabilizationWindowSeconds: 60 policies: - {type: Percent, value: 50, periodSeconds: 120} scaleDown: stabilizationWindowSeconds: 300 policies: - {type: Percent, value: 30, periodSeconds: 300}

这份配置的读法：副本下限 1、上限 10；CPU 超过 70% 才动手，持续 60 秒后每 2 分钟最多扩 50%；负载持续 300 秒低位，才每 5 分钟缩 30%。缩容窗口故意比扩容长，防的是缩得比峰谷切换还快。

第 3 步：接进 kustomize，让 Service 分发流量

kustomize 是 K8s 的配置打包工具，deployment/kustomizations/kustomization.yaml 的 resources 列表决定哪些清单一起 apply，加一行即可：

resources: - base/hpa-wren-ai-service.yaml

流量侧还要接上：在 deployment/kustomizations/patches/service.yaml 里把 Service 改成 LoadBalancer 类型，并配置 IPv4/IPv6 双栈。之后云负载均衡器会把进来的请求摊给所有就绪副本，HPA 扩出的新 pod 通过就绪检查就开始接客，用户这边毫无感知。

上线之后：按现象查，按现象调 ⚡

先把监控接上：挂一个 ServiceMonitor 每 15 秒抓一次服务的 /metrics，再用 Prometheus 和 Grafana 盯着扩缩行为。接好之后，你大概率会碰到下面这几类现象。

HPA 完全不动，先别急着改阈值，跑一下 kubectl describe hpa wren-ai-service-hpa 看事件，原因十有八九是这两样：metrics-server 没跑起来，指标拉不到；或者容器没配 requests，利用率算不出来。两处修一处就能动。

副本数加了、流量却没进新 pod，查 Service 的标签选择器和 Deployment 的标签是否一致。两者对不上，新 pod 就是 Service 眼里的"隐形人"，把标签对齐即可。

缩容时丢状态、请求被掐断，多半是应用把会话状态攥在本地，或者数据写在了本地存储上，pod 一缩状态跟着没了。状态挪到外部存储、关掉会话亲和性、再配一个优雅关闭钩子，让在途查询跑完再退出。

还有一种是副本几分钟内反复伸缩的抖动，说明 stabilizationWindowSeconds 给短了，拉长窗口就好。高峰扩容嫌慢，把触发阈值调低一点或提高单次扩容比例；低谷嫌浪费，就把 maxReplicas 调低一些。

三个可选升级项

CPU、内存之外，可以把触发条件换成业务指标：用 Prometheus Adapter 暴露查询成功率，跌破 95% 就扩容——对"查询堵了"这类问题，它比 CPU 反应快。也可以做分级扩容：CPU/内存一层应付日常波动，查询延迟一层专管复杂查询突增。再挂一个 PodDisruptionBudget（规定滚动更新和缩容时最少可用的副本数），minAvailable 设 1，保证缩容过程中至少还有一个副本在服务。

快速开始：一条命令应用全部

高峰来了有副本，走了不烧钱，这就是这套改动的终点：低谷期成本降 40-60%，高峰期查询响应稳定压在 2 秒内。想自己试，先用git clone https://gitcode.com/GitHub_Trending/wr/WrenAI把仓库拉下来，再执行kubectl apply -k deployment/kustomizations。将来若峰值更难预测，再加基于历史模式的预测扩缩容或 GPU 弹性调度即可，眼下这一步已经够用。

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考