聚焦 SIG 架构：生产就绪

这是 SIG 架构专题系列的第二次采访，该系列将涵盖不同的子项目。 在这篇博客中，我们将介绍 SIG 架构：生产就绪子项目.

在本次 SIG 架构专题中，我们采访了生产就绪子项目负责人 Wojciech Tyczynski (Google)。

关于 SIG 架构和生产就绪子项目

Frederico (FSM)：你好，Wojciech，你能简单介绍一下你自己、你的角色以及你如何参与 Kubernetes 的吗？

Wojciech Tyczynski (WT)：我于 2015 年 1 月开始为 Kubernetes 做贡献。当时，Google（我当时和现在仍在工作的地方）决定在华沙办事处（除了加利福尼亚和西雅图已有的团队之外）组建一个 Kubernetes 团队。我很幸运成为该团队的种子工程师之一。

在经过两个月的入职培训并帮助完成了整个项目的不同任务以实现 1.0 发布之后，我接管了可伸缩性领域的所有权，并领导 Kubernetes 支持具有 5000 个节点的集群。 我仍然作为其技术负责人参与 SIG 可伸缩性。 那是一段旅程的开始，因为可伸缩性是一个如此跨领域的主题，我开始为包括 SIG 架构在内的许多其他领域做出贡献。

FSM：在 SIG 架构中，为什么特别选择生产就绪子项目？ 是你从一开始就想到的，还是最初参与可伸缩性的意外结果？

WT：在达到 Kubernetes 支持 5000 个节点集群的里程碑之后，目标之一是确保 Kubernetes 不会随着时间的推移而降低其可伸缩性属性。虽然不可伸缩的实现总是可以修复的，但设计不可伸缩的 API 或合同是有问题的。 我正在寻找一种方法来确保人们在创建新特性和功能时考虑到可伸缩性，而不会引入过多的开销。

这时我与 John Belamaric 和 David Eads 联手，在 SIG 架构中创建了一个生产就绪子项目。 虽然为可伸缩性设定标准只是它的几个动机之一，但它最终非常适合。 同时，我已经在内部参与系统的整体可靠性，因此生产就绪的其他目标也深得我心。

FSM：对于任何不熟悉 SIG 架构工作原理的人，你如何描述生产就绪子项目的主要目标和干预领域？

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 为他们增加了一些额外的工作，但我们看到人们关心它，更令人鼓舞的是，随着每个版本的发布，答案的质量都有所提高，并且不再出现“我真的需要一个反映我的特性是否有效的指标”或“降级真的那么重要吗”之类的问题。

• ←上一个
下一个→