聚焦 SIG API Machinery

作者：Frederico Muñoz (SAS Institute) | 2024 年 8 月 7 日星期三

我们最近采访了 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 schema 随时间演进。在前端，这包括 schema 最佳实践、序列化、客户端模式以及在此之上的控制器模式。

Federico：Kubernetes 有很多不同的组件，但控制平面肩负着至关重要的使命：它是您与集群的通信层，并且拥有使 Kubernetes 如此强大的所有可扩展机制。我们不能犯诸如回归或不兼容变更之类的错误，因为影响范围太大了。

FSM：鉴于如此广泛的范围，您如何管理它的不同方面？

Federico：我们尝试将大量工作组织成更小的领域。工作组和子项目是其中的一部分。SIG 中的不同成员有各自的专业领域，如果遇到困难，我们非常幸运有 David、Joe 和 Stefan 这样真正“全能”的人，他们的能力多年来一直让我印象深刻。但另一方面，这也是为什么我们需要更多人帮助我们将 Kubernetes 的质量和卓越性从一个版本传递到另一个版本的原因。

不断演进的协作模型

FSM：现有的模型一直如此，还是随着时间演进？如果是，您认为主要变化是什么以及背后的原因是什么？

David：API Machinery 的范围随着时间推移既有增长也有收缩。在尝试满足客户端访问模式时，无论是功能层面还是应用层面，都很容易增加范围。

范围增长的一个很好的例子是，我们发现编写控制器的客户端需要减少内存占用，因此开发了 shared informers。通过开发 shared informers 以及使用它们的控制器模式（workqueues、错误处理和 listers），我们极大地降低了内存占用并消除了许多昂贵的列表操作。缺点是：我们增加了一套新的能力来支持，并且有效地从 sig-apps 接管了该领域的所有权。

另一个更具共享所有权的例子：在构建协同资源管理（server-side apply 的目标）时，kubectl 扩展并接管了利用 server-side apply 能力的所有权。这个过渡尚未完成，但 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+ 节点/命名空间）。这个时期特点是快速变化。我们经历了五种不同版本的 schema，并满足了需求。我们优化了快速的、树内 API 演进（有时会损害长期目标），并首次定义了模式。
满足规模需求：v1.3-1.9 左右（直到控制器中的 shared informers）。当我们开始尝试满足客户需求并获得广泛采用时，我们在 CPU 和内存方面发现了严重的规模限制。正是在这个阶段，我们将 API machinery 扩展到包含访问模式，但仍然主要关注树内类型。我们构建了 watch cache、protobuf 序列化和 shared caches。
培育生态系统：v1.8-1.21 左右（直到 CRD v1）。正是在这个时期，我们设计并编写了 CRD（被认为是 third-party-resources 的替代品），解决了我们知道即将出现的即时需求（admission webhooks），并演进到我们知道需要的最佳实践（API schemas）。这使得早期采用者数量爆发式增长，他们愿意非常谨慎地在限制内工作，以实现其服务 Pod 的用例。采用速度非常快，有时超出了我们的能力，并产生了新的问题。
简化部署：v1.22+。在相对较近的时期，我们一直在应对压力，或者大规模运行带有大量有时相互冲突的生态系统项目的 Kubernetes 集群，这些项目使用了我们的扩展机制。现在大量精力投入到使平台扩展更容易编写，并且让那些没有 Kubernetes 博士学位的人也能更安全地管理。这始于 server-side-apply 之类的功能，并一直持续到今天的 webhook match conditions 和 validating admission policies 等功能。

在 API Machinery 的工作对项目和生态系统有着广泛的影响。对于那些能够在长期内投入大量时间的人来说，这是一个令人兴奋的领域。

未来的道路

FSM：考虑到这些不同的演进阶段，您认为目前 SIG 的首要任务是什么？

David: 大致按照这个顺序：可靠性、效率和能力。

随着我们的 kube-apiserver 和扩展机制的使用增加，我们发现第一套扩展机制虽然在功能方面相当完整，但在潜在误用方面存在重大风险，可能导致大范围影响。为了减轻这些风险，我们正在投入开发功能，以减少事故的影响范围（webhook match conditions），并为大多数操作提供风险较低的替代机制（validating admission policy）。

与此同时，使用量的增加使我们更加意识到可以在服务器端和客户端改进的扩展限制。这方面的努力包括更高效的序列化（CBOR）、减少 etcd 负载（从缓存进行一致性读取）以及降低峰值内存使用量（流式列表）。

最后，使用量的增加凸显了一些我们正在弥补的长期存在的空白。例如 CRD 的字段选择器，批量工作组很渴望利用它，它最终将成为防止受感染节点发起跳板 Pod 攻击的新方法的基础。

加入我们

FSM：对于任何想开始贡献的人，您有什么建议？

Federico：SIG API Machinery 也不例外，正如 Kubernetes 的座右铭所说：劈柴担水。每周都有多个向所有人开放的会议，而且工作总是比人多。

我承认 API Machinery 并不容易，入门曲线也很陡峭。门槛很高，因为我们一直在讨论的原因：我们肩负着巨大的责任。但当然，凭借热情和毅力，多年来许多人都成功地提升了自己的能力，我们希望更多人能够加入进来。

具体的参与机会方面，每两周有一次 SIG 会议。欢迎所有人参加并旁听，了解小组讨论的内容，了解当前版本正在进行的工作等。

此外，每周二和周四有两次公开的 Bug 分类会议，我们会回顾上次会议以来的所有新内容。我们已经坚持这个做法七年多了。这是一个很好的机会，可以志愿审查代码、修复 bug、改进文档等。周二的会议时间是太平洋标准时间下午 1 点，周四的会议时间对 EMEA（欧洲、中东、非洲）地区友好（太平洋标准时间上午 9:30）。我们一直在寻求改进，希望未来能提供更多具体的加入和参与机会。

FSM：太棒了，谢谢！您还有什么想对读者说的最后的话吗？

Federico：正如我所说，第一步可能很难，但回报也更大。在 API Machinery 上工作意味着在一个影响巨大（数百万用户？）的领域工作，您的贡献将直接影响 Kubernetes 的工作方式和使用方式。对我来说，这就是足够的回报和动力！