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