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