原生双阶段完整调度流程
K8s 1.16 及更早版本,Pod 调度严格分为两大串行阶段,无任何可插入自定义逻辑的扩展位置。
遍历集群所有 Node,执行一系列布尔判断规则,淘汰不满足硬性约束的节点,任意一条 Predicate 失败则该节点直接丢弃,无加权、容错空间。
内置核心 Predicate 规则:
PodFitsResources节点剩余 CPU/内存资源满足 Pod 申请配额NodeSelector节点标签匹配 Pod 节点选择器NodeAffinity硬亲和硬性约束校验PodToleratesNodeTaintsPod 容忍度匹配节点污点PodFitsHostPorts节点端口不冲突NoDiskConflict存储卷资源无冲突
全部 Predicate 串行执行,只要一条校验失败,当前节点直接剔除候选列表。
对预选后剩余合格节点执行加权打分,每一类打分规则输出 0~10 区间分值,乘以固定权重累加得到节点总分,总分最高的节点作为调度目标。
原生内置 Priority 打分策略:
LeastRequestedPriority节点剩余资源越多分值越高,分散负载BalancedResourceAllocation均衡 CPU、内存占用比例NodeAffinityPriority节点软亲和偏好加分TaintTolerationPriority容忍污点越少分值越高ImageLocalityPriority本地存在容器镜像加分,拉取加速
打分完成后排序,取最高分 Node 执行绑定操作。
Predicate/Priority 架构四大不可解决的底层缺陷
仅支持新增自定义 Predicate 过滤规则、自定义 Priority 打分规则,无法干预调度全生命周期。无法在绑定前执行自定义资源预校验、无法在调度失败时自定义驱逐逻辑、无法在节点预选前做集群全局过滤。
所有 Predicate 全量执行完成后,才会进入 Priority 打分;无法在预选中途提前过滤低价值节点、无法基于打分结果反向微调预选逻辑,万节点集群场景下,完整两轮遍历会产生大量无效计算。
高优先级 Pod 抢占低优先级 Pod、节点资源不足驱逐逻辑硬编码在调度主流程,没有标准化扩展入口,企业多租户集群无法自定义抢占优先级、驱逐保护规则。
不存在预筛选、缓存、并行校验扩展点,每次调度 Pod 都需要全量遍历集群 Node,超大规模集群(5000+ Node)单次调度耗时急剧上涨,原生框架无优化切入点。