Kubernetes SIG Scheduling 2021 年度技术回顾调度重排队优化、抢占性能提升与调度框架组件配置演进【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community本文基于 Kubernetes 社区仓库中 SIG Scheduling 2021 年度报告 展开系统梳理该年度调度器在调度队列高效重排队、抢占Preemption性能、插件组件配置简化以及 Scheduler Simulator 子项目等方面的核心进展并深入结合仓库内调度队列、调度框架插件与基准测试等开发者文档帮助读者理解 kube-scheduler 的底层机制、KEP 演进脉络与实际参与 SIG 的路径。SIG Scheduling 负责 Kubernetes 中所有为 Pod 做出放置决策的组件是集群调度能力的核心维护者。阅读本文后你将掌握2021 年调度器在调度队列重排队与抢占路径上的关键优化点、Scheduler Component Config 如何简化插件配置、当年度多个 KEP 的成熟度状态以及如何借助调度器模拟器、性能基准测试等工具深度参与该领域。SIG Scheduling 概览负责 Pod 放置决策的组件根据 SIG 章程SIG Scheduling 的职责是负责做出 Pod 放置决策的组件构建 Kubernetes 调度器与调度功能设计并实现允许用户在集群节点上自定义 Pod 放置的特性包括提升工作负载可靠性、提高集群资源利用率、执行放置策略等功能。章程同时明确了与 sig-scalability、sig-api-machinery、sig-node、sig-auth 等 SIG 的交叉协作边界。范围内调度相关特性如 Node Affinity、kube-scheduler 性能与可扩展性、可靠性问题检测与修复、Pod 调度 API、节点/集群资源管理、Pod 调度策略等范围外网络管理sig-network、持久化存储管理sig-storage、资源配额与准入策略sig-api-machinery。在 sigs.yaml 中SIG Scheduling 的使命声明与章程一致并登记了 chairs、tech leads、meetings、contact 以及全部子项目归属与 OWNERS 文件位置是核对 SIG 组织结构的权威入口。2021 年度亮点工作总览年度报告将 2021 年的工作成果归纳为四项值得关注的重点高效 Pod 重排队Efficient re-queueing of pods显著减少了失败的调度周期failed scheduling cycles数量抢占Preemption性能改进优化了高优先级 Pod 驱逐低优先级 Pod 路径上的开销组件配置中简化插件配置Simplified plugin configuration in component config降低用户配置调度插件参数的复杂度调度器模拟器kube-scheduler-simulator作为新的独立子项目推出用于离线模拟调度行为。其中前两项属于未被 KEP 单独追踪的持续性工作性能改进、基准测试、代码重构清理第三项对应 KEP 2891 与 KEP 785 的推进第四项则是 2021 年新增的子项目。下文将逐一展开并结合仓库内开发者文档深入其实现原理。调度队列的高效重排队从三队列机制到 2021 的优化高效重排队是 2021 年最受关注的调度器改进之一。要理解它首先要理解 kube-scheduler 的调度队列机制。仓库中 调度队列文档 给出了完整的底层说明。调度队列让调度器能够在每个调度周期挑选最合适的 Pod。由于一个 Pod 可能依赖多种条件如持久卷已就绪、满足 Pod 反亲和规则、容忍节点污点等队列机制需要能把调度动作推迟到集群满足全部条件为止。该机制依赖三个队列队列定位说明activeactiveQ立即调度为下一个调度周期提供 PodunschedulableunschedulableQ停放等待存放等待特定条件发生的 PodbackoffpodBackoffQ指数退避存放调度失败如卷仍在创建中但预期最终可调度的 PodPod 在三个调度队列之间流转的机制示意两个后台刷新协程调度队列机制在后台运行两个周期性协程负责把 Pod 移回 active 队列flushUnschedulableQLeftover每 30 秒运行一次把 unschedulable 队列中的 Pod 移出重试。Pod 至少要在队列中停留 30 秒才会被移动最坏情况下可能需要 60 秒flushBackoffQCompleted每 1 秒运行一次把退避时间已满的 Pod 移回 active 队列。这两个重试周期是固定且不可配置的。此外调度器还会响应特定事件如节点新增/更新、已有 Pod 被删除等通过 MoveAllToActiveOrBackoffQueue 将 Pod 从相应队列移入 active 队列——这正是 2021 年优化重排队效率的核心作用面减少无效的调度尝试让真正具备调度条件的 Pod 更早进入调度周期同时避免不具备条件的 Pod 反复消耗调度资源。指数退避避免洪泛 active 队列Pod 被退避的次数越多重新进入 active 队列所需的时间就越长。退避超时随每次失败调度尝试呈指数增长直到达到上限。调度器允许配置初始退避默认 1 秒与最大退避默认 10 秒。文档给出了直观示例一个失败 3 次的 Pod目标退避超时为curTime 2s^38 秒失败 5 次则为curTime 2s^532 秒。如果最大退避设置得过低如默认 10 秒Pod 可能过于频繁地回到 active 队列因此建议按工作负载特征调大最大退避让经常失败的 Pod 在 backoff 队列中停留足够久避免洪泛 active 队列。移动请求Move Request与重排队的联系移动请求触发事件把 Pod 从 unschedulable 队列移到 active 或 backoff 队列。当前触发事件涵盖 Pod、节点、Service、PV、PVC、StorageClass 与 CSI 节点的变更。每个移动请求会记录当前的调度周期到 moveRequestCycle 变量若 Pod 在移动请求发出的同一调度周期内失败它会绕过 unschedulable 队列直接进入 backoff 队列从而更早被重试。典型场景包括一个 Pod 被调度后unschedulable 队列中与其亲和性匹配的 Pod 可能变为可调度——若亲和匹配是唯一条件发出移动请求即可让这些 Pod 最终完成调度Pod 在 filter 插件阶段发现无可用节点时恰好有异步移动请求因新节点事件而发出将其移入 backoff 队列使其更早回到 active 队列并重新评估新节点。从源码结构看高效重排队正是针对上述链路退避时长、移动请求的触发时机与 Pod 在各队列间的流转路径进行调优从而把失败的调度周期数量压到最低。队列还暴露了 pending_pods 与 queue_incoming_pods_total 两类指标可按事件维度统计每个队列的入队次数用于观察调度器吞吐与队列健康状况。抢占Preemption性能改进抢占是 kube-scheduler 在资源不足时为高优先级 Pod 腾出空间的机制当待调度 Pod 因资源不足无法调度时调度器会尝试驱逐抢占集群中优先级更低的 Pod。2021 年 SIG 对抢占路径做了性能改进——结合上下文可以推断改进方向包括减少抢占模拟与候选节点筛选的计算开销以及优化抢占后的重排队衔接被抢占 Pod 进入队列后的处理路径。报告同时记录了与抢占直接相关的 KEP 工作KEP 902NonPreempting PriorityClass为 PriorityClass 增加不抢占选项在 2020 年已进入 Beta并在后续年份1.24转 Stable2021 年还推进了 KEP 1923Prefer Nominated Node见下文 KEP 章节它优化了提名节点的利用方式间接改善了抢占场景下高优先级 Pod 的调度效率。需要说明的是年度报告本身未给出抢占性能改进的具体量化数据以上为基于报告内容与仓库相关 KEP 状态的准确转述。简化插件配置Scheduler Component Config 的 2021 进展2021 年在配置侧的两项 KEP 是KEP 2891Simplified Scheduler Config在 1.22 进入 Beta精简调度器配置写法降低用户心智负担KEP 785Scheduler Component Config API在 1.23 进入 Beta据 2022 年度报告 记载该 API 于 1.25 转 Stable为 kube-scheduler 提供了结构化、版本化的配置 API。这两项工作共同推动了组件配置中简化插件配置目标的落地。仓库中的 调度框架插件文档 完整展示了如何通过KubeSchedulerConfiguration为插件增加可配置参数是理解简化配置背后实现机制的最佳资料。插件参数的结构体定义与注册假设要给名为FooPlugin的插件增加一个可选整数参数barParam。首先在pkg/scheduler/apis/config/types_pluginargs.go中定义内部表示的结构体// k8s:deepcopy-gen:interfacesk8s.io/apimachinery/pkg/runtime.Object type FooPluginArgs struct { // metav1 即 k8s.io/apimachinery/pkg/apis/meta/v1 metav1.TypeMeta BarParam int32 }嵌入TypeMeta用于版本化与持久化的 API 元数据k8s:deepcopy-gen:interfaces注释用于自动生成DeepCopy函数。同时在staging/src/k8s.io/kube-scheduler/config/{version}/types_pluginargs.go定义版本化表示——这次字段类型可以是指针未指定时指针为零值nil框架据此填充默认值// k8s:deepcopy-gen:interfacesk8s.io/apimachinery/pkg/runtime.Object type FooPluginArgs struct { metav1.TypeMeta json:,inline BarParam *int32 json:barParam,omitempty }每次在types_pluginargs.go中新增类型都必须在对应的register.go中注册调度器才能在解析KubeSchedulerConfiguration时识别该参数。默认值与运行时校验解析配置发生在cmd/kube-scheduler/app/options/options.go调度器会把版本化类型转换为内部类型并填充默认值。默认值定义在pkg/scheduler/apis/config/v1beta1/defaults.gofunc SetDefaults_FooPluginArgs(obj *v1beta1.FooPluginArgs) { if obj.BarParam nil { obj.BarParam pointer.Int32Ptr(42) } }校验器定义在pkg/scheduler/apis/config/validation/validation_pluginargs.go处理的是填充默认值之后的内部类型func ValidateFooPluginArgs(args config.FooPluginArgs) error { if args.BarParam 0 args.BarParam 100 { return fmt.Errorf(must be in the range [0, 100]) } return nil }代码生成与测试闭环定义齐全后在 Kubernetes 仓库中依次执行make clean、./hack/update-codegen.sh与make generated_files即可自动生成深拷贝、类型转换、指针类型转原始类型及默认值填充代码。随后应补齐三类测试pkg/scheduler/apis/config/v1beta1/defaults_test.go单元测试默认值pkg/scheduler/apis/config/validation/validation_pluginargs_test.go单元测试校验器pkg/scheduler/apis/config/scheme/scheme_test.go用完整的KubeSchedulerConfiguration定义测试整条解析链路。在插件中接收参数最后在插件的New方法中接收参数并完成校验func New(fpArgs runtime.Object, fh framework.FrameworkHandle) (framework.Plugin, error) { args, ok : fpArgs.(*config.FooPluginArgs) if !ok { return nil, fmt.Errorf(got args of type %T, want *FooPluginArgs, fpArgs) } if err : validation.ValidateFooPluginArgs(*args); err ! nil { return nil, err } // 按需使用 args.BarParam }这套机制正是简化插件配置的底层支撑通过指针字段 默认值注入 自动代码生成插件作者只需声明结构体与默认值函数即可获得完整、版本化、可校验的配置能力。Scheduler Simulator2021 年新增子项目kube-scheduler-simulator 是 2021 年 SIG 新增的官方子项目对应 sigs.yaml 中登记的 subproject 与 OWNERS 指向其目标是让开发者在不操作真实集群的情况下模拟调度行为便于理解调度器内部机制、验证插件逻辑与进行教学演示。年度报告明确提到该子项目缺少 reviewers/owners是 SIG 最需要帮助的领域之一。对于希望从使用调度器走向贡献调度器的开发者参与该模拟器的评审与维护是低门槛、高价值的切入点详见 CONTRIBUTING.md 中关于 first-good-issue、help-wanted 标签 issue 的指引。未纳入 KEP 的持续工作性能、重构与节点资源评分增强除 KEP 外2021 年 SIG 还开展了以下不被 KEP 追踪的工作性能改进与基准测试Performance improvements and benchmarking持续的调度路径性能优化配套的集成基准测试方式详见下文代码重构与清理Code refactorings and cleanups围绕调度框架Scheduling Framework持续重构核心代码改善可维护性基于节点资源的评分增强Enhancements to node resource-based scoring涉及 kubernetes/kubernetes 的两处 PR编号 101946 与 101822属于节点资源评分策略的细化调整与 KEP 2458Node Resource Fit Scoring Strategy1.22 Beta方向一致。2021 年 KEP 全景从 Alpha 到 Stable 的演进年度报告按成熟度完整罗列了 2021 年推进的 KEP对应 1.22 与 1.23 版本线Stable稳定1.22KEP主题版本2249Multi-scheduling Profiles多调度 Profile1.221845Prioritization on Volume Capacity基于卷容量的优先级排序与 sig-storage 共管1.22Beta测试1.22 / 1.23KEP主题版本2249Namespace Selector for Pod AffinityPod 亲和性命名空间选择器1.221923Prefer Nominated Node优先使用提名节点1.222458Resource Fit Scoring Strategy资源匹配评分策略1.222891Simplified Scheduler Config简化调度器配置1.22785Scheduler Component Config API调度器组件配置 API1.232926Job Mutable Scheduling DirectivesJob 可变调度指令1.23Alpha / Pre-alpha2021 年无新增。对照 2020 年度报告 可以看到清晰的演进轨迹Prefer Nominated Node、Node Resource Strategy、Pod Affinity Namespace Selector 等 KEP 在 2020 年处于 Alpha2021 年整体推进到 BetaMulti-scheduling Profiles 与 Component Config 从 2020 年的 Beta 分别走向 1.22 Stable 与 1.23 Beta而 2022 年度报告 则记录了这些 KEP 后续转 Stable 的完整链路如 Default Pod Topology Spread、Prefer Nominated Node、Namespace Selector、Component Config 均于 1.24/1.25 转 Stable。三份年度报告串联起来恰好构成调度框架与配置 API 从孵化到毕业的完整 KEP 生命周期样本。子项目与工作组2021 年的增删与延续2021 年子项目与工作组的变动如下原始清单见 年度报告当前状态以 SIG README 与 sigs.yaml 为准新增子项目kube-scheduler-simulator退役子项目无延续子项目Descheduler、Scheduler Plugins、Cluster Capacity、Poseidon、KubeBatch新增工作组Structured Logging结构化日志仓库中对应 wg-structured-logging 目录退役工作组无延续工作组Policywg-policy、Multitenancywg-multitenancy。从后续演进看2022 年又新增了 Kueue、KWOK 两个子项目并退役 Poseidon见 2022 年度报告如今的 README 中 SIG 还赞助了 WG Batch、WG Checkpoint Restore、WG Device Management、WG Node Lifecycle、WG Workload-aware Scheduling 等工作组子项目列表也扩展至 dra-driver-topology、kube-scheduler-wasm-extension、kueue、kwok、scheduler-library 等反映出调度生态持续扩张的态势。项目健康与社区参与需要帮助的领域年度报告明确指出kube-scheduler-simulator缺少评审者reviewers与所有者owners。对调度器感兴趣的开发者可以从该子项目入手通过 CONTRIBUTING.md 找到 good first issue 与 help wanted 标签的 issue 池。社区健康指标SIG 关注并度量的社区指标包括多样性Diversity、贡献者数量Number of contributors、会议出席率Meetings attendance。报告的成员规模数据2021 年口径主 Slack 频道成员数2529主邮件列表成员数586主会议出席人数估算10主会议参与人数估算5SIG 所属包的唯一评审者reviewers数6SIG 所属包的唯一批准者approvers数4SIG 的运营核查sig-governance.md 所列事项在 2021 年均已完成包括 README/CONTRIBUTING 准确性复核、sigs.yaml 中子项目与 OWNERS 链接核对、领导成员活跃度确认、会议记录更新以及两次社区级更新2021 KubeCon EU 与 NA 的 SIG-Scheduling Intro Deep Dive。CONTRIBUTING.md 本身面向新老贡献者均保持更新状态且无超出通用贡献者指南的特殊评审/批准要求。性能基准测试验证与持续改进的工程手段调度器性能改进含 2021 年的重排队与抢占优化依赖可靠的基准测试体系。仓库中 调度器基准测试文档 给出了完整的实操方法。在 Kubernetes 仓库目录内运行集成基准测试make test-integration WHAT./test/integration/scheduler_perf KUBE_TEST_VMODULE KUBE_TEST_ARGS-run^$$ -bench.按名称运行特定基准集如BenchmarkSchedulingmake test-integration WHAT./test/integration/scheduler_perf KUBE_TEST_VMODULE KUBE_TEST_ARGS-run^$$ -benchBenchmarkScheduling如需仅输出基准结果可在KUBE_TEST_ARGS追加-alsologtostderrfalse -logtostderrfalse。这些基准位于./test/integration/scheduler_perf/scheduler_bench_test.go函数名以BenchmarkScheduling开头每个用例通过{nodes, existingPods, minPods}三元组定义测试规模如 100 节点/1000 存量 Pod/100 增量 Pod或 5000 节点/1000 存量 Pod/1000 增量 Pod。可以新增数组元素来测量特定规模例如要测量 5000 节点集群中调度 10000 个 Pod 的性能可加入{nodes: 5000, existingPods: 1000, minPods: 10000}并用-benchBenchmarkScheduling/5000Nodes/1000Pods只运行该配置。CPU 剖析可通过追加-cpuprofile cpu.out获得之后用go tool pprof -web cpu.out在浏览器中查看火焰图式的结果。端到端真实集群基准会周期性运行注意 API Server 限流为 100 请求/秒调度器吞吐因此封顶约 100 Pod/s。文档还建议凡是可能影响调度器性能的 PR都应随 PR 附带改动前后的集成基准对比结果——这正是 2021 年性能类改进重排队、抢占被持续验证与守护的工程惯例。结语2021 年对 SIG Scheduling 而言是收敛与提速的一年调度队列重排队优化直接削减了失败调度周期抢占路径的性能改进提升了高优先级工作负载的调度时效Simplified Scheduler Config 与 Component Config API 的 Beta 化让插件配置走向结构化与版本化而 kube-scheduler-simulator 的独立则降低了调度器学习与验证的门槛。从 年度报告 到 章程、CONTRIBUTING 与 开发者文档仓库为调度器使用者与潜在贡献者提供了从概念到实现的完整知识链——对于希望深入调度器源码或参与生态建设的开发者2021 年的这些工作正是最佳的起点与参照系。【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考