Spot Capacity Orchestrator  ·  View 17 of 32  ·  5 · Runtime

Placement Decision

Forty-two pending pods become a normalised claim, a plan that fills the floor first and respects every cap, and a batched launch of instances that boot already knowing their contract.

Editable source SVG draw.io All views
Kubernetes Demand intake Portfolio planner Fleet state Acquirer Nova Node agent 1. watch: 42 pods pending, contract T1 2. normalise: 168 vCPU · 672 GiB 3. claim delta for orders-daily 4. ranking r-8812 · contract · current units 5. 71 eligible pools in 9 groups 6. floor first: 30% on committed capacity 7. fill: ≤ 15% per pool, ≤ 30% per group 8. commit plan gen 5531 · depth premium 9. diff: 6 pools gain units 10. token budget · quota headroom 11. multi-create · tags sco:* · user-data 12. 9 instances building 13. boot: contract subset already on disk 14. node Ready · taint reclaimable Placement — From Pending Work to Diversified Capacity Steps 1 to 8 are the placement decision, p99 ≤ 10 s. The planner touches only the claim that changed, never the whole partition. v 1.0 · owner Compute Platform Architecture · date 2026-09

Decisions

  • Demand is normalised to vCPU, memory and accelerators before it reaches the planner. Asking for instance counts would lock a workload into one size and defeat diversification across sizes.
  • The planner is incremental. It re-plans a workload when its claim, its eligible pools' ranking or an exclusion changes, and leaves the rest of the partition alone, which is what keeps the decision under 10 seconds as the fleet grows.
  • Fill order is fixed: guaranteed floor first, from committed reservations; then reclaimable units by score, water-filled so no pool holds more than 15% and no correlation group more than 30%, across at least 8 pools.

Rate and quota

  • The acquirer checks quota headroom and draws from a token budget of 10 mutating calls a second per region before calling Nova, and uses multi-create so one call launches many instances of a pool. The budget holds during recovery too.

Omitted

  • Slurm demand takes the same path through slurmrestd; scale-down is the scheduler's idle timeout, after which the acquirer deletes the empty instance.
◀  Pool Scoring Pipeline All views Hard Notice to Drain  ▶
Solution Architecture v1.0 · Compute Platform Architecture · 2026-09 · 32 views · open source, fully on-premises17-placement-decision