本文发表于一年多前。旧文章可能包含过时内容。请检查页面中的信息自发布以来是否已变得不正确。

聚焦 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：我没有 David 那么早就接触 Kubernetes，但现在也已经超过六年了。在我之前的公司，我们开始为自己的产品使用 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 的范围随着时间不断演变，既有扩展也有收缩。在试图满足客户端访问模式时，很容易在功能和应用方面增加范围。

一个很好的扩展范围的例子是，我们发现需要减少编写控制器的客户端的内存使用，并开发了共享 Informer。在开发共享 Informer 和使用它们的控制器模式（工作队列、错误处理和 Listers）时，我们大大减少了内存使用并消除了许多昂贵的列表操作。缺点是：我们增加了一套新的功能需要支持，并实际上从 sig-apps 手中接管了那个领域的所有权。

对于一个更共享所有权的例子：在构建协作资源管理（服务器端应用的目标）时，kubectl 扩展了其职能，负责利用服务器端应用功能。这个过渡尚未完成，但 SIG CLI 负责管理和拥有该用法。

FSM：对于不同方法之间的界限，你们有什么指导方针吗？

David：我认为很大程度上取决于影响。如果影响在即时效应上是局部的，我们会建议其他 SIG，让他们按自己的节奏进行。如果影响在即时效应上是全局性的，且没有自然的激励机制，我们发现有必要直接推动采用。

FSM：还是关于这个问题，SIG Architecture 有一个 API 治理子项目，它与 SIG API Machinery 大多是独立的，还是有重要的连接点？

David：这两个项目的名字听起来很像，并且彼此之间有一些影响，但它们的使命和范围是不同的。API Machinery 负责“如何做”，而 API 治理负责“做什么”。API 约定、API 批准流程以及对单个 k8s.io API 的最终决定权属于 API 治理。API Machinery 负责 REST 语义和非 API 特定的行为。

Federico：我非常喜欢 David 的说法：“API Machinery 负责‘如何做’，而 API 治理负责‘做什么’”：我们不拥有实际的 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 左右（直到控制器中的共享 Informer）。当我们开始试图满足客户需求时，随着采用率的增加，我们在 CPU 和内存方面发现了严重的扩展限制。正是在这个时候，我们扩大了 API Machinery 的范围，以包括访问模式，但仍然严重关注树内类型。我们构建了 watch 缓存、protobuf 序列化和共享缓存。
培育生态系统：v1.8-1.21 左右（直到 CRD v1）。这是我们设计和编写 CRD（被认为是第三方资源的替代品）、我们知道即将到来的即时需求（准入 Webhook）以及我们知道我们需要的最佳实践演进（API Schema）的时候。这使得早期采用者愿意在约束范围内非常谨慎地工作，以实现他们为 Pod 提供服务的用例，从而促成了一次爆炸式增长。采用速度非常快，有时超出了我们的能力，并产生了新的问题。
简化部署：v1.22+。在相对较近的过去，我们一直在应对大规模运行 Kube 集群的压力，其中有大量有时相互冲突的生态系统项目使用我们的扩展机制。现在，大量精力投入到使平台扩展更容易编写和更安全地由那些不持有 Kubernetes 博士学位的人来管理。这始于像服务器端应用这样的事情，并一直持续到今天，例如 Webhook 匹配条件和验证准入策略等功能。

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

前路漫漫

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

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

随着我们的 kube-apiserver 和扩展机制的使用增加，我们发现我们第一套扩展机制虽然在功能方面相当完备，但在潜在的滥用方面带有重大风险，影响范围很大。为了减轻这些风险，我们正在投资于能够减少意外事故影响范围的功能（Webhook 匹配条件），并为大多数操作提供风险较低的替代机制（验证准入策略）。

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

最后，使用的增加凸显了一些我们正在弥补的长期存在的差距。例如 CRD 的字段选择器，批处理工作组急于利用它，并最终将构成一种防止来自被利用节点的跳板 Pod 攻击的新方法的基础。

加入我们

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

Federico：SIG API Machinery 也不例外于 Kubernetes 的座右铭：“挑水砍柴”。每周都有多个对所有人开放的会议，而且总是有比人力更多的工作要做。

我承认 API Machinery 不容易，入门曲线会很陡峭。门槛很高，原因我们已经讨论过：我们肩负着巨大的责任。但当然，凭借热情和毅力，多年来许多人已经成长起来，我们希望未来会有更多人加入。

就具体机会而言，每两周有一次 SIG 会议。欢迎大家参加和聆听，了解小组在谈论什么，了解本版本中正在发生的事情等。

此外，每周两次，周二和周四，我们有公开的 Bug 分类会议，我们会审查自上次会议以来的所有新内容。我们已经坚持这个做法超过 7 年了。这是一个绝佳的机会，可以自愿审查代码、修复 Bug、改进文档等。周二的会议时间是下午 1 点（PST），周四的会议时间对 EMEA 地区友好（上午 9:30 PST）。我们一直在寻求改进，并希望将来能提供更多具体的加入和参与机会。

FSM：太好了，谢谢你们！还有什么最后的评论想与我们的读者分享吗？

Federico：正如我提到的，起步可能会很困难，但回报也更大。在 API Machinery 工作，是在一个具有巨大影响力的领域工作（数百万用户？），你的贡献将直接影响 Kubernetes 的工作方式和使用方式。对我来说，这本身就是足够的回报和动力！