SIG Scheduling 访谈
在本次 SIG Scheduling 的访谈中，我们与 Kensei Nakada 进行了交流，他是 SIG Scheduling 的一名 Approver。
介绍
Arvind: 你好，感谢你让我们有机会了解 SIG Scheduling！ 你能介绍一下自己，告诉我们你的角色以及你是如何参与 Kubernetes 的吗？
Kensei: 嗨，感谢你给我这个机会！我是 Kensei Nakada (@sanposhiho)，是来自 Tetrate.io 的一名软件工程师。 我在业余时间为 Kubernetes 贡献了超过 3 年的时间，现在我是 Kubernetes 中 SIG-Scheduling 的一名 Approver。 同时，我还是两个 SIG 子项目的创始人/负责人： kube-scheduler-simulator 和 kube-scheduler-wasm-extension。
关于 SIG Scheduling
AP: 太棒了！你参与这个项目已经很久了。你能简要概述一下 SIG Scheduling，并说明它在 Kubernetes 生态系统中的角色吗？
KN: 正如名字所示，我们的责任是增强 Kubernetes 中的调度特性。 具体来说，我们开发了一些组件，将每个 Pod 调度到最合适的 Node。 在 Kubernetes 中，我们的主要关注点是维护 kube-scheduler， 以及其他调度相关的组件，这些组件是 SIG Scheduling 的子项目。
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 集群上， 同时与现有的成熟控制器（调度器、cluster-autoscaler、kube-controller-manager 等）协作。
- KWOK
- KWOK 这个组件可以在几秒钟内创建一个包含数千个节点的集群。它主要用于模拟/测试轻量级集群，实际上另一个 SIG 子项目 kube-scheduler-simulator 就在后端使用了 KWOK。
- Descheduler
- Descheduler 这个组件可以将运行在不理想的节点上的 Pod 重新创建。
在 Kubernetes 中，调度约束（
PodAffinity、NodeAffinity、PodTopologySpread等）仅在 Pod 调度时被考虑， 但不能保证这些约束在之后仍然被满足。Descheduler 会驱逐违反其调度约束（或其他不符合预期状况）的 Pod， 以便这些 Pod 被重新创建和重新调度。
- Descheduling Framework:
- 一个非常有趣的正在进行的项目，类似于调度器中的调度框架， 旨在使去调度逻辑可扩展，并允许维护者们专注于构建 Descheduler 的核心引擎。
AP: 感谢你告诉我们这些！我想问一下，你最喜欢这个 SIG 的哪些方面？
KN: 我真正喜欢这个 SIG 的地方在于每个人都积极参与。 我们来自不同的公司和行业，带来了多样的视角。 这些差异并没有造成分歧，实际上产生了丰富的观点。 每种观点都会受到尊重，这使我们的讨论既丰富又富有成效。
我非常欣赏这种协作氛围，我相信这对我们多年来不断改进组件至关重要。
给 SIG Scheduling 做贡献
AP: Kubernetes 是一个社区驱动的项目。你对新贡献者或希望参与并为 SIG Scheduling 做出贡献的初学者有什么建议？他们应该从哪里开始？
KN: 让我先给出一个关于为任何 SIG 贡献的通用建议：一种常见的方法是寻找 good-first-issue。 然而，你很快就会意识到，世界各地有很多人正在尝试为 Kubernetes 仓库做贡献。
我建议先查看你感兴趣的某个组件的实现。如果你对该组件有任何疑问，可以在相应的 Slack 频道中提问（例如，调度器的 #sig-scheduling，kubelet 的 #sig-node 等）。 一旦你对实现有了大致了解，就可以查看 SIG 中的 Issue （例如，sig-scheduling）， 相比 good-first-issue，在这里你会发现更多未分配的 Issue。你可能还想过滤带有 kind/cleanup 标签的 Issue，这通常表示较低优先级的任务，可以作为起点。
具体对于 SIG Scheduling 而言，你应该先了解调度框架， 这是 kube-scheduler 的基本架构。大多数实现都可以在 pkg/scheduler中找到。我建议从 ScheduleOne 函数开始，然后再深入探索。
此外，除了 kubernetes/kubernetes 主仓库外，还可以考虑查看一些子项目。 这些子项目的维护者通常比较少，你有更多的机会来对其产生重大影响。尽管被称为“子”项目， 但许多项目实际上有大量用户，并对社区产生了相当大的影响。
最后但同样重要的是，记住为社区做贡献不仅仅是编写代码。 虽然我谈到了很多关于实现的贡献，但还有许多其他方式可以做贡献，每一种都很有价值。 对某个 Issue 的一条评论，对现有特性的一个反馈，对 PR 的一个审查建议，对文档的一个说明阐述； 每一个小贡献都有助于推动 Kubernetes 生态系统向前发展。
AP: 这些建议非常有用！冒昧问一下，你是如何帮助新贡献者入门的，参与 SIG Scheduling 的贡献者可能会学习到哪些技能？
KN: 我们的维护者在 #sig-scheduling Slack 频道中随时可以回答你的问题。 多多参与，你将深入了解 Kubernetes 的调度，并有机会与来自不同背景的维护者合作和建立联系。 你将学习到的不仅仅是如何编写代码，还有如何维护大型项目、设计和讨论新特性、解决 Bug 等等。
未来方向
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 的贡献非常有价值。