本文发表于一年多前。旧文章可能包含过时内容。请检查页面中的信息自发布以来是否已变得不正确。
一次一个 KEP，增强 Kubernetes
你知道 Kubernetes v1.24 有 46 项增强吗？在一个为期 4 个月的发布周期中，这包含了大量的新功能。Kubernetes 发布团队协调了发布的后勤工作，从修复测试中的不稳定问题到发布更新的文档。这是一项艰巨的工作，但他们总能按时完成。
发布团队由大约 30 人组成，分布在六个子团队中——Bug Triage、CI Signal、Enhancements、Release Notes、Communications 和 Docs。每个子团队管理发布的一个组成部分。这篇文章将重点介绍增强子团队的角色以及你如何参与其中。
什么是增强子团队？
好问题。我们稍后会谈到这个，但首先，让我们谈谈 Kubernetes 中是如何管理功能的。
每个新功能都需要一份Kubernetes 增强提案——简称 KEP。KEP 是小型的结构化设计文档，提供了一种提出和协调新功能的方式。KEP 作者描述了动机、设计（及替代方案）、风险和测试——然后社区成员提供反馈以达成共识。
KEP 通过 k/enhancements 仓库上的拉取请求（PR）工作流来提交和更新。功能从 alpha 阶段开始，随着其成熟，经过一个毕业过程，逐步进入 beta 和 stable 阶段。例如，这里有一个关于在 Windows Server 上支持特权容器的很酷的 KEP。它在 Kubernetes v1.22 中作为 alpha 功能引入，并在 v1.23 中升级到 beta。
现在回到问题上来——增强子团队为每个版本协调 KEP 的生命周期跟踪。每个 KEP 都需要满足一套要求才能被批准包含在某个版本中。增强子团队会为每个 KEP 核实每一项要求并跟踪其状态。
在每个发布周期开始时，Kubernetes 特别兴趣小组 (SIG) 会提交他们的增强功能以选择加入该版本。一个典型的版本开始时可能会有 60 到 90 个增强功能。在发布过程中，许多增强功能会退出。有些没有完全满足 KEP 要求，另一些则没有完成代码实现。大约 60%-70% 的已选择加入的 KEP 会进入最终版本。
增强子团队做什么？
又一个好问题，请继续提问！增强团队在每个发布周期中都参与了两个关键的里程碑：增强冻结和代码冻结。
增强冻结
增强冻结（Enhancements Freeze）是 KEP 必须完成的截止日期，以便该增强功能能够被包含在发布中。这是一个质量关卡，旨在强制大家围绕维护和更新 KEP 保持一致。最值得注意的要求是 (1) 生产就绪性审查 (PRR) 和 (2) 一份带有完整测试计划和毕业标准的 KEP 文件。
增强子团队通过在 Github 上的 KEP issue 中发表评论与每个 KEP 作者进行沟通。作为第一步，他们会核实状态并检查其是否满足要求。满足要求后，KEP 会被标记为“tracked”（已跟踪）；否则，它被视为“at risk”（有风险）。如果一个 KEP 在增强冻结生效时仍然处于风险状态，那么该 KEP 将从该版本中移除。
这个周期通常是增强子团队最忙碌的时候，因为有大量的 KEP 需要整理，并且每个 KEP 可能需要多次检查以核实其是否满足要求。
代码冻结
代码冻结（Code Freeze）是所有增强功能的实现截止日期。如果增强功能需要代码更改或更新，那么代码必须在此时点前实现、审查并合并。发布的后三分之一阶段专注于稳定代码库——修复不稳定的测试、解决各种回归问题和准备文档——所有代码都需要在这些步骤开始之前就位。
增强子团队会核实一个增强功能的所有 PR 是否都已合并到 Kubernetes 代码库 (k/k) 中。在此期间，子团队会联系 KEP 作者，了解哪些 PR 是 KEP 的一部分，核实这些 PR 是否已合并，然后更新 KEP 的状态。如果代码在代码冻结截止日期前没有全部合并，该增强功能将从该版本中移除。
我如何参与发布团队？
很高兴你问了。最直接的方式是申请成为发布团队的影子成员（release team shadow）。影子角色是一种实践性学徒制，旨在为个人在发布团队中担任领导职位做准备。许多影子角色是非技术性的，并且不需要之前对 Kubernetes 代码库有贡献。
Kubernetes 每年有 3 个版本发布，每个版本大约有 25 个影子成员，因此发布团队总是需要愿意贡献的人。在每个发布周期之前，发布团队会开放影子计划的申请。当申请开始时，它会发布在 Kubernetes 开发邮件列表中。你可以订阅该列表的通知（或定期查看！）来关注申请何时开放。公告通常会在四月中旬、七月中旬和十二月中旬发布——大约在每个发布周期开始前一个月。
我如何了解更多信息？
如果你对所有 Kubernetes 发布子团队的具体细节感到好奇，请查看角色手册。这些手册记录了每个子团队的后勤工作，包括子团队活动的每周分解。这是更好地了解每个团队的绝佳参考。
你也可以查看与发布相关的 Kubernetes Slack 频道——特别是 #release、#sig-release 和 #sig-arch。这些频道中有关于发布的许多方面的讨论和更新。