By Jermine

☰

在 Buildbarn + Kubernetes 的分布式编译场景中，识别弹性节点并据此调整 Worker 行为，是构建弹性编译集群的关键一环。以下结合 Buildbarn 架构，给出完整的技术方案。

Buildbarn 架构速览

Buildbarn 分布式编译集群通常包含以下核心组件：

  • bb_scheduler：接收构建请求，维护操作队列，将任务分发给 Worker
  • bb_worker：实际执行编译任务，与 Scheduler 和 Storage 通信
  • bb_storage：提供 CAS（内容寻址存储）和 ActionCache
  • bb_runner：由 Worker 调起，实际运行构建动作

在 Kubernetes 上部署时，bb_worker 通常以 Deployment 形式运行，每个 Worker Pod 对应一个编译执行单元。

为什么 Buildbarn 需要识别弹性节点？

在弹性 Kubernetes 集群中，节点可能来自不同类型：

  • 常规节点：稳定的包年包月实例
  • 弹性节点：Spot 实例、抢占式实例，价格低但可能被回收

对于 Buildbarn 而言，识别节点类型后可以：

  1. 差异化的 Worker 配置：弹性节点上的 Worker 可设置更短的任务超时时间
  2. 优雅退出：节点被回收前，Worker 主动完成当前任务并停止接收新任务
  3. 成本可观测：不同节点类型的 Worker 上报不同标签，便于成本分析

Buildbarn Worker 识别弹性节点的方法

核心思路与通用方案一致：通过 Kubernetes Downward API 获取节点名称，再查询节点标签进行判断。

步骤一：在 Worker Pod 中注入节点名称

修改 bb_worker 的 Deployment 配置，添加环境变量：

 1apiVersion: apps/v1
 2kind: Deployment
 3metadata:
 4  name: bb-worker
 5spec:
 6  template:
 7    spec:
 8      containers:
 9        - name: worker
10          image: ghcr.io/buildbarn/bb-worker:latest
11          env:
12            - name: MY_NODE_NAME
13              valueFrom:
14                fieldRef:
15                  fieldPath: spec.nodeName

步骤二：容器内查询节点标签

Buildbarn Worker 启动脚本或 Sidecar 容器中，通过 Kubernetes API 查询节点标签：

1# 在 Worker 容器启动脚本中
2NODE_LABELS=$(kubectl get node $MY_NODE_NAME -o jsonpath='{.metadata.labels}')

步骤三：识别弹性节点标签

不同云厂商的弹性节点标签示例：

  • 阿里云 ACK：k8s.io/cluster-autoscaler: true
  • GKE：cloud.google.com/gke-spot: "true"
  • Karpenter：karpenter.sh/nodepool
  • AWS EKS：eks.amazonaws.com/nodegroup + Spot 相关的污点

步骤四：Worker 根据节点类型调整行为

识别后，bb_worker 可通过环境变量或配置文件调整：

  • 设置不同的 concurrency（并发数）
  • 弹性节点上的 Worker 设置更短的 execution_timeout
  • 启动时向 bb_scheduler 上报节点类型标签

与 Buildbarn 自动伸缩方案的整合

识别弹性节点后，可以结合以下方案实现从负载到 Worker，再到节点的全链路弹性。

方案一：bb-autoscaler（官方方案）

bb-autoscaler 从 bb_scheduler 的 Prometheus 指标获取负载，计算所需 Worker 数量。在 Kubernetes 环境下，可以扩展其能力：

  • 根据弹性节点标签，决定伸缩的 Worker Deployment
  • 弹性节点充足时优先扩容弹性 Worker，成本高时回退到常规 Worker

方案二：Kubernetes HPA + 自定义指标

通过 Prometheus Adapter 将 bb_scheduler 指标暴露给 HPA，HPA 根据负载调整 bb_worker 的 Deployment 副本数。配合节点标签识别：

  • 为弹性 Worker 和常规 Worker 分别创建 Deployment，打上不同标签
  • HPA 可分别设置不同的伸缩策略

方案三：Cluster Autoscaler / Karpenter 联动

当 HPA 或 bb-autoscaler 扩容 Worker Pod 后，如果节点资源不足：

  1. Pending 的 Worker Pod 触发 Cluster Autoscaler
  2. Cluster Autoscaler 根据节点池配置，优先扩容弹性节点池
  3. 新节点带有弹性标签，被新 Worker 识别

全链路弹性闭环：编译负载增加 → bb-scheduler 队列变长 → bb-autoscaler/HPA 扩容 Worker → Pending Pod 触发 Cluster Autoscaler → 弹性节点加入 → Worker 识别节点类型并适配行为

配置示例

Worker Deployment（带节点识别）

 1apiVersion: apps/v1
 2kind: Deployment
 3metadata:
 4  name: bb-worker-spot
 5  labels:
 6    worker-type: spot
 7spec:
 8  replicas: 0 # 由 HPA 控制
 9  template:
10    metadata:
11      labels:
12        worker-type: spot
13    spec:
14      containers:
15        - name: bb-worker
16          image: ghcr.io/buildbarn/bb-worker:latest
17          env:
18            - name: MY_NODE_NAME
19              valueFrom:
20                fieldRef:
21                  fieldPath: spec.nodeName
22            - name: WORKER_CONCURRENCY
23              value: "4" # 弹性节点可设置较低并发
24            - name: WORKER_TIMEOUT
25              value: "300s" # 弹性节点设置较短超时
26      # 优先调度到弹性节点
27      nodeSelector:
28        node-type: spot
29      tolerations:
30        - key: "spot"
31          operator: "Equal"
32          value: "true"
33          effect: "NoSchedule"

HPA 配置（基于自定义指标）

 1apiVersion: autoscaling/v2
 2kind: HorizontalPodAutoscaler
 3metadata:
 4  name: bb-worker-hpa
 5spec:
 6  scaleTargetRef:
 7    apiVersion: apps/v1
 8    kind: Deployment
 9    name: bb-worker-spot
10  minReplicas: 0
11  maxReplicas: 100
12  metrics:
13    - type: Pods
14      pods:
15        metric:
16          name: buildbarn_queue_length
17        target:
18          type: AverageValue
19          averageValue: "10"

总结

在 Buildbarn + Kubernetes 的分布式编译场景中，识别弹性节点的核心路径是：

Downward API 注入节点名 → 查询 Kubernetes API 获取节点标签 → 根据标签（如 cloud.google.com/gke-spot）判断节点类型 → Worker 据此调整行为

将节点识别能力与 bb-autoscaler/HPA + Cluster Autoscaler 联动，即可实现从编译任务负载到 Worker Pod，再到底层弹性节点的全链路自动伸缩，既保证编译高峰期的算力供给，又在低谷期最大化成本节约。