聚焦 SIG Scheduling
在本次 SIG Scheduling 聚焦访谈中，我们与 SIG Scheduling 的 Approver Kensei Nakada 进行了交流。
介绍
Arvind：你好，感谢你给我们这次机会来更多地了解 SIG Scheduling！能否请你介绍一下自己，谈谈你的角色，以及你是如何参与到 Kubernetes 项目中来的？
Kensei：你好，感谢这次机会！我是 Kensei Nakada (@sanposhiho)，Tetrate.io 的一名软件工程师。我利用业余时间为 Kubernetes 贡献了三年多，现在是 Kubernetes 中 SIG Scheduling 的一名 Approver。此外，我也是两个 SIG 子项目 kube-scheduler-simulator 和 kube-scheduler-wasm-extension 的创始人/所有者。
关于 SIG Scheduling
AP：太棒了！你参与这个项目已经很久了。能简要介绍一下 SIG Scheduling 及其在 Kubernetes 生态系统中的作用吗？
KN：顾名思义，我们的职责是增强 Kubernetes 内的调度能力。具体来说，我们开发用于决定哪个 Node 是每个 Pod 最佳位置的组件。在 Kubernetes 中，我们的主要工作重点是维护 kube-scheduler，以及作为我们 SIG 子项目一部分的其他与调度相关的组件。
AP：我明白了，了解了！这让我很好奇——SIG Scheduling 最近为 Kubernetes 调度引入了哪些创新或发展？
KN：从功能角度来看，最近对 PodTopologySpread 进行了几项增强。PodTopologySpread 是调度器中一个相对较新的功能，我们仍在收集反馈并进行改进。
最近，我们一直专注于一项名为 QueueingHint 的新的内部增强，旨在提高调度吞吐量。吞吐量是我们调度中至关重要的指标之一。传统上，我们主要关注优化每个调度周期的延迟。QueueingHint 采用了一种不同的方法，通过优化何时重试调度来减少浪费调度周期的可能性。
A：听起来很有趣！在 SIG Scheduling 内部，你目前还在进行其他有趣的话题或项目吗？
KN：我正在领导我刚刚分享的 QueueingHint 的开发。鉴于这对我们来说是一个巨大的新挑战，我们遇到了许多意想不到的难题，尤其是在可扩展性方面，我们正在努力逐一解决，以最终实现默认启用它。
此外，我相信我去年启动的 kube-scheduler-wasm-extension（一个 SIG 子项目）会让很多人感兴趣。Kubernetes 的许多组件都有各种扩展。传统上，扩展是通过 webhook（调度器中的 extender）或 Go SDK（调度器中的调度框架）提供的。然而，这些方式都有缺点——webhook 存在性能问题，而 Go SDK 则需要重建和替换调度器，这给那些希望扩展调度器但又不熟悉它的人带来了困难。该项目正试图为这个普遍性挑战引入一种新的解决方案——基于 WebAssembly 的扩展。Wasm 允许用户轻松构建插件，无需担心重新编译或替换他们的调度器，并避免了性能问题。
通过这个项目，SIG Scheduling 一直在学习关于 WebAssembly 与大型 Kubernetes 对象交互的宝贵见解。而且我相信，我们正在获得的经验将对整个社区都有用，而不仅仅是 SIG Scheduling。
A：确实如此！现在，SIG Scheduling 内部有 8 个子项目。你愿意谈谈它们吗？有没有那些团队做出的你想强调的有趣贡献？
KN：我来挑选三个子项目：Kueue、KWOK 和 descheduler。
- Kueue
- 最近，很多人尝试用 Kubernetes 管理批处理工作负载，2022 年，Kubernetes 社区成立了 WG-Batch，以更好地支持 Kubernetes 中的这类批处理工作负载。Kueue 是一个在此方面扮演关键角色的项目。它是一个作业排队控制器，决定作业何时应该等待、何时应该被接纳开始，以及何时应该被抢占。Kueue 旨在安装在普通的 Kubernetes 集群上，同时与现有的成熟控制器（scheduler、cluster-autoscaler、kube-controller-manager 等）协同工作。
- KWOK
- KWOK 是一个组件，你可以在几秒钟内用它创建包含数千个节点的集群。它主要作为轻量级集群用于模拟/测试，实际上另一个 SIG 子项目 kube-scheduler-simulator 在后台使用了 KWOK。
- descheduler
- Descheduler 是一个重新创建运行在不期望节点上的 Pod 的组件。在 Kubernetes 中，调度约束（
PodAffinity、NodeAffinity、PodTopologySpread等）仅在 Pod 调度时被遵守，但不能保证这些约束在之后会一直得到满足。Descheduler 会驱逐违反其调度约束（或其他不期望条件）的 Pod，以便它们被重新创建和重新调度。 - Descheduling Framework
- 一个非常有趣的正在进行的项目，类似于调度器中的调度框架，旨在使 descheduling 逻辑可扩展，并允许维护者专注于构建 descheduler 的核心引擎。
AP：感谢你的介绍！我必须问一下，关于这个 SIG，你最喜欢的地方有哪些？
KN：我真正喜欢这个 SIG 的地方是每个人的参与都非常积极。我们来自不同的公司和行业，为讨论带来了多样的视角。这些差异非但没有造成分歧，反而催生了丰富的观点。每个观点都受到尊重，这使得我们的讨论既丰富又富有成效。
我非常欣赏这种协作氛围，我相信这是多年来我们不断改进组件的关键。
为 SIG Scheduling 做贡献
AP：Kubernetes 是一个社区驱动的项目。对于希望参与并为 SIG Scheduling 做出贡献的新贡献者或初学者，你有什么建议吗？他们应该从哪里开始？
KN：让我从对任何 SIG 贡献的通用建议开始：一个常见的方法是寻找 good-first-issue。然而，你很快会发现，世界各地有很多人都在尝试为 Kubernetes 仓库做出贡献。
我建议从检查你感兴趣的组件的实现开始。如果你对此有任何疑问，可以在相应的 Slack 频道中提问（例如，调度器是 #sig-scheduling，kubelet 是 #sig-node 等）。一旦你对实现有了大致的了解，就可以查看 SIG 内的问题（例如，sig-scheduling），你会发现那里有更多未分配的问题，比 good-first-issue 更多。你可能还想用 kind/cleanup 标签过滤问题，这通常表示优先级较低的任务，可以作为起点。
具体到 SIG Scheduling，你应该首先了解 调度框架，这是 kube-scheduler 的基本架构。大部分实现都可以在 pkg/scheduler 中找到。我建议从 ScheduleOne 函数开始，然后从那里深入探索。
此外，除了主要的 kubernetes/kubernetes 仓库，还可以考虑研究子项目。这些项目通常维护者较少，提供了更多产生重大影响的机会。尽管被称为“子”项目，但许多项目拥有大量用户，并对社区产生相当大的影响。
最后但同样重要的是，请记住为社区做贡献不仅仅是代码。虽然我谈了很多关于实现方面的贡献，但贡献的方式有很多，每一种都很有价值。对一个问题的一条评论，对一个现有功能的一份反馈，PR 中的一条审查意见，对文档的一次澄清；每一个小小的贡献都有助于推动 Kubernetes 生态系统向前发展。
AP：这些都是非常有用的建议！如果可以的话，我想问一下，你是如何帮助新贡献者入门的？通过参与 SIG Scheduling，贡献者可能会学到哪些技能？
KN：我们的维护者会在 #sig-scheduling Slack 频道回答你的问题。通过参与，你将更深入地了解 Kubernetes 调度，并有机会与来自不同背景的维护者合作和交流。你不仅会学到如何编写代码，还会学到如何维护一个大型项目、设计和讨论新功能、解决错误等等。
未来方向
AP：在调度方面，Kubernetes 面临哪些特有的挑战？有什么特别的痛点吗？
KN：由于不同组织有不同的业务需求，Kubernetes 中的调度可能非常具有挑战性。在 kube-scheduler 中支持所有可能的用例是不可能的。因此，可扩展性是我们的一个关键焦点。几年前，我们用调度框架重新设计了 kube-scheduler，它为用户提供了灵活的可扩展性，可以通过插件实现各种调度需求。这使得维护者可以专注于核心调度功能和框架运行时。
另一个主要问题是保持足够的调度吞吐量。通常，一个 Kubernetes 集群只有一个 kube-scheduler，所以它的吞吐量直接影响整体的调度可扩展性，从而影响集群的可扩展性。虽然我们有一个内部性能测试（scheduler_perf），但不幸的是，我们有时会忽略在不太常见场景下的性能下降。这很困难，因为即使是看起来与性能无关的微小变化，也可能导致性能下降。
AP：SIG Scheduling 有哪些即将到来的目标或计划？你如何设想 SIG 未来的发展？
KN：我们的首要目标始终是构建和维护一个**可扩展**且**稳定**的调度运行时，我敢打赌这个目标将永远不变。
如前所述，可扩展性是解决多样化调度需求挑战的关键。与其试图在 kube-scheduler 中直接支持每一种不同的用例，我们将继续专注于增强可扩展性，以便它能适应各种用例。我提到的 kube-scheduler-wasm-extension 也是这项计划的一部分。
关于稳定性，引入像 QueueHint 这样的新优化是我们的策略之一。此外，保持吞吐量也是未来的一个关键目标。我们计划增强我们的吞吐量监控（参考），以便在发布前尽可能多地自行发现性能下降。但是，现实地说，我们无法覆盖所有可能的场景。我们非常感谢社区对调度吞吐量的任何关注，并鼓励大家就性能问题提供反馈和警报！
结束语
AP：最后，对于那些有兴趣更多了解 SIG Scheduling 的人，你想传达什么信息？
KN：调度是 Kubernetes 中最复杂的领域之一，你刚开始可能会觉得困难。但是，正如我前面分享的，你可以找到很多贡献的机会，而且许多维护者都愿意帮助你理解事情。我们知道，你独特的视角和技能正是我们开源社区如此强大的原因 😊
随时可以通过 Slack（#sig-scheduling）或会议与我们联系。希望这篇文章能引起大家的兴趣，我们能看到新的贡献者！
AP：非常感谢你抽出时间接受这次访谈！我相信很多人会发现这些信息对于更多地了解 SIG Scheduling 以及为该 SIG 做出贡献非常有价值。