SIG Architecture 焦点：增强

作者：Frederico Muñoz (SAS Institute) |

这是 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 项目做贡献而参与进来的。随着时间的推移，我加入了发布团队，最终成为了 Enhancements Lead 和 Release Lead Shadow。在发布团队期间，我基于团队的经验，为 SIGs 和 Enhancements 团队提出了一些改进流程的想法（选择加入流程）。最终，我开始参加子项目会议，并为子项目的工作做贡献。

FSM：你提到了 Enhancements 子项目：你能描述一下它的主要目标和干预领域吗？

KG：Enhancements 子项目 主要关注 Kubernetes Enhancement Proposal（简称 KEP）—— 所有特性和对 Kubernetes 项目重大变更所需的设计文档。

KEP 及其影响

FSM：KEP 流程的改进是 SIG Architecture 深度参与的领域之一。对于不了解此流程的人，你能否解释一下？

KG：每个发布周期，SIGs 都会告知发布团队他们打算在新版本中处理哪些特性。如前所述，这些变更的前提条件是 KEP —— 一种标准化的设计文档，所有作者都必须在发布周期的最初几周内填写并获得批准。大多数特性会经历 3 个阶段：alpha、beta 和最终 GA（通用可用）。因此，批准一个特性意味着 SIG 需要做出重大承诺。

KEP 是特性的完整事实来源。KEP 模板 根据特性的阶段有不同的要求，但通常需要详细讨论设计和影响，并提供稳定性和性能的证明文件。KEP 在作者、SIG 评审者、API 评审团队和生产就绪评审团队1 之间需要进行大量的迭代工作，才能获得批准。每个评审者团队都在确保提案符合其标准，以实现稳定且高性能的 Kubernetes 发布。只有获得所有批准后，作者才能继续将他们的特性合并到 Kubernetes 代码库中。

FSM：我明白了，增加了不少额外的结构。回顾过去，这种方法最显著的改进是什么？

KG：总的来说，我认为影响最大的改进与聚焦于 KEP 的核心意图有关。KEPs 不仅仅是为了记录设计，更提供了一种结构化的方式来讨论和达成关于变更不同方面的共识。KEP 流程的核心是沟通和考量。

为此，一些显著的变更围绕着更详细、更易于访问的 KEP 模板。k/enhancements 仓库能形成目前的结构——一个按 SIG 组织的目录结构，包含现代 KEP 模板的轮廓（带有 Proposal/Motivation/Design Details 子节）——这经过了长时间的大量工作。今天我们可能认为这种基本结构是理所当然的，但它确实代表了许多人为建立这个流程基础所做的持续努力。

随着 Kubernetes 的成熟，我们需要考虑的不仅仅是合并单个特性的最终目标。我们需要考虑诸如：稳定性、性能、设定并满足用户期望等方面。随着我们对这些方面的思考，模板也变得越来越详细。Production Readiness Review 的增加以及增强的测试要求（在 KEP 生命周期的不同阶段有所不同）都非常重要。

当前的关注领域

FSM：谈到成熟，我们最近发布了 Kubernetes v1.31，v1.32 的工作也已经开始。Enhancements 子项目目前正在解决哪些领域，这些领域可能会改变工作方式？

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

  1. 创建 Process KEP 模板。 有时人们希望利用 KEP 流程来处理更偏向流程而非特性的重大变更。我们希望支持这一点，因为记录变更很重要，而且提供更好的工具来做到这一点只会鼓励更多的讨论和透明度。
  2. KEP 版本控制。 虽然我们的模板变更旨在尽量不造成中断，但我们相信，通过带版本的 KEP 模板以及配套的策略，将更容易跟踪这些变更并更好地与社区沟通。

这两项特性都需要一些时间才能正确实现并全面推广（就像 KEP 特性一样），但我们相信它们都将带来改进，从而使整个社区受益。

FSM：你提到了改进：我记得最近几个版本中引入了用于 Enhancements 跟踪的项目看板，效果非常好，获得了发布团队成员的一致好评。这是子项目特别关注的领域吗？

KG：子项目在发布团队的 Enhancement 团队从使用电子表格迁移到项目看板的过程中提供了支持。收集和跟踪 enhancements 一直是一个后勤挑战。在我参与发布团队期间，我帮助完成了向 enhancements 选择加入系统的过渡，即由 SIG leads “选择加入”要进行版本跟踪的 KEPs。这有助于在对 KEP 进行任何重要工作之前加强作者和 SIG 之间的沟通，并减轻了 Enhancements 团队的工作量。这项变更使用了现有工具，避免一次性给社区带来太多变更。后来，发布团队向子项目提出了利用 GitHub Project Boards 进一步改进收集流程的想法。这将是摒弃复杂的电子表格，转而使用 k/enhancement issue 上的仓库原生标签和项目看板。

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

KG：消除摩擦源和促进清晰沟通对于 Enhancements 子项目非常重要。同时，对影响整个社区的决策进行仔细考量也很重要。我们希望确保变更平衡，既有好处，又不会在推广过程中造成任何退步和痛苦。我们在构思以及实际迁移到项目看板的过程中都支持了发布团队。这是一次巨大的成功，很高兴看到团队做出了高影响力的变更，帮助了所有参与 KEP 流程的人！

如何参与

FSM：对于那些好奇并有兴趣提供帮助的读者，你如何描述参与子项目所需的技能？

KG：熟悉 KEPs，无论是通过经验还是花时间查看 kubernetes/enhancements 仓库，都会有所帮助。所有感兴趣的人都欢迎参与 - 我们可以从那里开始。

FSM：太好了！非常感谢你的时间和见解——你还有什么想与我们的读者分享的最后意见吗？

KG：Enhancements 流程是 Kubernetes 中最重要的部分之一，需要项目内人员和团队之间进行大量的协调和协作才能成功。我感谢并受到所有为使项目变得更好而持续努力和奉献的人们的鼓舞。这真是一个美妙的社区。

  1. 欲了解更多信息，请查看本系列中的生产就绪评审焦点访谈。 ↩︎