聚焦 SIG API Machinery
我们最近与 SIG API Machinery 的主席 Federico Bongiovanni（Google）和 David Eads（Red Hat）进行了访谈， 了解一些有关这个 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 在随着时间的推移不断发展，既有扩展也有收缩。 在尝试满足客户端访问模式时，它很容易在特性和应用方面扩大范围。
一个范围扩大的好例子是我们认识到需要减少客户端写入控制器时的内存使用率而开发了共享通知器。 在开发共享通知器和使用它们的控制器模式（工作队列、错误处理和列举器）时， 我们大大减少了内存使用率，并消除了许多占用资源较多的列表。 缺点是：我们增加了一套新的权能来提供支持，并有效地从 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（直到控制器中的共享通知器）。 当我们开始尝试满足客户需求时，我们发现了严重的 CPU 和内存规模限制。 这也是为什么我们将 API Machinery 扩展到包含访问模式，但我们仍然非常关注树内类型。 我们构建了 watch 缓存、protobuf 序列化和共享缓存。
- 培育生态系统：
v1.8-1.21（直到 CRD v1）。这是我们设计和编写 CRD（视为第三方资源的替代品）的时间， 满足我们知道即将到来的即时需求（准入 Webhook），以及我们知道需要的最佳实践演变（API 模式）。 这促成了早期采用者的爆发式增长，他们愿意在约束内非常谨慎地工作，以实现服务 Pod 的用例。 采用速度非常快，有时超出了我们的权能，并形成了新的问题。
- 简化部署：
v1.22+。在不久之前， 我们采用扩展机制来响应运行大规模的 Kubernetes 集群的压力，其中包含大量有时会发生冲突的生态系统项目。 我们投入了许多努力，使平台更易于扩展，管理更安全，就算不是很精通 Kubernetes 的人也能做到。 这些努力始于服务器端应用，并在如今延续到 Webhook 匹配状况和验证准入策略等特性。
API Machinery 的工作对整个项目和生态系统有广泛的影响。 对于那些能够长期投入大量时间的人来说，这是一个令人兴奋的工作领域。
未来发展
FSM：考虑到这些不同的发展阶段，你能说说这个 SIG 的当前首要任务是什么吗？
David：大致的顺序为可靠性、效率和权能。
随着 kube-apiserver 和扩展机制的使用增加，我们发现第一套扩展机制虽然在权能方面相当完整，
但在潜在误用方面存在重大风险，影响范围很大。为了减轻这些风险，我们正在致力于减少事故影响范围的特性
（Webhook 匹配状况）以及为大多数操作提供风险配置较低的替代机制（验证准入策略）。
同时，使用量的增加使我们更加意识到我们可以同时改进服务器端和客户端的扩缩限制。 这里的努力包括更高效的序列化（CBOR），减少 etcd 负载（从缓存中一致读取）和减少峰值内存使用量（流式列表）。
最后，使用量的增加突显了一些长期存在的、我们正在设法填补的差距。这些包括针对 CRD 的字段选择算符， Batch Working Group 渴望利用这些选择算符，并最终构建一种新的方法以防止从有漏洞的节点实施“蹦床式”的 Pod 攻击。
加入有趣的我们
FSM：如果有人想要开始贡献，你有什么建议？
Federico：SIG API Machinery 毫不例外也遵循 Kubernetes 的风格：砍柴和挑水（踏实工作，注重细节）。 有多个每周例会对所有人开放，总是有更多的工作要做，人手总是不够。
我承认 API Machinery 并不容易，入门的坡度会比较陡峭。门槛较高，就像我们所讨论的原因：我们肩负着巨大的责任。 当然凭借激情和毅力，多年来有许多人已经跟了上来，我们希望更多的人加入。
具体的机会方面，每两周有一次 SIG 会议。欢迎所有人参会和听会，了解小组在讨论什么，了解这个版本中发生了什么等等。
此外，每周两次，周二和周四，我们有公开的 Bug 分类管理会，在会上我们会讨论上次会议以来的所有新内容。 我们已经保持这种做法 7 年多了。这是一个很好的机会，你可以志愿审查代码、修复 Bug、改进文档等。 周二的会议在下午 1 点（PST），周四是在 EMEA 友好时间（上午 9:30 PST）。 我们总是在寻找改进的机会，希望能够在未来提供更多具体的参与机会。
FSM：太好了，谢谢！你们还有什么想与我们的读者分享吗？
Federico：正如我提到的，第一步可能较难，但回报也更大。 参与 API Machinery 的工作就是在加入一个影响巨大（百万用户？）的领域， 你的贡献将直接影响 Kubernetes 的工作方式和使用方式。对我来说，这已经足够作为回报和动力了！