Kubernetes作业队列排序规则及资源受限场景调度机制

默认配置下，因集群资源上限进入Pending状态的Job，不会严格按照先进先出（FIFO）规则在资源释放后完成调度。
需要先明确：Kubernetes的实际调度单元是Job控制器创建的Pod，而非Job本身，调度队列里排序的是待调度的Pod对象。默认调度队列虽然会记录Pod的入队时间，但不会把入队时间作为唯一排序依据：

• 调度循环每次从队列取Pod时，会先跳过所有不满足节点硬性调度规则的对象（比如资源不匹配、节点亲和/反亲和不满足、污点容忍不符合要求），不会让这类暂时无法调度的Pod阻塞后面符合调度条件的Pod
• 同属资源不足导致Pending的Pod，优先级更高的对象会直接排到队列前列，和创建/入队时间无关
• 调度器还会参考资源本地性、调度公平性等维度做调度决策，比如和待释放资源位于同一节点、满足本地存储/缓存亲和的Pod，可能比更早入队的Pod优先完成绑定
• 如果Pod调度失败触发重试，会重新进入队列，排序位置也会动态调整，不会保留最初的入队顺序。

只有当集群所有待调度Job对应Pod的优先级完全一致、没有自定义调度规则、所有Pod都满足全部节点过滤条件的理想场景下，才会近似表现出FIFO的调度效果，但这不是Kubernetes承诺的强制行为，业务不能依赖这个默认特性保障作业执行顺序。

Kubernetes从原生能力到生态扩展，提供了多维度的作业排序调度能力：

• 优先级与抢占机制：这是原生最核心的调度排序规则。用户可以通过PriorityClass资源定义不同的优先级数值，绑定了高优先级PriorityClass的Pod会始终排在调度队列的前列；集群资源极度紧张时，高优先级Pod还会触发抢占逻辑，驱逐节点上已运行的低优先级Pod来腾出资源，保障高优先级作业先运行。
• 可扩展的调度队列插件：默认调度器的队列排序逻辑是插件化的，支持用户通过自定义调度插件替换默认排序规则，可实现严格FIFO、按作业权重排序、按作业预计运行时长排序等自定义逻辑，满足不同业务的调度需求。默认内置的排序插件核心排序维度是Pod优先级，同优先级下才会参考入队时间排序。
• 跨来源调度公平性规则：原生调度器内置了队列公平性逻辑，会避免单个命名空间、单个用户提交的大量Pod长期独占调度队列，保证不同业务来源的Pod都有均等的调度机会，不会出现单个用户提前提交海量作业就堵死整个队列的情况。
• 批量作业生态的队列能力：如果是大数据、AI训练这类批量作业场景，搭配Volcano、kube-batch这类批量调度扩展组件，还可以实现更复杂的队列能力：比如划分多级资源队列、给不同队列配置固定资源配额、支持同队列内FIFO/优先级/DRF（主导资源公平）等多种排序策略、支持Gang调度（同作业所有Pod凑齐资源才统一调度）等，适配复杂的批量作业调度需求。

内容的提问来源于stack exchange，提问作者cellardog