企业官网建设流程全解析

Kubernetes SIG Scheduling 2022 年度报告解读：PodTopologySpread 精细化、调度器扩展钩子与子项目版图

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

SIG Scheduling（调度兴趣小组）是 Kubernetes 社区中负责 Pod 放置决策相关组件的 SIG，其 2022 年度报告（sig-scheduling/annual-report-2022.md）系统记录了该年度的工作重点：PodTopologySpread API 的可控性增强、面向外部调度器的集成钩子、一批 KEP 从 Beta 走向 Stable，以及 Kueue、KWOK 等新子项目的加入。本文以这份年度报告为骨架，结合仓库内的 charter.md、README.md、sigs.yaml 与报告生成模板 sig_report.tmpl，逐项解读 2022 年调度领域的真实进展，帮助读者理解 kube-scheduler 生态在过去一年里"做了什么、为什么做、做到什么程度"。

SIG Scheduling 的定位与年度报告的价值

根据 SIG Scheduling Charter，SIG Scheduling 负责"做出 Pod 放置决策的组件"，其范围包括调度相关特性（如 Node Affinity）、kube-scheduler 的性能与可扩展性（与 SIG Scalability 协作）、调度可靠性、Pod 调度 API（与 SIG API Machinery 协作）以及 Pod 调度策略（与 SIG Auth 协作），同时明确将网络管理、持久化存储管理、资源配额与准入策略执行列为范围之外。

年度报告是 Kubernetes 社区治理体系的一部分。从 sig_report.tmpl 可以看到，该模板由 generator 支撑，要求各 SIG 回答"本年度值得强调的工作""未在 KEP 中跟踪的举措""KEP 工作进展""子项目与工作组变化""运营检查清单"等结构化问题，其中 KEP 列表还可从 kubernetes/enhancements 仓库的元数据自动生成。因此，2022 年度报告既是该 SIG 的年度工作总结，也是观察 kube-scheduler 功能演进的权威窗口。

2022 核心举措：为 Pod 放置决策增加更细粒度的控制

报告开篇列出的两项重点工作中，第一项是PodTopologySpread API 的改进——"增加更多旋钮（knobs）来控制散布行为，引入了 minDomains 和 matchLabelKey"。第二项是为外部调度器集成简化而增加更多钩子（mutable pod scheduling directives、pod scheduling readiness）。这两项共同指向一个趋势：让集群管理员和平台构建者在"默认调度器行为"之外，拥有更精细的放置控制权和更开放的扩展点。

PodTopologySpread 增强：minDomains 与 matchLabelKeys

PodTopologySpread 用于把一组 Pod 均匀分布到不同拓扑域（如 zone、node）上，其核心机制是计算各拓扑域中匹配 Pod 的数量，并与 maxSkew 对比来决定放置位置。2022 年该 API 新增的控制旋钮包括：

• minDomains：允许用户指定"参与均匀分布的最小拓扑域数量"。当集群中实际可用的拓扑域少于该值时，Pod 不再被集中塞入少数几个域，而是尽量均匀地铺开，避免小集群场景下负载倾斜。该能力对应 KEP-3022（Tuning the number of domains in PodTopologySpread），报告显示其于 v1.25 进入 Beta。
• matchLabelKeys：通过指定一组 Pod 标签键，让 PodTopologySpread 在计算 skew 时只考虑标签键取值与自身一致的 Pod，从而将"与自己同类的 Pod"纳入散布计算。典型场景是排除刚刚创建、尚未完成启动的 Pod，避免它们干扰已有 Pod 的分布判定。

在 YAML 中使用时，它们以 topologySpreadConstraints 的字段形式出现，例如：

spec: topologySpreadConstraints: - maxSkew: 1 topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: DoNotSchedule minDomains: 3 # KEP-3022 引入，v1.25 Beta matchLabelKeys: - pod-template-hash # 只计算与自身该标签取值一致的 Pod

（具体字段名与支持版本以对应 Kubernetes 发行版的 API 文档为准。）与之配套的还有 KEP-3094（Take taints/tolerations into consideration when calculating PodTopologySpread skew，v1.25 Beta）：在计算 PodTopologySpread 的 skew 时把节点污点（taint）与 Pod 容忍（toleration）纳入考量，避免把 Pod 分布到无法真正被调度的节点上，使分布结果更贴近实际可调度性。

面向外部调度器的集成钩子

报告提到的第二项核心工作是为外部调度器集成提供更多钩子：

• mutable pod scheduling directives：允许调度器在 Pod 调度完成后，按需修改 Pod 的调度指令（如 nodeSelector、affinity 等），而不是要求用户重新创建 Pod。这为外部调度器与 kube-scheduler 的协作、以及调度后的动态调整提供了基础。
• pod scheduling readiness：为 Pod 增加"调度就绪"门控，使调度器可以区分"尚未允许被调度"与"可以开始调度"两种状态，外部调度器可以据此决定何时将 Pod 纳入调度队列。

这两项都属于调度框架（Scheduling Framework）生态的延伸，其价值在于：默认的 kube-scheduler 不再是唯一的选择，社区可以通过明确定义的钩子与状态机，构建可插拔、可协作的调度方案。这与下文提到的 scheduler-plugins 子项目定位一脉相承。

不依赖 KEP 的持续投入：性能、重构与两个旗舰子项目

年度报告的第二部分记录了"未在 KEP 中跟踪的举措"，包括性能改进、代码重构与清理，以及两个重要的子项目：

• Kueue：报告将其描述为"k8s 原生的作业调度与排队控制器（k8s-native job scheduling and queueing controller）"，是该 SIG 在 2022 年新赞助的子项目。它面向批处理、AI/ML 训练等场景，为多个租户提供基于队列的作业准入与配额管理。在 sigs.yaml 与 README.md 中，kueue 已被登记为 SIG Scheduling 的子项目，并设有明确的 leads 与 OWNERS 文件归属。
• scheduler-plugins：作为"树外（out-of-tree）调度插件"的官方仓库，承载无法或不宜合入 kube-scheduler 主干的各种实验性与生产级插件，是验证调度框架扩展性的试验场。README 中同样将其列为 SIG 子项目（scheduler-plugins 的 Subprojects 一节）。

这两者一个解决"作业排队与批量调度"的集群级问题，一个解决"插件如何生长在核心之外"的工程化问题，共同构成了 2022 年 SIG Scheduling 在核心 kube-scheduler 之外的两条主要战线。

2022 年 KEP 进展全景（v1.24 / v1.25 / v1.26）

报告第三部分按"进入 Beta"与"进入 Stable"两个梯队，列出了 2022 年在 v1.24、v1.25、v1.26 三个版本周期内推进的 KEP。

进入 Beta 的 KEP

两个 Beta KEP 都围绕 PodTopologySpread 展开（详见上文），体现了该年度对"拓扑分布精度"的集中投入。

进入 Stable 的 KEP

这批进入 Stable 的能力值得逐一关注：

• KEP-1258（默认 Pod 拓扑分布）让集群可以为未显式声明 topologySpreadConstraints 的 Pod 提供默认的拓扑分布约束，显著降低了多可用区集群的配置门槛；
• KEP-1923（优先被提名节点）优化了调度器在抢占流程中"预选提名节点"与最终放置的一致性；
• KEP-2249（亲和性命名空间选择器）为 Pod 亲和性/反亲和性补充了 namespaceSelector，使跨命名空间的亲和性规则可以按标签灵活圈定范围；
• KEP-785（调度器组件配置 API）将 kube-scheduler 的配置收敛为正式的组件配置 API（KubeSchedulerConfiguration），是调度器可运维性的基石；
• KEP-902（非抢占 PriorityClass）允许 PriorityClass 声明 preemptionPolicy: Never，让高优先级 Pod 不抢占其他 Pod 而是排队等待资源释放，适合对抢占敏感的工作负载。

从 sig_report.tmpl 的注释可以看到，这类 KEP 列表本可以由生成器基于 kubernetes/enhancements 中的 KEP 元数据自动产出，再由 SIG 成员人工复核，因此年度报告中的版本号（v1.24 / v1.25）与标题均为可核查的社区记录。

子项目版图：新增 kueue 与 kwok，退休 poseidon

报告用"新增 / 退休 / 延续"三类梳理了 2022 年的子项目变化：

• 新增（New in 2022）：kueue、kwok。
  • kueue 的定位见上文；kwok（Kubernetes Without Kubelet）则提供一套轻量级的节点/Pod 模拟器，让开发者无需真实节点即可进行大规模调度测试与验证，是调度器性能与正确性测试的重要工具。
• 退休（Retired in 2022）：poseidon。
• 延续（Continuing）：cluster-capacity（集群容量评估）、descheduler（再调度/驱逐治理）、kube-batch（批处理调度）、kube-scheduler-simulator（调度器仿真器）、scheduler（kube-scheduler 本体）、scheduler-plugins。

对照当前 sigs.yaml 中 sig-scheduling 的 subprojects 条目（cluster-capacity、descheduler、dra-driver-topology、kube-scheduler-simulator、kube-scheduler-wasm-extension、kueue、kwok、scheduler、scheduler-library、scheduler-plugins）可以看到，2022 年确立的 kueue、kwok 子项目地位至今延续，后续年份又新增了 DRA 驱动拓扑、WASM 扩展等新项目，说明该 SIG 的"树外生态"仍在持续扩大。子项目的增删是社区对技术方向投入与收敛的真实写照：投入资源充足、社区活跃的方向升格为新子项目，而不再活跃的方向（如 poseidon）则被归档退役。

工作组：WG Batch 成立

报告显示，2022 年 SIG Scheduling 赞助的工作组中新增了WG Batch（批处理工作组），同时延续了 WG Multitenancy、WG Policy、WG Structured Logging。从当前仓库的 wg-batch/README.md 可以看到，WG Batch 致力于"讨论并增强核心 Kubernetes 对批处理（如 HPC、AI/ML、数据分析、CI）工作负载的支持，统一批处理工作负载的部署方式以提升可移植性并简化提供方支持"，其 Stakeholder SIG 列表包含 SIG Apps、SIG Autoscaling、SIG Node 与SIG Scheduling。批处理与调度天然耦合——批量作业的排队、配额、抢占与拓扑分布都依赖调度能力，这也是 WG Batch 由 SIG Scheduling 深度参与的原因。值得注意的是，报告 2022 中列为延续的工作组（Multitenancy、Policy、Structured Logging）如今可在 archive 目录中找到对应归档，反映了工作组随使命完成或演进而被归档的社区生命周期机制。

项目健康与社区指标

报告在 Project health 一节披露了 SIG 的社区状态：

• 最需要帮助的领域：增加 reviewer 数量（报告附有面向社区的 reviewer 招募呼吁）。
• 关注的健康指标：多样性（diversity）、贡献者数量、会议出勤率。
• 贡献者体验：认为 CONTRIBUTING.md 对新人足够友好且处于最新状态；除通用贡献者规范外无额外特殊要求；成员来自多家公司/组织。

在 Membership 一节，报告给出了 2022 年的量化数据：

从 community-membership.md 定义的 Reviewer/Approver 角色分工（Reviewer 对 PR 给出 /lgtm，Approver 批准合并）来看，"6 名 reviewer、4 名 approver"支撑着包含 kube-scheduler 核心代码在内的多个包，人员规模并不宽裕——这也解释了报告把"增加 reviewer"列为最需要帮助领域的判断。对想参与调度社区的新人，CONTRIBUTING.md 给出了明确的入口：good-first-issue 与 help-wanted 标签的 issue、SIG 双周例会、邮件列表，以及面向调度框架设计文档与 KEP 的阅读路径。

运营工作与社区传播

在 Operational 一节，报告确认 2022 年的治理运营任务全部完成：

• 复核并更新了 README.md 与 CONTRIBUTING.md；
• 复核了 sigs.yaml 中的子项目列表及其 OWNERS 文件关联；
• 确认 SIG 领导（chairs、tech leads、子项目 owner）在 sigs.yaml 中准确且活跃；
• 在 README 中链接并更新了 2022 年会议纪要与会话录像；
• 面向社区做了年度更新：2022 KubeCon NA 与 KubeCon EU 均安排了 "SIG-Scheduling Intro & Deep Dive" 专题分享。

这些任务对应的治理依据是 sig-governance.md，模板 sig_report.tmpl 中也保留了这份运营检查清单的原始形态。对照当前 sigs.yaml 中 sig-scheduling 的 leadership 条目（chairs 与 tech leads 均有明确的 GitHub 账号、公司与邮箱）可见，报告中所说的"领导信息准确且活跃"在仓库数据中得到了落实。

结语

从 sig-scheduling/annual-report-2022.md 这份年度报告可以清晰还原 SIG Scheduling 在 2022 年的三条主线：一是把 PodTopologySpread 从"均匀分布"升级为"可精细调校的均匀分布"（minDomains、matchLabelKeys、taint/toleration 感知），让多可用区与异构集群的放置更可控；二是为外部调度器打开集成空间（mutable scheduling directives、pod scheduling readiness），配合 scheduler-plugins 验证调度框架的扩展性；三是完成子项目与工作组的版图刷新——kueue、kwok 加入、poseidon 退役、WG Batch 成立，并让一批 KEP（默认拓扑分布、调度器组件配置 API、非抢占 PriorityClass 等）进入 Stable。对于想要理解 kube-scheduler 生态演进脉络的读者，这份报告连同仓库中的 README.md、charter.md 与 sigs.yaml 构成了相互印证的完整资料链。

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