聚焦 SIG Architecture: Enhancements

借由 Frederico Muñoz (SAS Institute) | 译者 Michael Yao (DaoCloud) |

这是 SIG Architecture 聚光灯系列的第四次采访，我们将介绍 SIG Architecture: Enhancements。

在本次 SIG Architecture 专题采访中，我们访谈了 Enhancements 子项目的负责人 Kirsten Garrison。

Enhancements 子项目

Frederico (FSM)：你好 Kirsten，很高兴有机会讨论 Enhancements 子项目。开始请先介绍一下你自己和所承担的职责。

Kirsten Garrison (KG)：我是 SIG-Architecture 的 Enhancements 子项目的负责人，目前就职于 Google。 我最初在 Carolyn Van Slyck 的帮助下，为 service-catalog 项目贡献代码， 后来加入了 Release 团队， 最终成为 Enhancements Lead 和 Release Lead 影子。 在发布团队工作期间，我根据团队的经验为 SIG 和 Enhancements 团队提出了一些改进流程的想法（如参与其中的流程）。 之后，我开始参加子项目会议，并为这个子项目的工作做贡献。

FSM：你提到了 Enhancements 子项目，你如何描述它的主要目标和干预范围？

KG：Enhancements 子项目的核心是管理 Kubernetes 增强提案（KEP）， 这是 Kubernetes 项目所有特性和重大变更的“设计”文档。

KEP 及其影响

FSM：KEP 流程的改进一直是 SIG Architecture 深度参与的工作之一。你能为不了解的人介绍一下这个流程吗？

KG：在每次发布版本时，各个 SIG 需要告知 Release Team 各自计划将哪些特性放到当前的版本发布中。 正如前面提到的，所有变更的前提是有一个 KEP，这是一种标准化的设计文档， 所有 KEP 的作者必须在发布周期的最初几周内填写完并获得批准。 大多数特性会经历三个阶段： Alpha、Beta，最终进入 GA，因此批准一个特性对 SIG 来说是一项重大承诺。

KEP 作为某个特性真实、完整的信息来源。 KEP 模板 对处于不同阶段的特性具有不同的要求，但通常需要详细讨论其设计、影响，并提供稳定性和性能的证明材料。 KEP 通常会在作者、SIG 审查人员、API 审查团队和 Production Readiness Review 团队1之间进行多轮迭代后才能获批。 每组审查者都会确保提案符合其标准，以保证 Kubernetes 版本的稳定性和性能。 只有在所有审批完成后，作者才能将其特性合并到 Kubernetes 代码库。

FSM：我懂了，新增了一些结构。回顾来看，你认为这种流程方法最重要的改进是什么？

KG：总体而言，我认为最有影响力的改进在于聚焦 KEP 的核心意图。 KEP 不仅仅是设计的存档文件，更是提供了一种结构化的方式来讨论和达成共识。 KEP 流程的核心是沟通和审慎考虑。

为此，一些重要的改进围绕着更详细且更易于访问的 KEP 模板展开。 我们投入了大量时间，使 k/enhancements 仓库发展成当前的形式：目录结构按 SIG 小组划分，附带现代 KEP 模板文件， 其中包含 Proposal/Motivation/Design Details（提案/动机/设计细节）等小节。 我们今天可能认为这种基本结构是理所当然的，但它实际上代表付出了许多人力和时间努力工作才奠定了这一流程基础。

随着 Kubernetes 的发展和成熟，我们需要考虑的不仅仅是如何合并单个特性，还需要关注稳定性、性能、设置和用户期望等问题。 因此随着我们的思考深入，KEP 模板变得更详细。例如增加了 Production Readiness Review 机制，同时对测试要求进行了强化 （这些要求会随着 KEP 生命周期的不同阶段动态调整）。

当前关注领域

FSM：说到发展，我们最近发布了 Kubernetes v1.31， 而 v1.32 版本的开发工作已经开始。 Enhancements 子项目目前有哪些领域正在推进以改进这个流程？

KG：我们目前正在进行两项工作：

  1. 创建一个 Process KEP 模板。有时，人们希望使用 KEP 流程来记录重要的流程变更，而不是特性变更。 我们希望支持这一点，因为记录变更很重要，为此提供更好的工具将鼓励更多的讨论和更透明。
  2. KEP 版本化。虽然我们的模板变更旨在尽量减少破坏性影响，但我们认为引入 KEP 版本化及相应的策略， 可以让变更更易于追踪并更好地与社区沟通。

这两项改进都需要时间来完善和推广（就像 KEP 特性本身一样），但我们相信它们最终会给社区带来很大的好处。

FSM：你提到了改进：我记得最近的发布引入了用于 Enhancement 追踪的项目看板（Project Board）， 发布团队成员对此表示一致好评。这是 Enhancements 子项目的一个重点方向吗？

KG：Enhancements 子项目为 Release Team 的 Enhancement 团队提供支持，从使用电子表格迁移到一个项目看板。 增强提案的收集和跟踪一直是后勤支持的一项挑战。在我担任 Release Team 成员期间，我帮助推动了增强的“选择加入”机制， 即 SIG 负责人需要主动“选择加入” KEP 进行发布追踪。 这有助于在对 KEP 实施重大工作之前，加强作者与 SIG 之间的沟通，并减少 Enhancements 团队的重复工作。 这一变更利用了现有工具，以避免一次性向社区引入过多变化。 后来，Release Team 向子项目提出了利用 GitHub 项目看板进一步改进收集流程的想法。 这一举措旨在从使用复杂的电子表格转为使用 k/enhancement Issues 和项目看板上的原生仓库标签。

FSM：这无疑简化了工作流程...

KG：减少摩擦来源、促进清晰沟通对 Enhancements 子项目至关重要。同时，我们也需要谨慎考虑影响整个社区的决策。 我们希望确保变更既带来好处，又不会在推广过程中造成回归或额外负担。 我们支持 Release Team 进行头脑风暴，并协助完成迁移到项目看板的工作。 这次变更取得了巨大成功，很高兴看到团队做出了高影响力的改进，使所有参与 KEP 流程的每个人受益！

如何参与

FSM：如果有人想要参与 Enhancements 子项目，你认为需要具备哪些技能？

KG：熟悉 KEP 机制，无论是通过体验，还是花时间阅读 kubernetes/enhancements 仓库都会有所帮助。 我们欢迎所有感兴趣的人参与，我们可以一步步引导他们。

FSM：太棒了！非常感谢你的时间和分享——最后你有什么想对读者们说的吗？

KG：Enhancements 流程是 Kubernetes 生态中最重要组成部分之一，需要各个团队的密切协作才能成功。 我很感激并敬佩大家持续不断的努力工作和奉献，让这个项目越来越好。这真是一个很棒的社区。

  1. 更多信息参考 Production Readiness Review 专题采访。 ↩︎