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

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 从能调度走向调度得精细、调度得可控的演进路径调度 API 精细化细化调度器 API为多样化的基础设施和工作负载提供更多选项。具体抓手是持续推进 PodTopologySpread API 的改进并将同样的思路按标签键动态匹配迁移应用到 PodAffinity API 上细粒度重排队指令为开发者引入新的控制机制使其可以自定义Pod 应当如何、以及何时被重新入队的逻辑从而提升调度效率核心稳定 外部可扩展在稳住核心调度逻辑的同时增强调度器对外部组件的可扩展性。这三条主线与 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 编号与所对应的引入/进阶版本均以年度报告原文为准阶段KEP 编号主题版本Alpha3280抢占发生时保证 PodDisruptionBudgetGuarantee PodDisruptionBudget When Preemption Happensv1.27Alpha3633为 PodAffinity / PodAntiAffinity 引入 MatchLabelKeys 与 MismatchLabelKeysv1.29Beta3521Pod 调度就绪Pod Scheduling Readinessv1.27Beta3838Pod 可变调度指令Pod Mutable Scheduling Directivesv1.27Beta3902将 TaintManager 与 NodeLifeCycleController 解耦v1.29Beta4247面向高效重排队的 per-plugin 回调函数QueueingHintv1.28Stable2926Job 的可变节点调度指令Mutable Node Scheduling Directives for Jobsv1.27Stable3243滚动升级后仍尊重 PodTopologySpread 约束v1.292.1 Alpha 阶段为抢占与亲和性补上精细化能力KEP-3280v1.27Alpha关注抢占Preemption场景下的可靠性当调度器通过抢占其他 Pod 来为新 Pod 腾出空间时必须同时保证被抢占 Pod 所属工作负载的 PodDisruptionBudgetPDB约束不被破坏。这与年度报告提升工作负载可靠性的目标直接呼应补齐了抢占路径上最后一个容易造成可用性风险的细节。KEP-3633v1.29Alpha为 PodAffinity 与 PodAntiAffinity 引入matchLabelKeys与mismatchLabelKeys字段。这一思路与 PodTopologySpread API 的既有演进一脉相承调度时不再静态匹配 Pod 标签而是允许通过标签键动态参与亲和性计算让调度决策能够感知滚动更新等动态场景中的标签变化从而避免新老副本标签不一致导致的调度偏差。2.2 Beta 阶段调度时机与队列行为开始变得可控KEP-3521v1.27Beta引入Pod 调度就绪概念允许工作负载通过显式机制表明自身当前尚未准备好被调度调度器将据此推迟调度动作直到就绪条件满足为先创建资源、后放行调度的编排模式提供了原生支持。KEP-3838v1.27Beta提供Pod 可变调度指令能力对尚未完成调度的 Pod允许更新其调度指令类字段使调度约束可以在 Pod 排队等待期间被调整而无需删除重建 Pod。KEP-3902v1.29Beta将 TaintManager污点管理器从 NodeLifeCycleController 中解耦使其成为独立组件。这一架构调整减小了调度相关逻辑与节点生命周期控制器之间的耦合为后续独立演进、独立故障域隔离打下基础。KEP-4247v1.28Beta即年度报告中细粒度重排队指令主线在 KEP 层面的落地为调度队列引入 per-plugin 的 QueueingHint 回调让每个插件可以自定义哪些事件发生时、当前排队中的 Pod 是否应当被重新入队。这正是下文第三节将要展开讲解的内容也是 2023 年调度器内部机制最重要的变化之一。2.3 Stable 阶段两项能力正式毕业KEP-2926v1.27Stable让 Job 可以在运行期间更新 Pod 模板中的节点调度指令如节点亲和性、节点选择器等使批处理工作负载的调度约束具备运行时可变性。KEP-3243v1.29Stable解决滚动升级场景下的拓扑分布问题确保集群经历滚动升级Pod 标签随版本变化之后PodTopologySpread 的拓扑分布约束依然被正确尊重不会因新旧副本标签不一致而产生分布失衡。三、纵深解读 KEP-4247调度队列的三队列模型与重排队机制要理解 KEP-4247per-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-extensionWebAssembly 调度扩展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/schedulerscheduler-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 精细化的部分思路存在承接关系持续运行Batchwg-batch、Policywg-policy、Structured Loggingwg-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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考