Predicate筛选与Priorities评分两阶段调度算法及乐观绑定策略

[[状态共享双循环调度机制用调度缓存避免每次调度都远程轮询节点]]里 Scheduler Loop的核心工作分两步。第一步Predicate（一组节点过滤器） 解决”能不能运行”：通用过滤策略检查处理器/内存等资源是否够、主机端口 是否冲突、nodeAffinity是否匹配；卷过滤策略检查Volume是否冲突（如块 设备被同时挂到两个节点）或可用区域是否匹配，[[存储接入的三阶段模型 及PV控制器AD控制器Volume管理器的职责分工]]里Local PersistentVolume 的调度检查就在这里做；节点过滤策略检查污点与容忍度（Taint and Toleration，如默认Master节点不可调度就是靠给Master打污点实现的）以及 是否处于驱逐冷却期。第二步Priorities（打分规则，0-10分）解决”哪个最 恰当”：把Predicate筛出的候选节点集打分排序，如 LeastRequestedPriority（选处理器和内存空闲最多的节点，剩余越多分越高） 常和BalancedResourceAllocation（希望调度完各节点的处理器/内存/存储 分配比例尽量均衡，避免一种资源被大量分配另一种大量剩余的尴尬局面） 搭配用，此外还有ImageLocalityPriority、NodeAffinityPriority等。选定 节点后，调度器并不直接联系kubelet创建Pod，只是把Pod的nodeName字段 更新为目标节点名，kubelet监视这个字段变化自己接手后续——这个更新 过程用的是”乐观绑定”（Optimistic Binding）：先同步更新调度缓存里的 nodeName，再异步写etcd（这个操作叫Binding），如果最终调度成功，缓存 和etcd自然会一致；如果失败，则由Informer根据Pod变动清空这次没成功 创建的Pod的nodeName字段、重新同步进调度缓存，触发下一轮调度。这套 “先斩后奏、失败就回滚”的乐观策略，是为了不让”等待Pod真正创建完成”这个 可能耗时较长的过程拖累调度器本身的吞吐效率。