目标读者：平台工程与多 AZ Mac 集群管理员。结论先行：用 KEDA 对齐构建队列深度伸缩 worker，用 OpenClaw 汇总网关金丝雀指标，失败时广播 Webhook 摘要。结构含决策矩阵、七步落地与三条 FAQ。请先回到 首页 确认节点区域，再串读 Flagger 金丝雀文 与 Nomad 构建锁文。
三大痛点：① ScaledObject 只盯 CPU，忽略 build_queue_depth，尖峰仍排队；② 金丝雀网关与 stable 共用技能包，canary 收到半套设定；③ 扩缩失败只打原始日志，值班无法在 60 秒内判断是否冻结晋升。下文用一张 KEDA／Flagger/Argo 对照表与七步清单把事件驱动金丝雀跑通。
KEDA ScaledObject 触发条件与构建队列关系
在 Mac 集群上，构建队列深度比 CPU 更能预测是否需要加 worker。建议以 Prometheus 或 OpenClaw 导出的 openclaw_build_queue_depth{tenant} 作为触发器，cooldownPeriod 覆盖最长单次构建（建议 300 秒），maxReplicaCount 受磁盘水位约束而非硬拉满。
| 触发器 | 阈值起点 | 与队列关系 |
|---|---|---|
| prometheus | depth ≥ 12 扩 1 副本 | 每 +8 depth 再加 1，上限受水位表 |
| cron | 夜间 02:00–06:00 | 强制缩至 minReplica=1，错峰 rsync |
| webhook | 队列卡死 > 900s | 广播摘要并冻结 scale-out |
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
name: openclaw-build-workers
spec:
scaleTargetRef:
name: build-worker
triggers:
- type: prometheus
metadata:
serverAddress: http://observer:9090
query: max(openclaw_build_queue_depth)
threshold: "12"
多可用区网关节点金丝雀切片
按 AZ + ROLE 切三层：全域 KEDA 与 OpenClaw 共享字段、区域层写入口与权重、租户层写技能包 digest。canary-gw 仅在通过探针后才接收 KEDA 新起的 worker 流量；stable-gw 保持 100% 基线直到权重台阶晋升。
指标探针（延迟、错误率）阈值
| 指标 | 阈值（基线） | 探针来源 |
|---|---|---|
| score | ≥94 允许 scale-out，<88 冻结 | OpenClaw readyz + doctor |
| 5xx 率 | ≤1.0% | canary-gw access 对比 stable |
| p95 延迟 | 较 stable 升幅 ≤15% | 网关合并口径 |
| queue lag | ≤ 120s | 构建队列最老任务年龄 |
ScaledObject 的 activation 应读 /keda/canary-score，返回 score、queue_lag、p95_delta、digest_sha256。勿与 Flagger 的 /flagger/canary-score 或 Rollouts 路径混用，避免令牌覆盖。
Webhook 失败摘要广播
扩缩失败、探针未过或队列卡死时，广播固定五元组：rollout, queue, node, reason, attempts。鉴权用双令牌重叠窗口（建议 12 分钟）。401 单独标「鉴权失败」；业务降级返回 200 + 低 score，避免 KEDA 把网络抖动当坏版本。
- 注册 ScaledObject 并绑定 Prometheus 触发器。
- 部署 OpenClaw observer 与
/keda/canary-score。 - 写入 X-OpenClaw-Token，校验令牌版本。
- 合并四类探针：路由、5xx、p95、queue lag。
- 金丝雀段冻结 maxReplica，仅允许权重晋升。
- 失败触发 Webhook 摘要，同 delivery id 60 秒内只推一条。
- 预发压深队列，验证 scale 与摘要同步回落。
技能包版本锁与回滚
金丝雀阶段必须锁定 skills.lock 的 SHA256 digest；KEDA 新起的 worker 在 digest 未验前不得挂载 canary 技能树。回滚时先降 maxReplicaCount 至 min，再还原 stable 技能包与网关权重，顺序不可颠倒。排程亲和请对照 Nomad 构建锁矩阵。
1TB/2TB 磁盘水位
构建暂存与 DerivedData 常把 1TB 盘提前打红；KEDA 扩缩必须读取同一水位脚本输出，红线时冻结 scale-out 并降 rsync bwlimit。
| 规格 | 黄线 | 红线 | KEDA 动作 |
|---|---|---|---|
| 1TB | 约 78% | 约 88% | 黄：maxReplica ×0.6；红：冻结扩缩 |
| 2TB | 约 72% | 约 84% | 黄：禁止新 canary worker；红：缩至 min |
与 Flagger/Argo 已有文差异化（强调 KEDA）
| 方案 | 驱动方式 | 适用场景 |
|---|---|---|
| KEDA | 队列深度/事件指标 | CI 尖峰、夜间退避、Mac worker 池 |
| Flagger | 固定权重台阶 + AnalysisRun | 网关版本渐进；见 姊妹文 |
| Argo Rollouts | 步进式 AnalysisRun | GitOps 镜像流；见 Rollouts 探针文 |
实务上建议 KEDA 管 worker 副本与构建队列，Flagger 或 Rollouts 管网关流量权重；两者共用 OpenClaw observer，但指标路径与令牌必须隔离。
金丝雀与扩缩 FAQ
- 问：KEDA 与 Flagger 能否共用端点？答：可共用 observer，路径必须分离，例如 /keda 与 /flagger。
- 问：队列飙升是否立刻拉满 maxReplica？答：受 cooldown 与磁盘水位约束，红线时冻结扩缩。
- 问：与 Rollouts 差异？答：Rollouts 重步进晋升；KEDA 重事件对齐队列，更适合 CI 尖峰。