聚焦 SIG API Machinery
我们最近与 Federico Bongiovanni (Google) 和 David Eads (Red Hat)，SIG API Machinery 的主席进行了交谈，以更多地了解这个 Kubernetes 特别兴趣小组。
介绍
Frederico (FSM)：您好，感谢您抽出时间。首先，您能谈谈自己以及您是如何参与到 Kubernetes 中的吗？
David：我于 2014 年秋季开始在 OpenShift（Red Hat 的 Kubernetes 发行版）上工作，并很快参与了 API Machinery。我的第一个 PR 是修复 kube-apiserver 错误消息，然后我扩展到了 kubectl（kubeconfigs 是我的错！），auth（RBAC 和 *Review API 是从 OpenShift 移植的），apps（例如，workqueues 和 sharedinformers）。不要告诉其他人，但 API Machinery 仍然是我的最爱 :)
Federico：我加入 Kubernetes 的时间没有 David 那么早，但现在已经超过六年了。在我之前的公司，我们开始将 Kubernetes 用于我们自己的产品，当我遇到直接使用 Kubernetes 的机会时，我放弃了一切，登上了这艘船（绝非双关语）。我于 2018 年初加入 Google 和 Kubernetes，并一直参与其中。
SIG Machinery 的范围
FSM：只需快速浏览一下 SIG API Machinery 的章程，就会发现它的范围相当大，不亚于 Kubernetes 控制平面。您能用自己的话描述一下这个范围吗？
David：我们拥有 kube-apiserver 以及如何高效地使用它。在后端，这包括它与后端存储的契约，以及它如何允许 API 模式随着时间的推移而演变。在前端，这包括模式最佳实践、序列化、客户端模式以及所有之上的控制器模式。
Federico：Kubernetes 有许多不同的组件，但控制平面有一个非常关键的任务：它是您与集群的通信层，并且还拥有使 Kubernetes 如此强大的所有可扩展性机制。我们不能犯任何错误，例如回归或不兼容的更改，因为影响范围非常大。
FSM：鉴于其范围如此之广，您如何管理它的不同方面？
Federico：我们尝试将大量工作组织成较小的区域。工作组和子项目是其中的一部分。SIG 中的不同人有他们自己的专业领域，如果一切都失败了，我们很幸运拥有像 David、Joe 和 Stefan 这样的人，他们在某种程度上是真正的“全能型人才”，即使过了这么多年，他们仍然让我印象深刻。但另一方面，这就是为什么我们需要更多的人来帮助我们保持 Kubernetes 从一个版本到另一个版本的质量和卓越性。
不断发展的协作模型
FSM：现有的模型一直如此吗，还是随着时间的推移而演变的？如果是这样，您认为主要的变化以及它们背后的原因是什么？
David：API Machinery 随着时间的推移而发展，范围不断扩大和缩小。在尝试满足客户端访问模式时，很容易在功能和应用方面增加范围。
一个范围扩大的好例子是，我们认识到需要减少编写控制器的客户端的内存利用率，并开发了共享的 informers。在开发共享 informers 和控制器模式（使用它们，例如工作队列、错误处理和 listers）时，我们大大减少了内存利用率，并消除了许多昂贵的列表。缺点：我们增加了一组新的功能来支持并有效地从 sig-apps 接管了该区域的所有权。
关于更多共享所有权的示例：构建协作资源管理（服务器端应用的目的是），kubectl 扩展为接管利用服务器端应用功能的所有权。过渡尚未完成，但 SIG CLI 管理该使用并拥有它。
FSM：对于方法之间的界限，您有什么指导原则吗？
David：我认为很大程度上取决于影响。如果影响在短期内是局部的，我们会建议其他 SIG 并让他们按照自己的节奏前进。如果影响在短期内是全局的，并且没有自然的激励，我们会发现需要直接推动采用。
FSM：还是关于这一点，SIG Architecture 有一个 API Governance 子项目，它是否主要独立于 SIG API Machinery，还是有重要的连接点？
David：这些项目有相似的名称，并且相互之间产生一些影响，但具有不同的任务和范围。API Machinery 拥有“如何”，API Governance 拥有“什么”。API 约定、API 批准过程以及对单个 k8s.io API 的最终决定权属于 API Governance。API Machinery 拥有 REST 语义和非 API 特定行为。
Federico：我真的很喜欢 David 的说法：“API Machinery 拥有‘如何’，API Governance 拥有‘什么’：我们不拥有实际的 API，但实际的 API 通过我们而存在。
Kubernetes 受欢迎的挑战
FSM：随着 Kubernetes 采用率的增长，我们当然看到了控制平面需求的增加：这有何感受，它如何影响 SIG 的工作？
David：它对 API Machinery 产生了巨大的影响。多年来，我们经常响应并多次启用 Kubernetes 的演变阶段。作为 Kubernetes 集群上几乎所有功能的中心编排中心，我们既领导又跟随社区。概括而言，我看到了 API Machinery 多年来的一些演变阶段，始终保持着高活跃度。
寻找目标：
pre-1.0一直到v1.3（直到我们的第一个 1000 多个节点/命名空间）左右。这段时间的特点是快速变化。我们经历了五个不同的模式版本，并崛起以满足需求。我们优化了快速的、树内 API 演变（有时会损害长期目标），并首次定义了模式。扩展以满足需求：
v1.3-1.9（直到控制器中的共享 informers）左右。当我们开始尝试在获得采用时满足客户需求时，我们发现 CPU 和内存方面存在严重的扩展限制。这就是我们扩展 API Machinery 以包含访问模式的地方，但仍然非常关注树内类型。我们构建了监视缓存、protobuf 序列化和共享缓存。培养生态系统：
v1.8-1.21（直到 CRD v1）左右。这是我们设计和编写 CRD（被认为是第三方资源的替代品）、我们知道即将到来的即时需求（admission webhooks）以及我们知道我们需要（API 模式）的最佳实践演变的时候。这使得早期采用者激增，他们愿意非常谨慎地在约束条件下工作，以实现他们为服务 pod 的用例。采用速度非常快，有时甚至超过了我们的能力，并造成了新的问题。简化部署：
v1.22+。在相对最近的过去，我们一直在响应压力，或者以大规模运行 kube 集群，其中有大量有时相互冲突的生态系统项目使用我们的扩展机制。现在，我们正在努力使平台扩展更容易编写，并且对于那些没有 Kubernetes 博士学位的人来说，管理起来更安全。这从服务器端应用等内容开始，并一直延续到今天的 webhook 匹配条件和验证 admission 策略等功能。
API Machinery 中的工作对整个项目和生态系统都有广泛的影响。对于那些能够长期投入大量时间的人来说，这是一个令人兴奋的领域。
未来的道路
FSM：考虑到这些不同的演变阶段，您认为目前 SIG 的首要任务是什么？
David： 可靠性、效率和能力，大致按此顺序排列。
随着我们的 kube-apiserver 和扩展机制的使用增加，我们发现我们的第一套扩展机制虽然在功能方面相当完整，但在潜在的滥用方面具有很大的风险，影响范围很大。为了减轻这些风险，我们正在投资于减少意外影响范围的功能（webhook 匹配条件），并为大多数操作提供风险较低的替代机制（验证 admission 策略）。
与此同时，使用的增加使我们更加意识到我们可以改进服务器端和客户端的扩展限制。这里的努力包括更高效的序列化 (CBOR)、减少 etcd 负载（来自缓存的一致读取）以及减少峰值内存使用量（流式列表）。
最后，使用量的增加也突显了一些长期存在但我们正在弥补的差距。比如 CRD 的字段选择器，批量处理工作组 非常希望利用它，并且最终将成为防止利用受攻击节点发起 trampoline pod 攻击的新方法的基础。
加入乐趣
FSM：对于任何想要开始贡献的人，你有什么建议？
Federico：SIG API Machinery 也不例外，它也遵循 Kubernetes 的座右铭：砍柴挑水。每周都有多个公开会议，而且总是需要做的工作比做的人多。
我知道 API Machinery 并不容易，入门过程会很陡峭。门槛很高，原因正如我们一直在讨论的：我们肩负着巨大的责任。但当然，凭借热情和毅力，多年来许多人都成功入门，我们也希望将来会有更多人加入。
在具体机会方面，每两周会举行一次 SIG 会议。欢迎所有人参加和倾听，了解小组讨论的内容，了解此版本中正在发生的事情等等。
此外，每周两次，周二和周四，我们会进行公开的 Bug 分类，我们会检查上一次会议以来的所有新内容。我们已经保持这种实践 7 年多了。这是一个自愿审查代码、修复错误、改进文档等的绝佳机会。周二的会议是下午 1 点（太平洋标准时间），周四的会议是欧洲、中东和非洲友好的时间（太平洋标准时间上午 9:30）。我们一直在努力改进，并希望将来能够提供更具体的机会来加入和参与。
FSM：太棒了，谢谢！您还有什么最后想和我们的读者分享的吗？
Federico：正如我提到的，第一步可能很难，但回报也更大。在 API Machinery 上工作是在一个具有巨大影响力的领域工作（数百万用户？），您的贡献将直接影响 Kubernetes 的工作方式以及使用方式。对我来说，这足以作为奖励和动力！