第一章：主流调度框架对比——Kubernetes、Slurm、HTCondor、YARN

各位同学，咱们今天聊聊调度框架的选择。说实话，这问题我每年都会被问到几十次。选错了框架，后面运维起来真是欲哭无泪。我见过不少团队，一开始图省事随便选一个，结果业务一上来，调度器成了瓶颈，整个集群都在骂娘。

所以这一章，咱们把四个主流框架——Kubernetes、Slurm、HTCondor、YARN——掰开揉碎了讲清楚。不搞虚的，直接说人话。

1.1 为什么需要调度框架？

说白了，调度框架就是帮你在多台机器上分配任务的东西。你想想看，你有100台服务器，1000个任务要跑。谁先跑？跑在哪台机器上？资源不够了怎么办？机器挂了怎么办？

这些破事，调度框架帮你搞定。

我个人习惯把调度框架分成两类：在线服务型和离线批处理型。前者要求响应快、高可用，比如Kubernetes；后者追求吞吐量、资源利用率，比如Slurm和HTCondor。YARN嘛，它是个混血儿，但更偏向批处理。

1.2 四大框架速览

先给个总览表格，方便你快速对比：

框架	出身	核心定位	调度粒度	典型场景
Kubernetes	Google（Borg）	容器编排	Pod（容器组）	微服务、在线服务、CI/CD
Slurm	HPC社区	高性能计算	Job（作业）	科学计算、仿真、AI训练
HTCondor	威斯康星大学	高吞吐计算	Job（作业）	计算密集型、网格计算
YARN	Apache/Hadoop	资源管理	Container（容器）	大数据批处理、Spark/MapReduce

嗯，这里要注意：YARN的Container和Kubernetes的Pod不是一回事。YARN的Container更像是一个资源隔离单元，而Pod是应用部署的最小单位。我刚开始学的时候也搞混过。

1.3 Kubernetes：云原生的调度之王

Kubernetes，简称K8s。现在几乎成了容器调度的代名词。它的架构核心是控制面（Control Plane）和工作节点（Worker Node）。

控制面里有个关键组件叫Scheduler，它负责决定Pod跑在哪台机器上。调度策略包括：

• 资源过滤：先筛掉不满足CPU、内存要求的节点
• 优先级打分：对剩余节点打分，选最优的
• 亲和性/反亲和性：比如让两个Pod尽量靠近，或者强制分开

我在项目中遇到过一个问题：某个AI推理服务，Pod总是调度到同一台机器上，导致那台机器负载过高。后来发现是默认调度策略没考虑节点负载均衡。解决办法是加了podAntiAffinity规则，强制Pod分散部署。

1.4 Slurm：HPC领域的常青树

Slurm，全称Simple Linux Utility for Resource Management。名字叫Simple，其实一点都不简单。它是高性能计算（HPC）领域的标配。

Slurm的架构是典型的主从模式：

• slurmctld：中央调度器，负责管理作业队列和资源分配
• slurmd：工作节点守护进程，执行任务
• sacct：记账工具，记录作业资源使用情况

调度策略上，Slurm支持多种算法：

• FIFO：先来先服务，简单粗暴
• Backfill：回填调度，提高资源利用率
• Gang：时间片轮转，适合多用户共享

我个人习惯用Backfill模式。为什么呢？因为FIFO模式下，一个大作业堵在前面，后面一堆小作业干等着。Backfill允许小作业“插队”，只要不影响大作业的预期启动时间就行。这招在混部场景下特别好用。

1.5 HTCondor：高吞吐计算的隐形冠军

HTCondor，名字有点怪，但它在高吞吐计算（High Throughput Computing）领域是绝对的王者。和Slurm追求“快”不同，HTCondor追求“多”——它擅长管理大量、松耦合的作业。

HTCondor最牛的特性是资源匹配（ClassAd机制）。每个节点和作业都有一组属性描述，调度器根据这些属性做匹配。比如：

• 作业要求“GPU数量 >= 2”
• 节点声明“GPU数量 = 4，显存 = 16GB”
• 匹配成功，作业调度到该节点

这种机制非常灵活。我记得有一次，用户需要作业跑在特定CPU型号的机器上。用Slurm得改分区配置，用HTCondor只需要在作业描述里加一行Requirements = (CpuModel == "Intel Xeon 6248")，搞定。

1.6 YARN：大数据生态的资源管家

YARN，全称Yet Another Resource Negotiator。它是Hadoop 2.0引入的资源管理框架，专门为大数据批处理设计。

YARN的架构分为三层：

• ResourceManager（RM）：全局资源调度器，负责分配资源
• NodeManager（NM）：节点代理，管理Container生命周期
• ApplicationMaster（AM）：每个应用一个，负责任务调度和容错

调度策略有三种：

• FIFO Scheduler：简单队列，不推荐生产使用
• Capacity Scheduler：按队列分配资源，支持弹性
• Fair Scheduler：公平调度，保证每个用户/队列获得等量资源

我建议生产环境用Capacity Scheduler。为什么呢？因为Fair Scheduler虽然公平，但资源利用率低。Capacity Scheduler允许你设置最小和最大资源，既保证核心业务，又允许空闲资源被其他任务使用。

1.7 框架对比总结

说了这么多，到底怎么选？我画了一张图，帮你理清思路：

总结一下我的个人经验：

• 跑在线服务：别犹豫，直接上Kubernetes。生态好，社区活跃，坑少。
• 跑HPC科学计算：Slurm是首选。MPI作业、GPU集群调度，Slurm最成熟。
• 跑高吞吐批处理：HTCondor。尤其是你有大量异构节点、或者想利用空闲桌面机。
• 跑大数据生态：YARN。Spark、Hive、MapReduce原生支持，省心。

当然，现实世界没这么简单。我见过不少团队混用多个调度器。比如用Kubernetes跑在线服务，用Slurm跑AI训练，中间通过统一资源池管理。嗯，这又是另一个话题了。