企业官网建设流程全解析

Kubernetes SIG Scheduling 2023 年度技术盘点：调度 API 精细化、队列重排与子项目生态演进

【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community

本文以社区仓库中 SIG Scheduling 2023 年度报告 为骨架，系统梳理该 SIG 在 v1.27、v1.28、v1.29 三个版本周期内推进的 8 项 KEP 及其 Alpha/Beta/Stable 状态，深入解读调度 API 精细化、细粒度重排队、调度器核心稳定与外部可扩展三大工作主线，并结合仓库内的调度器开发文档给出源码级参考；读完后你将掌握 2023 年 kube-scheduler 的关键能力演进脉络，以及继续深挖这些特性所需的仓库内材料路径。

一、2023 年三条工作主线：从年度报告中提炼的信号

SIG Scheduling 在 2023 年度报告中明确提出了三项重点投入方向，它们共同描绘了 kube-scheduler 从"能调度"走向"调度得精细、调度得可控"的演进路径：

1. 调度 API 精细化：细化调度器 API，为多样化的基础设施和工作负载提供更多选项。具体抓手是持续推进 PodTopologySpread API 的改进，并将同样的思路（按标签键动态匹配）迁移应用到 PodAffinity API 上；
2. 细粒度（重）排队指令：为开发者引入新的控制机制，使其可以自定义"Pod 应当如何、以及何时被（重新）入队"的逻辑，从而提升调度效率；
3. 核心稳定 + 外部可扩展：在稳住核心调度逻辑的同时，增强调度器对外部组件的可扩展性。

这三条主线与 SIG Scheduling Charter 中定义的职责范围一脉相承——该 SIG 负责所有"为 Pod 做出放置决策"的组件，构建调度器与调度特性，让用户能够自定义 Pod 在集群节点上的放置，以提升工作负载可靠性、资源利用效率并执行放置策略。

二、2023 年度 KEP 全景：v1.27 / v1.28 / v1.29 的三级状态分布

2023 年横跨 Kubernetes v1.27、v1.28、v1.29 三个版本，SIG Scheduling 提交的 KEP 分布在 Alpha、Beta、Stable 三个成熟度阶段，完整清单如下（KEP 编号与所对应的引入/进阶版本均以年度报告原文为准）：

2.1 Alpha 阶段：为抢占与亲和性补上精细化能力

KEP-3280（v1.27，Alpha）关注抢占（Preemption）场景下的可靠性：当调度器通过抢占其他 Pod 来为新 Pod 腾出空间时，必须同时保证被抢占 Pod 所属工作负载的 PodDisruptionBudget（PDB）约束不被破坏。这与年度报告"提升工作负载可靠性"的目标直接呼应，补齐了抢占路径上最后一个容易造成可用性风险的细节。

KEP-3633（v1.29，Alpha）为 PodAffinity 与 PodAntiAffinity 引入matchLabelKeys与mismatchLabelKeys字段。这一思路与 PodTopologySpread API 的既有演进一脉相承：调度时不再静态匹配 Pod 标签，而是允许通过"标签键"动态参与亲和性计算，让调度决策能够感知滚动更新等动态场景中的标签变化，从而避免新老副本标签不一致导致的调度偏差。

2.2 Beta 阶段：调度时机与队列行为开始变得可控

KEP-3521（v1.27，Beta）引入"Pod 调度就绪"概念，允许工作负载通过显式机制表明自身当前尚未准备好被调度，调度器将据此推迟调度动作，直到就绪条件满足，为"先创建资源、后放行调度"的编排模式提供了原生支持。

KEP-3838（v1.27，Beta）提供"Pod 可变调度指令"能力：对尚未完成调度的 Pod，允许更新其调度指令类字段，使调度约束可以在 Pod 排队等待期间被调整，而无需删除重建 Pod。

KEP-3902（v1.29，Beta）将 TaintManager（污点管理器）从 NodeLifeCycleController 中解耦，使其成为独立组件。这一架构调整减小了调度相关逻辑与节点生命周期控制器之间的耦合，为后续独立演进、独立故障域隔离打下基础。

KEP-4247（v1.28，Beta）即年度报告中"细粒度（重）排队指令"主线在 KEP 层面的落地：为调度队列引入 per-plugin 的 QueueingHint 回调，让每个插件可以自定义"哪些事件发生时、当前排队中的 Pod 是否应当被重新入队"。这正是下文第三节将要展开讲解的内容，也是 2023 年调度器内部机制最重要的变化之一。

2.3 Stable 阶段：两项能力正式毕业

KEP-2926（v1.27，Stable）让 Job 可以在运行期间更新 Pod 模板中的节点调度指令（如节点亲和性、节点选择器等），使批处理工作负载的调度约束具备运行时可变性。

KEP-3243（v1.29，Stable）解决滚动升级场景下的拓扑分布问题：确保集群经历滚动升级（Pod 标签随版本变化）之后，PodTopologySpread 的拓扑分布约束依然被正确尊重，不会因新旧副本标签不一致而产生分布失衡。

三、纵深解读 KEP-4247：调度队列的三队列模型与重排队机制

要理解 KEP-4247"per-plugin 重排队回调"解决了什么问题，需要先了解 kube-scheduler 调度队列的底层设计。仓库中的 调度队列机制文档 给出了完整说明，其核心是三队列模型：

• activeQ（活动队列，堆实现）：为立即调度提供 Pod，默认堆顶是优先级最高的 Pod，顺序可通过 QueueSort 扩展点定制；
• podBackoffQ（退避队列，堆实现）：存放调度失败但预期最终能成功的 Pod（例如等待存储卷创建完成），按退避超时最短者优先；退避时长随失败次数指数增长，initialBackoff与maxBackoff可配置（默认分别为 1 秒与 10 秒）；
• unschedulableQ（不可调度队列，map 实现）：存放调度失败且未被任何"移动请求（move request）"触及的 Pod。

kube-scheduler 调度队列中 Pod 在三队列间的流转关系

后台有两个周期性的 flush 协程负责把 Pod 送回活动队列：flushUnschedulableQLeftover每 30 秒将不可调度队列中停留超过 30 秒的 Pod 重新尝试（最坏情况下一个 Pod 需要最多 60 秒才能被移动）；flushBackoffQCompleted每秒将退避到期的 Pod 移入活动队列。此外，节点新增/更新、Pod 删除等集群事件会触发"移动请求"，通过MoveAllToActiveOrBackoffQueue将相应 Pod 迁回活动或退避队列，并记录当时的调度周期号moveRequestCycle——如果 Pod 恰好在移动请求发出的同一周期内调度失败，它会被直接送入退避队列而非不可调度队列，从而更快获得重试机会。

这套机制的痛点在于：重排队行为是全局、粗粒度的。任何一次事件都可能把整批 Pod 从不可调度队列搬回活动队列，造成不必要的重复调度尝试。KEP-4247 引入的 QueueingHint 正是针对这一痛点：让每个插件提供回调函数，精确告知调度队列"本插件关心的某类事件发生后，哪些 Pod 值得重新入队"，从而把"何时重排、为何重排"的决策权下放给插件。这与年度报告所述"引入新控制机制，让开发者实现自定义的 Pod（重）入队时机逻辑"完全对应。社区文档也明确提示：默认的最大退避时间（10 秒）对于高频失败的负载可能过短，建议按工作负载特征调大maxBackoff，避免活动队列被反复失败的 Pod 淹没——这一调优建议在引入细粒度重排队后依然适用。

四、调度循环与框架扩展点：理解"核心稳定 + 外部可扩展"

年度报告的第三条主线是"稳定核心调度，同时增强外部组件可扩展性"。要理解这条主线，可以对照仓库中的 调度器代码层级总览：

kube-scheduler 的主循环由**调度周期（scheduling cycle）与绑定周期（binding cycle）**组成。调度周期依次执行：从队列取出下一个 Pod → 运行调度算法 → 若失败则通过 PostFilter 插件尝试抢占 → 成功后执行AssumePod写入调度缓存，并按序运行Reserve、Permit扩展点；绑定周期则按WaitOnPermit→PreBind→Bind→PostBind的顺序执行，任一环节失败都会触发所有 Reserve 插件的Unreserve回滚。调度算法在 PreFilter/Filter 阶段并行过滤节点，在 PreScore/Score/NormalizeScore 阶段并行打分并计算加权总分，最终选出最优节点。

kube-scheduler 调度循环、缓存、队列与框架的组装关系

这套以扩展点（extension point）为核心的 Scheduling Framework 设计，正是"核心稳定 + 外部可扩展"的基石：内置插件与外部插件通过统一的Plugin工厂函数注册进框架，每个 profile 拥有独立的插件集合实例（共享 informer 与事件记录器）。年度报告中 2023 年新增的子项目kube-scheduler-wasm-extension正是这条主线的最新注脚——它允许开发者把调度扩展插件编译为 WebAssembly 模块加载进调度器，进一步降低了外部扩展的构建与分发成本。若需要为插件增加可配置参数，仓库中的 Scheduler Framework 插件开发文档 提供了从KubeSchedulerConfiguration参数结构定义、默认值设置（SetDefaults_*）、运行时校验（Validate*）到代码生成（hack/update-codegen.sh）的完整链路参考。

五、子项目与工作组生态变化：新增、退役与持续演进

5.1 子项目（Subprojects）状态

年度报告记录了 2023 年子项目列表的三类变化：

• 2023 年新增：kube-scheduler-wasm-extension（WebAssembly 调度扩展）；
• 2023 年退役：kube-batch（批处理调度相关子项目退出 SIG 维护列表，面向队列作业调度的kueue仍在持续维护中）；
• 持续维护：cluster-capacity、descheduler、kube-scheduler-simulator、kueue、kwok、scheduler（即 kube-scheduler 本体）、scheduler-plugins。

从当前 SIG Scheduling README 的子项目列表可以看到生态的延续：scheduler子项目的 OWNERS 指向 Kubernetes 仓库中的cmd/kube-scheduler与pkg/scheduler；scheduler-plugins、descheduler、kwok、kueue、kube-scheduler-simulator、cluster-capacity等均在 kubernetes-sigs 组织下持续演进，后续又陆续补充了dra-driver-topology、scheduler-library等新成员。

5.2 工作组（Working Groups）状态

• 2023 年退役：Multitenancy（对应归档目录 archive/wg-multitenancy，其多租户工作与年度报告中调度 API 精细化的部分思路存在承接关系）；
• 持续运行：Batch（wg-batch）、Policy（wg-policy）、Structured Logging（wg-structured-logging）。

这些工作组覆盖了批处理调度语义、调度策略、结构化日志等与调度器可靠性、可观测性密切相关的横切主题。

六、社区沟通与运营：2023 年的对外透明化动作

年度报告还记录了 SIG 的社区活动与运营状态：

• 社区级更新：SIG 在 KubeCon EU 2023 与 KubeCon NA 2023 上分别做了两次社区同步分享，向整个 Kubernetes 社区通报调度器的工作进展；
• 运营检查清单：2023 年 SIG 完成了全部运营任务，包括审阅并更新 README 与 CONTRIBUTING.md、审阅并更新 sigs.yaml 中的子项目列表及其 OWNERS 文件、核对 SIG 领导者（chairs、tech leads 与子项目负责人）的准确性与活跃度、并在 README 中链接/更新 2023 年会议纪要与录像。这些动作遵循 SIG 治理规范 的年度例行要求，保证治理信息对社区始终透明、准确。

七、结语：从年度报告看调度器的 2023 演进坐标

综合来看，SIG Scheduling 2023 年的工作可以浓缩为三个关键词：精细化（PodTopologySpread 与 PodAffinity 的标签键动态匹配）、可控化（调度就绪门控、可变调度指令、per-plugin 重排队回调）、可扩展化（TaintManager 解耦、wasm 扩展子项目落地）。其中 v1.28 的 KEP-4247 与 v1.29 的 KEP-3633 代表了调度器从"全局粗粒度重排队"走向"插件自治重排队"、从"静态标签匹配"走向"动态键匹配"的长期方向，而 调度队列文档 与 调度器架构文档 则为深入这些特性提供了完整的源码级地图。对于希望追踪调度器演进或基于 Scheduling Framework 构建自定义调度能力的开发者，从年度报告中的 KEP 清单出发、再对照仓库内的开发文档逐项深入，是一条高效的学习路径。

【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community