本文发表于一年多前。旧文章可能包含过时内容。请检查页面中的信息自发布以来是否已变得不正确。
聚焦 SIG Architecture：生产就绪性
这是 SIG Architecture Spotlight 系列的第二次采访，该系列将涵盖不同的子项目。在本博客中，我们将介绍 SIG Architecture：生产就绪性子项目.
在本次 SIG Architecture 聚焦中，我们与生产就绪性子项目的负责人 Wojciech Tyczynski (Google) 进行了交谈。
关于 SIG Architecture 和生产就绪性子项目
Frederico (FSM): 你好 Wojciech，能给我们介绍一下你自己、你的角色以及你是如何参与到 Kubernetes 中来的吗？
Wojciech Tyczynski (WT): 我从 2015 年 1 月开始为 Kubernetes 做贡献。当时，我所在的公司 Google 决定在华沙办公室成立一个 Kubernetes 团队（当时已在加利福尼亚和西雅图设有团队）。我很幸运能成为该团队的创始工程师之一。
经过两个月的入职培训并协助项目各方面的不同任务以迎接 1.0 版本的发布后，我负责了可扩展性领域的工作，并带领 Kubernetes 团队支持拥有 5000 个节点的集群。我目前仍然作为技术负责人参与 SIG Scalability。那是一段旅程的开始，因为可扩展性是一个贯穿多个领域的议题，我开始为许多其他领域做出贡献，随着时间的推移，也包括了 SIG Architecture。
FSM: 在 SIG Architecture 中，为什么特别选择生产就绪性子项目？这是你从一开始就有的想法，还是你最初参与可扩展性工作时的一个意外结果？
WT: 在实现 Kubernetes 支持 5000 节点集群 这个里程碑之后，我们的目标之一是确保 Kubernetes 的可扩展性特性不会随着时间的推移而退化。虽然不可扩展的实现总是可以修复的，但设计不可扩展的 API 或契约则是有问题的。我一直在寻找一种方法，以确保人们在创建新特性和功能时能考虑到可扩展性，同时又不会引入过多的开销。
就在那时，我与 John Belamaric 和 David Eads 联手，在 SIG Architecture 内部创建了生产就绪性子项目。虽然为可扩展性设定标准只是其众多动机之一，但它最终非常契合。与此同时，我已经在内部参与了系统的整体可靠性工作，所以生产就绪性的其他目标也正合我意。
FSM: 对于任何不熟悉 SIG Architecture 运作方式的人，你会如何描述生产就绪性子项目的主要目标和介入领域？
WT: 生产就绪性子项目的目标是确保任何添加到 Kubernetes 的功能都能在生产集群中可靠地使用。这主要意味着这些功能是可观测的、可扩展的、可支持的，可以随时安全地启用，并且在出现生产问题时也可以禁用。
生产就绪性与 Kubernetes 项目
FSM: 架构一致性是该 SIG 的目标之一，Kubernetes 的分布式和开放性是否让这一点更具挑战性？你觉得这是否影响了生产就绪性必须采取的方法？
WT: Kubernetes 的分布式特性当然会影响生产就绪性，因为它使得思考启用/禁用或可扩展性等方面更具挑战性。更具体地说，当启用或禁用跨多个组件的功能时，你需要考虑它们之间的版本偏差并为此进行设计。对于可扩展性，一个组件的变化实际上可能会导致一个完全不同的组件出现问题，所以这需要对整个系统有很好的理解，而不仅仅是单个组件。但这也是这个项目如此有趣的原因。
FSM: 那些在生产环境中运行 Kubernetes 的人会有他们自己的观点，你是如何收集这些反馈的？
WT: 幸运的是，我们这里不是在谈论*“他们”*，我们是在谈论*“我们”*：我们所有人都为管理着大型 Kubernetes 集群的公司工作，我们也参与其中，所以我们自己也深受这些问题之苦。
因此，虽然我们努力获取反馈（我们年度的 PRR 调查对我们非常重要），但它很少揭示全新的问题——它更多地是展示了问题的规模。我们也会尝试对此作出反应——像“默认关闭 Beta API”这样的变化就是对我们观察到的数据作出的反应。
FSM: 谈到反应，这让我想到了 Kubernetes 增强提案（KEP）模板中有一个生产就绪性审查（PRR）部分，这与毕业过程相关联。这是因为发现了一些不足之处而产生的吗？你会如何描述其结果？
WT: 正如上面提到的，生产就绪性子项目的总体目标是确保每个新添加的功能都能在生产环境中可靠地使用。这不可能由一个中央团队来强制执行——我们需要让它成为每个人的问题。
为了实现这一点，我们希望确保每个设计新功能的人从一开始就考虑到安全启用、可扩展性、可观测性、可支持性等问题。这意味着不是在实现开始时，而是在设计阶段。鉴于 KEP 实际上是 Kubernetes 的设计文档，将其作为 KEP 模板的一部分是实现这一目标的方式。
FSM: 所以，在某种程度上是为了确保特性所有者已经考虑了他们提案的影响。
WT: 正是如此。我们已经观察到，仅仅通过强制特性所有者思考 PRR 的各个方面（通过让他们填写 PRR 问卷），许多最初的问题就消失了。当然，作为 PRR 批准者，我们仍然会发现一些漏洞，但即使是 KEP 的最初版本，在考虑生产化方面，现在也比几年前要好得多，这正是我们想要达到的目标——传播一种思考可靠性（以其最广泛的含义）的文化。
FSM: 我们一直在讨论 PRR 流程，你能为我们的读者描述一下吗？
WT: PRR 流程相当简单——我们只是想确保你尽早地思考你的功能的生产化方面。如果你做好了你的工作，那只是在 KEP 模板中回答一些问题并获得 PRR 批准者的批准（除了常规的 SIG 批准）。如果你之前没有考虑过这些方面，可能需要花费更多时间，并可能修改一些决定，但这正是我们使 Kubernetes 项目可靠所需要的。
协助生产就绪性工作
FSM: 生产就绪性似乎是一个需要大量先前经验才能成为有效贡献者的领域。对于项目新手来说，有没有什么方式可以贡献？
WT: PRR 批准者必须对整个 Kubernetes 项目有深入的了解，才能发现潜在问题。Kubernetes 现在是一个如此庞大的项目，有如此多的细微之处，以至于刚接触项目的人无论资历多深，都可能错过上下文。
话虽如此，你有很多方式可以间接地提供帮助。通过提高项目的可观测性和可调试性、增加测试覆盖率、构建新的测试类型（升级、降级、混沌测试等）来提高项目特定领域的可靠性，这将对我们有很大帮助。请注意，PRR 子项目专注于在设计层面保持标准，但我们也应该同等关注实现。为此，我们依赖于各个 SIG 和代码批准者，因此在那里有了解生产化方面并深切关心它的人，将对项目有很大帮助。
FSM: 谢谢你！你还有什么最后的评论想与我们的读者分享吗？
WT: 我想强调并感谢所有贡献者的合作。虽然 PRR 给他们增加了一些额外的工作，但我们看到人们关心它，更令人鼓舞的是，每个版本的答案质量都在提高，“我真的需要一个反映我的功能是否工作的指标吗”或“降级真的那么重要吗”这样的问题几乎不再出现了。