[AI天生] kube-scheduler核心优化总结

发表于 2026-7-12 17:51:45

马上注册，结交更多好友，享用更多功能，让你轻松玩转社区。

您需要登录才可以下载或查看，没有账号？立即注册

×

一、团体架构演进

kube-scheduler 从早期的单体调理器演进到基于 Scheduler Framework 的插件化架构，核心优化思绪围绕镌汰锁竞争、提升缓存掷中率、并行化调理和低沉无效调理四个方向睁开。
1.1 调理流程概览

Pod 进入调度队列
↓
出队（Pop）
↓
调度循环（Scheduling Cycle）
├── PreFilter（前置过滤）
├── Filter（节点过滤/预选）
├── PostFilter（后置过滤/抢占）
├── PreScore（前置打分）
├── Score（节点打分/优选）
├── Reserve（预留资源）
└── Permit（许可）
↓
绑定循环（Binding Cycle）
├── WaitOnPermit（等待许可）
├── PreBind（前置绑定）
├── Bind（绑定）
└── PostBind（后置绑定）

复制代码

1.2 两个独立控制循环

kube-scheduler 内部有两个独立的控制循环：

调理循环（Scheduling Loop）：不停从队列中取出 Pod，为其选择最符合的节点。
节点/集群信息更新循环：通过 informer 监听 Node、Pod 等资源变革，实时更新调理缓存。

两个循环通过 scheduler cache 解耦，调理循环只读缓存，更新循环写缓存，克制了频仍的锁竞争。
二、调理队列优化

2.1 三种队列操持

kube-scheduler 维护三个 Pod 队列，各司其职：
队列作用数据结构activeQ（生动队列）存放期待调理的 Pod，按优先级排序堆（Heap）backoffQ（退避队列）存放调理失败后期待重试的 Pod，指数退避堆（Heap）unschedulableQ（不可调理队列）存放完全不可调理的 Pod，期待集群变革后重新入队Map + 双向链表2.2 Queue Hint（队列提示）

引入版本：Kubernetes v1.28 开始徐徐引入，v1.30+ 徐徐成熟。
核心头脑：传统方式下，任何集群变革（如节点新增、Pod 删除等）都会将 unschedulableQ 中的全部 Pod 全部移回 activeQ 重试，造成大量无效调理。Queue Hint 让每个 Filter 插件告诉调理器：哪些变革会影响我对 Pod 的调理决议，从而只移动真正大概调理乐成的 Pod。
工作机制：

// 每个 Filter 插件可以实现 EventsToRegister 方法
type FilterPlugin interface {
Filter(ctx context.Context, state *CycleState, pod *v1.Pod, nodeInfo *NodeInfo) *Status
EventsToRegister() []ClusterEvent
}

复制代码

每个插件声明本身关心的集群事故范例（如 NodeAdd、PodUpdate 等）
当集群发生变革时，调理器只叫醒那些受该变革影响的 Pod
大幅镌汰 unschedulableQ → activeQ 的无效搬迁

收益：在大规模集群中，unschedulable Pod 数量巨大时，Queue Hint 能显着低沉调理器负载，提升调理吞吐量。
2.3 队列间 Pod 倒换机制

Node 增加 / Pod 删除 / 资源变化等事件
↓
unschedulableQ 中受影响的 Pod（Queue Hint 过滤）
↓
根据是否在退避期决定：
├── 退避期内 → backoffQ
└── 退避期外 → activeQ
↓
backoffQ 到期后自动移入 activeQ

复制代码

三、调理缓存优化

3.1 Snapshot 快照机制

调理循环开始时，会从 scheduler cache 中 snapshot（拍快照），得到一份当前集群状态的只读副本。后续整个调理过程（Filter、Score 等）都基于这份快照举行，不再访问共享缓存。
上风：

无锁读取：调理过程中不必要加锁，大幅镌汰锁竞争
划一性：单次调理内看到的集群状态是划一的
并行安全：多个调理协程可以并行工作，各自持有本身的快照

3.2 缓存分层操持

schedulerCache
├── Node 缓存（节点信息、已分配资源）
├── Pod 缓存（已调度 Pod 的资源占用）
├── Assume 机制（预占缓存）
└── Snapshot（只读快照）

复制代码

3.3 Assume 机制

Pod 调理乐成后，在真正 Bind 之前，先在缓存中 Assume（假设） 该 Pod 已经绑定到节点上，更新节点的已分配资源。如许后续调理能立刻感知到该节点资源变革，不必要期待 API Server 的回调。
如果后续 Bind 失败，会调用 Forget 回滚 Assume 的效果。
四、预选（Filter）优化

4.1 并行化 Filter

对多个节点的 Filter 查抄是并行实验的，利用多核 CPU 提升预选速率：

// 并行对所有节点执行 Filter
workqueue.ParallelizeUntil(ctx, 16, int(allNodes), checkNode)

复制代码

默认并发度是 16（parallelism 参数），可通过设置调解。
4.2 节点短路（Short-circuit）

一旦某个 Filter 插件判定节点不通过，后续 Filter 不再实验
按固定次序实验 Filter，盘算量小的前置，快速清除不及格节点
节点数量较多时，接纳 nominatedNode 优先查抄机制

4.3 预选节点数量优化（percentageOfNodesToScore）

大规模集群中，不必要对全部节点都实验完备的预选+优选流程。调理器找到肯定比例的可调理节点后就克制预选，直接进入优选阶段。

默认计谋：动态盘算，节点越多，预选比例越低
100 节点以下：100%（全量预选）
5000 节点时：约 10%（500 个节点）
可通过 percentageOfNodesToScore 设置项调解

目标：在包管调理质量的条件下，镌汰不须要的盘算。
五、优选（Score）优化

5.1 并行化 Score

与 Filter 类似，对多个节点的 Score 盘算也是并行实验的。
5.2 归一化打分

每个 Score 插件输出的分数范围差异（有的 0-10，有的 0-100），调理器会将其归一化到 0-100 的同一区间，然后按权重加权求和。

// 归一化公式
normalizedScore = int64(score) * int64(MaxNodeScore) / int64(maxScore)

复制代码

5.3 常用打分插件及其权重

插件默认权重作用NodeResourcesBalancedAllocation1资源平衡度NodeResourcesFit1资源匹配度（支持 LeastAllocated / MostAllocated）PodTopologySpread2Pod 拓扑分布InterPodAffinity2Pod 间亲和/反亲和NodeAffinity1节点亲和性TaintToleration1污点容忍ImageLocality1镜像当地性六、Scheduler Framework 插件化

6.1 扩展点一览

Scheduler Framework 界说了多个扩展点，开发者可以通过实现插件接口来自界说调理逻辑，无需修改内核代码。
扩展点阶段分析QueueSort队列排序决定 Pod 在 activeQ 中的排序PreFilter前置过滤盘算 Pod 级别的元信息，供后续 Filter 利用Filter节点过滤判定节点是否满足 Pod 要求PostFilter后置过滤调理失败后实验，如抢占、降级PreScore前置打分盘算打分所需的公共信息Score节点打分为可调理节点打分排序Reserve资源预留Assume Pod 到节点前调用Permit允许答应/拒绝/延伸 Pod 的绑定PreBind前置绑定绑定前实验额外利用Bind绑定实验现实的绑定利用PostBind后置绑定绑定乐成后调用Unreserve预留回滚绑定失败时回滚 Reserve 利用6.2 多设置文件（Multi-profile）

kube-scheduler 支持同时运行多个调理设置文件（profile），每个 profile 可以：

有独立的插件列表和设置
有独立的调理队列
有独立的调理循环

差异范例的 Pod 可以选择差异的 schedulerName，走差异的调理逻辑，互不影响。
七、抢占（Preemption）优化

7.1 抢占流程

当高优先级 Pod 无法调理时，触发抢占逻辑：

选出全部大概的候选节点
盘算每个节点上必要驱逐的低优先级 Pod
选择代价最小的节点（驱逐 Pod 最少、优先级最低等）
驱逐选定的 Pod，将高优先级 Pod 调理上去

7.2 抢占优化点

候选节点筛选：只思量有低优先级 Pod 的节点
dry-run 抢占：在缓存中模仿抢占，不现实驱逐 Pod
nominatedNodeName：抢占乐成后标志候选节点，下次优先调理

八、性能调优参数

8.1 关键设置项

参数默认值分析kube-api-burst100API Server 哀求突发量kube-api-qps50API Server 哀求 QPSpercentageOfNodesToScore0（动态盘算）参加优选的节点比例schedulerNamedefault-scheduler调理器名称workers数量 = CPU 核数并行调理协程数8.2 大规模集群发起

调高 workers：多核呆板上增长并行调理协程数
低沉 percentageOfNodesToScore：集群很大时（>1000 节点），得当低沉预选节点比例
启用 Queue Hint：v1.28+ 启用，镌汰无效重调理
公道设置插件权重：根据业务场景调解，镌汰不须要的复杂盘算
分层调理：利用多 profile，差异业务走差异调理逻辑

九、核心优化总结

优化方向技能本事收益镌汰锁竞争Snapshot 快照、调理循环只读缓存调理过程无锁，吞吐提升并行化Filter/Score 并行实验、多 workers利用多核，紧缩单次调理时间低沉无效调理Queue Hint、percentageOfNodesToScore镌汰不须要的盘算和重调理插件化架构Scheduler Framework、多 profile机动扩展，不修改内核缓存优化Assume 机制、分层缓存实时感知资源变革，镌汰 API 调用智能重调理backoff 退避、unschedulableQ 分级克制失败 Pod 频仍重试kube-scheduler 的优化思绪本质上是经典的空间换时间（缓存、快照）、并行化（多核利用）和镌汰无效盘算（Hint、短路）三大范式在调理场景下的具体实践。