在 Agent Substrate 里用 HPA 伸缩 Actor 与 Worker
来源:dev.to — 2026-10-15
📋 概述
作者的出发点是伸缩的第一原则:你得手上有足够多的现成资源,能消化、吸收并调度你真正要跑的东西;对代理类负载来说就是「有没有足够内存去跑多 Actor 的 Worker」。文章用一套可复现实验讲清 Actor(代理运行的地方)、Worker 与 WorkerPool 的关系:Actor 部署后自动处于 suspended 状态,只在有活跃会话时才真正运行,不跑就不占 CPU 和内存,同时保持在「温」状态,所以恢复不用等几秒。实验里 WorkerPool 把每个 Worker 限制在 1Gi,而 Actor 模板要 768Mi,因此一台 Worker 永远放不下第二个 Actor:6 个 Actor 对 2 个 Worker 是 3:1,前两个能调度,第三个请求直接 504 超时并停在 parked 状态,直到有人释放 Worker。最后加上 WorkerPool 的 HPA,把副本上限设到 10,6 个 Actor 全部被调度起来,终端里能看到从 2/2 扩到 6/6,每个请求都返回 200。
🔑 核心要点
- Actor 的省资源设计:部署后自动处于 suspended,只有存在活跃会话才运行;同时保持「温」状态,避免冷启动要等好几秒。
- 内存是硬约束:WorkerPool 每 Worker 上限 1Gi,Actor 模板要 768Mi,所以第二个 Actor 永远放不下。
- 扩容前的表现很直观:6 个 Actor 对 2 个 Worker 是 3:1,第三个请求 504 超时并停在 parked 状态,直到有 Worker 释放。
- 加上 HPA 之后:副本上限设为 10,6 个 Actor 全被调度,终端从 2/2 扩到 6/6,请求全部返回 200。
- 他的收尾理由很实在:代理一旦挂了可能影响整个组织,所以伸缩不只是技术团队的事。
💡 金句
伸缩的第一条原则,是确保你手上有足够多的现成资源,能消化、吸收并调度你真正要跑的东西。
👍 0
👎 0
← 返回 dev.to 首页