聚焦 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 负责人和一名发布负责人实习成员。在发布团队期间，我根据我们团队的经验，提出了一些改进 SIG 和 Enhancements 团队流程的想法（即选择性加入流程）。最终，我开始参加子项目的会议，并为子项目的工作做出贡献。

FSM：你提到了 Enhancements 子项目：你会如何描述它的主要目标和工作范围？

KG：Enhancements 子项目主要关注Kubernetes 增强提案（简称 KEP）—— 这是所有特性和对 Kubernetes 项目的重大变更所必需的“设计”文档。

KEP 及其影响

FSM：KEP 流程的改进是（并且现在也是）SIG Architecture 重点参与的一个方面。你能为那些不了解它的人解释一下这个流程吗？

KG：每个发布版本，SIG 都会告知发布团队他们打算在该版本中开发哪些特性。如上所述，这些变更的前提是需要一个 KEP —— 一个标准化的设计文档，所有作者都必须在发布周期的前几周填写并获得批准。大多数特性都会经历 3 个阶段：alpha、beta，最后是 GA，因此批准一个特性意味着 SIG 作出了一项重大承诺。

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

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

KG：总的来说，我认为影响最大的改进是专注于 KEP 的核心意图。KEP 的存在不仅仅是为了记录设计，更是为了提供一种结构化的方式来讨论和就变更的不同方面达成一致。KEP 流程的核心是沟通和周全的考虑。

为此，一些重大的变化围绕着一个更详细、更易于访问的 KEP 模板。随着时间的推移，我们投入了大量工作才将 k/enhancements 仓库发展成现在的形式 —— 一个按 SIG 组织的目录结构，具有现代 KEP 模板的轮廓（包含提案/动机/设计细节等子部分）。我们今天可能认为这个基本结构是理所当然的，但它确实代表了许多人长期以来为建立这个流程基础所做的努力。

随着 Kubernetes 的成熟，我们需要考虑的不仅仅是合并单个特性的最终目标。我们需要考虑诸如稳定性、性能、设定和满足用户期望等问题。随着我们对这些问题的思考，模板也变得更加详细。生产就绪性评审的引入以及增强的测试要求（在 KEP 的生命周期的不同阶段有所不同）也是重大的改变。

当前的重点领域

FSM：说到成熟，我们最近发布了 Kubernetes v1.31，v1.32 的工作也已经开始。Enhancements 子项目目前是否正在处理任何可能改变现有工作方式的领域？

KG：我们目前正在做两件事：

  1. 创建一个流程 KEP 模板。 有时人们希望利用 KEP 流程来进行更偏向于流程而非特性的重大变更。我们希望支持这一点，因为记录变更是非常重要的，为人们提供更好的工具来做到这一点，只会鼓励更多的讨论和透明度。
  2. KEP 版本控制。 尽管我们对模板的更改旨在尽可能减少干扰，但我们相信，通过一个带版本号的 KEP 模板以及与之配套的策略，可以更轻松地跟踪这些更改，并更好地与社区沟通。

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

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

KG：子项目为发布团队的 Enhancements 团队从使用电子表格迁移到项目看板提供了支持。增强功能的收集和跟踪一直是一个后勤挑战。在我参与发布团队期间，我协助过渡到了一个增强功能的选择性加入系统，即由 SIG 负责人“选择加入”KEP 以进行发布跟踪。这有助于在对 KEP 进行任何重大工作之前加强作者和 SIG 之间的沟通，并减轻了 Enhancements 团队的重复性工作。这一变化利用了现有工具，以避免一次性向社区引入太多变化。后来，发布团队向子项目提出了一个利用 GitHub 项目看板来进一步改进收集流程的想法。这将是摆脱使用复杂电子表格，转而使用 k/enhancement 问题和项目看板上的仓库原生标签的做法。

FSM：这无疑对简化工作流程产生了影响……

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

参与进来

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

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

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

KG：Enhancements 流程是 Kubernetes 最重要的部分之一，需要项目内外的人员和团队之间大量的协调与合作才能成功。我感谢并为每个人持续的辛勤工作和致力于使项目变得伟大的奉献精神所鼓舞。这真是一个了不起的社区。

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