Buildbarn on Kubernetes：根据编译负载自动伸缩 Worker 的四种方案
把 Buildbarn 自身的负载指标，转化为 Kubernetes 的行动指令。
在 Kubernetes 上运行 Buildbarn 作为远端执行（Remote Execution）/ 远程缓存后端时，一个常见诉求是：根据 CI 编译任务的规模，动态调整 Worker 的数量，从而既扛得住编译高峰，又不在低谷期浪费资源。本文梳理了四种主流方案，并给出选型建议。
核心思路：把负载指标翻译成 K8s 行动
无论选择哪种方案，本质都是同一件事：
- 从
bb_scheduler暴露的负载指标中拿到"当前需要多少 Worker"这个信号； - 把这个信号转化为对 Kubernetes Deployment
replicas字段的调整； - （可选）当新增 Pod 因资源不足而
Pending时，再由节点级自动扩缩容补齐机器。
理解了这条主干，四种方案只是"由谁来执行翻译"的差异。
方案一：bb-autoscaler（最直接，官方出品）
bb-autoscaler
是 Buildbarn 社区官方提供的工具，专门用于根据负载自动调整 Worker 数量。它直接从 bb_scheduler 获取指标，并操作 Kubernetes Deployment 的副本数。
工作原理
- 获取指标：
bb-autoscaler通过 Prometheus 查询bb_scheduler暴露的负载指标。 - 计算副本数：使用 PromQL 函数（如
quantile_over_time()）计算所需的 Worker 数量。 - 执行扩缩：直接调整 Kubernetes Deployment 的
replicas字段。
实施步骤
- 部署 Prometheus：确保 Prometheus 已部署并能抓取
bb_scheduler的指标。 - 部署 bb-autoscaler：在集群中部署
bb-autoscaler服务。 - 配置扩缩策略：编写配置文件，定义如何根据 PromQL 查询结果计算目标副本数。
- 授予权限：为
bb-autoscaler的服务账号授予操作 Deployment 的 RBAC 权限。
方案二：Kubernetes HPA + 自定义指标（K8s 原生）
Kubernetes 的 Horizontal Pod Autoscaler（HPA）支持使用自定义指标进行扩缩容，可以将 Buildbarn 的负载指标暴露给 HPA。
工作原理
- 暴露指标：通过 Prometheus Adapter 将
bb_scheduler的指标注册为 Kubernetes 的自定义 API。 - 配置 HPA：创建 HPA 资源，引用该自定义指标并设置目标值。
- HPA 决策：HPA 周期性检查指标，计算所需 Pod 数量并调整 Deployment 的副本数。
实施步骤
- 部署 Prometheus 与 Prometheus Adapter：确保 Prometheus 能抓取
bb_scheduler指标，并通过 Adapter 暴露给 Kubernetes API Server。 - 创建 HPA 资源：编写 YAML 文件，指定
apiVersion: autoscaling/v2，在metrics中引用自定义指标。 - 测试验证：通过压测观察 HPA 是否按预期工作。
方案三：KEDA（事件驱动自动伸缩）
KEDA 是一个更高级的自动伸缩组件，可以基于各种事件源（包括 Prometheus）来驱动伸缩。
实施步骤
- 部署 KEDA：在集群中安装 KEDA。
- 创建 ScaledObject：定义 KEDA 的 ScaledObject 资源，指定触发器为 Prometheus，并配置查询语句和目标值。
- KEDA 决策：KEDA 会根据 Prometheus 指标计算并调整 Deployment 的副本数。
相比 HPA，KEDA 的优势在于可以缩容到 0、支持多种事件源、伸缩策略更灵活，代价是引入了新的 CRD 和控制器。
方案四：节点级自动扩缩容（弹性资源池）
前面三种方案解决的是 Pod 级扩缩容。而"弹性资源池"通常指的是 节点级自动扩缩容——Cluster Autoscaler 或 Karpenter 。这个方案需要与上述 Pod 级方案配合使用：
- Pod 级扩缩容：通过方案一、二或三，根据编译任务负载调整 Buildbarn Worker Pod 的副本数。
- 节点级扩缩容：当新增的 Worker Pod 因资源不足而处于
Pending状态时，Cluster Autoscaler 或 Karpenter 自动增加节点。 - 缩容：当 Worker Pod 被缩容后，空闲的节点也会被自动回收。
这种方式实现了 从任务负载 → Pod → 节点资源 的全链路弹性。
选型对比
| 方案 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| bb-autoscaler | 最直接，为 Buildbarn 量身定制，配置简单 | 需要部署额外组件 | 优先推荐，特别是希望快速实现功能时 |
| HPA + 自定义指标 | K8s 原生，生态成熟，无额外组件 | 配置自定义指标 Adapter 相对复杂 | 已有 Prometheus Operator 并熟悉其配置时 |
| KEDA | 功能强大，支持多种事件源，伸缩策略灵活，可缩容到 0 | 引入新的 CRD 和控制器，增加复杂度 | 有多种不同事件源需要统一管理时 |
总结与建议
综合来看，方案一（bb-autoscaler）是上手最快、最贴合需求的方案。 它是官方为 Buildbarn 量身定制的工具，配置链路最短。Buildbarn 官方文档也指出，在 Kubernetes 环境下，使用 HPA 配合自定义指标同样是一种选择。
如果集群里已经跑着 Prometheus Operator 且团队对自定义指标适配很熟，方案二（HPA）可以不引入额外组件，直接复用现有可观测性栈。如果未来还要把多种事件源（消息队列、队列长度等）纳入统一伸缩管理，那么方案三（KEDA）的扩展性更值得一次性投入。
无论选择哪种方案，核心都是 将 bb_scheduler 的负载指标作为决策依据，最终转化为对 Kubernetes Deployment 副本数的调整，从而实现根据 CI 编译规模动态调整 Worker 数量。再叠加节点级自动扩缩容，就能得到一条从编译任务负载到机器资源的完整弹性链路。