目標讀者：平台工程與多 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 尖峰。