前言

首先我们来了解一下什么是Coscheduling和Gang scheduling。Wikipedia对 Coscheduling的定义是“在并发系统中将多个相关联的进程调度到不同处理器上同时运行的策略”。在Coscheduling的场景中，最主要的原则是保证所有相关联的进程能够同时启动。防止部分进程的异常，导致整个关联进程组的阻塞。这种导致阻塞的部分异常进程，称之为“碎片（fragement）”。
在Coscheduling的具体实现过程中，根据是否允许“碎片”存在，可以细分为Explicit Coscheduling，Local Coscheduling和Implicit Coscheduling。其中Explicit Coscheduling就是大家常听到的Gang Scheduling。Gang Scheduling要求完全不允许有“碎片”存在，也就是“All or Nothing”。

我们将上述定义的概念对应到Kubernetes中，就可以理解Kubernetes调度系统支持批任务Coscheduling的含义了。一个批任务（关联进程组）包括了N个Pod（进程），Kubernetes调度器负责将这N个Pod调度到M个节点（处理器）上同时运行。如果这个批任务需要部分Pod同时启动即可运行，我们称需启动Pod的最小数量为min-available。特别地，当min-available=N时，批任务要求满足Gang Scheduling。

为什么Kubernetes调度系统需要Coscheduling？

Kubernetes目前已经广泛的应用于在线服务编排，为了提升集群的的利用率和运行效率，我们希望将Kubernetes作为一个统一的管理平台来管理在线服务和离线作业。默认的调度器是以Pod为调度单元进行依次调度，不会考虑Pod之间的相互关系。但是很多数据计算类的离线作业具有组合调度的特点，即要求所有的子任务都能够成功创建后，整个作业才能正常运行。如果只有部分子任务启动的话，启动的子任务将持续等待剩余的子任务被调度。这正是Gang Scheduling的场景。

如下图所示，JobA需要4个Pod同时启动，才能正常运行。Kube-scheduler依次调度3个Pod并创建成功。到第4个Pod时，集群资源不足，则JobA的3个Pod处于空等的状态。但是它们已经占用了部分资源，如果第4个Pod不能及时启动的话，整个JobA无法成功运行，更糟糕的是导致集群资源浪费。