解读

在国内 Docker 面试中，这道题常被用来考察候选人对 Swarm 集群调度策略的理解深度。面试官不仅想知道三种算法的字面含义，更希望听到你在资源利用率、高可用、故障域打散、实际业务场景之间的权衡思路。回答时要结合生产环境案例，体现“能调优、敢拍板”的能力。

知识点

1. Spread：默认算法，优先把容器均匀打散到各个节点，追求节点级高可用，但可能导致资源碎片。
2. Binpack：优先把容器塞满当前最拥挤的节点，最大化资源利用率，减少闲置节点，适合包年包月云主机场景，但单点故障风险上升。
3. Random：完全随机，零计算开销，适合压测或短时 Job，但不可控，国内生产几乎不用。

答案

“这三种都是 Swarm 的调度策略，差异体现在打分阶段的权重公式。
Spread 会给容器数最少的节点打最高分，保证各节点副本数接近，故障域最分散，国内金融、政府项目常用；缺点是 8G 内存的节点可能只跑 1G 业务，造成碎片。
Binpack 反过来，给已用资源最多但仍能容纳的节点打高分，把机器吃干榨尽，在阿里云预付费节点上能省 20% 成本；但节点挂掉时集中爆炸，必须配套PodDisruptionBudget与多可用区标签兜底。
Random 跳过打分，直接抽签，调度最快，适合凌晨拉起的灰度压测容器；生产环境若使用，会被 SRE 在复盘大会上点名批评。
选型时我会先看SLA 等级：核心支付链路透传 Spread，离线大数据用 Binpack，临时压测 Pod 用 Random，并通过docker service update --placement-pref动态切换，不需要重建集群。”

拓展思考

1. 国内云厂商常把宿主机 CPU 超卖与 Binpack 混用，需监控steal time，超过 15% 就自动迁移。
2. 自研调度器可二次开发：在 Spread 打分前加资源碎片率因子，在 Binpack 打分后加故障域反亲和硬约束，实现“碎片率 <10% 且 AZ 级打散”。
3. 面试加分项：提到K8s 的 Scheduler Framework已把这三类思想做成Score 插件，并指出Docker Swarm 的调度器是单线程 Go 程序，万节点规模下调度延迟会飙到 2s，从而自然引出迁移 K8s 的演进路线。