聚焦 SIG 调度
在本次 SIG 调度专题中，我们与 SIG 调度的审批人 Kensei Nakada 进行了交谈。
介绍
Arvind： 您好，感谢您给我机会了解更多关于 SIG 调度的信息！您能否介绍一下自己，并告诉我们您在其中的角色，以及您是如何参与到 Kubernetes 的？
Kensei：大家好，感谢给我这次机会！我是 Kensei Nakada (@sanposhiho)，是 Tetrate.io 的一名软件工程师。我利用业余时间为 Kubernetes 做贡献已经超过 3 年了，现在我是 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（调度器中的调度框架）提供的。但是，这些都存在缺点——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 集群上安装，同时与现有的成熟控制器（调度器、集群自动伸缩器、kube-controller-manager 等）合作。
- KWOK
- KWOK 是一个组件，您可以在其中在几秒钟内创建一个包含数千个节点的集群。它主要用作轻量级集群进行模拟/测试，实际上另一个 SIG 子项目 kube-scheduler-simulator 使用 KWOK 作为背景。
- descheduler
- Descheduler 是一个重新创建运行在不想要的节点上的 Pod 的组件。在 Kubernetes 中，调度约束（
PodAffinity、NodeAffinity、PodTopologySpread等）仅在 Pod 调度时受到尊重，但不能保证约束在之后一直得到满足。Descheduler 会驱逐违反其调度约束（或其他不良条件）的 Pod，以便重新创建并重新调度它们。 - Descheduling Framework
- 一个非常有趣的正在进行的项目，类似于调度器中的调度框架，旨在使取消调度逻辑可扩展，并允许维护人员专注于构建取消调度器的核心引擎。
AP：感谢您告诉我们这些！我必须问一下，您最喜欢这个 SIG 的哪些方面？
KN：我真正喜欢这个 SIG 的地方是每个人都非常积极地参与。我们来自不同的公司和行业，带来了不同的视角。这些差异并没有导致分裂，反而产生了丰富的观点。每个观点都受到尊重，这使得我们的讨论既丰富又富有成效。
我非常感谢这种协作氛围，我相信这是多年来不断改进我们组件的关键。
为 SIG Scheduling 做贡献
AP：Kubernetes 是一个社区驱动的项目。对于希望参与并为 SIG 调度做出贡献的新贡献者或初学者，您有什么建议？他们应该从哪里开始？
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 这样的新优化是我们的策略之一。此外，保持吞吐量也是未来至关重要的目标。我们计划增强我们的吞吐量监控（ref），以便我们在发布之前尽可能多地注意到我们自己的性能下降。但是，实际上，我们无法涵盖所有可能的场景。我们非常感谢社区对调度吞吐量的关注，并鼓励对性能问题提供反馈和警报！
结束语
AP：最后，您想向那些有兴趣了解更多关于 SIG Scheduling 的人传达什么信息？
KN：调度是 Kubernetes 中最复杂的领域之一，您可能会发现它一开始很难。但是，正如我之前分享的那样，您可以找到许多贡献的机会，并且许多维护人员愿意帮助您理解。我们知道您独特的视角和技能使我们的开源如此强大 😊
欢迎在 Slack 上联系我们 (#sig-scheduling) 或参与我们的会议。希望这篇文章能引起大家的兴趣，并欢迎新的贡献者加入！
AP：非常感谢您抽出时间完成这篇文章！我相信很多人会发现这些信息对于了解 SIG 调度以及为 SIG 做出贡献非常有价值。