SIG Architecture 聚焦：API 治理
这是 SIG Architecture 聚焦系列的第五篇访谈，将介绍不同的子项目。本篇聚焦 SIG Architecture：API 治理。
在这篇 SIG Architecture 聚焦访谈中，我们采访了 API 治理子项目负责人 Jordan Liggitt。
介绍
FM：Jordan 你好，感谢你接受采访。请先简单介绍一下你自己、你的职责，以及你是如何参与 Kubernetes 的。
JL：我叫 Jordan Liggitt。我是一名基督徒、丈夫、四个孩子的父亲，白天在 Google 做软件工程师，私下还是个业余音乐人。 我出生在德克萨斯州（现在也仍然喜欢把那里称作自己的起点），但我人生大部分时间都生活在北卡罗来纳州。
我从 2014 年开始参与 Kubernetes。当时我在 Red Hat 负责认证和授权， 提交给 Kubernetes 的第一个 PR 是尝试给 Kubernetes API 服务器 增加一个 OAuth 服务器。 那个 PR 最终一直停留在 WIP 状态，没有合并。 后来我换了一种方式，在另一个项目里以“叠加在核心 Kubernetes API 服务器之上”的思路来实现（这也可以看作后文的一个伏笔）， 六个月后我关闭了那个 PR。
尽管开局如此，我还是持续参与了进来，帮助构建 Kubernetes 的认证与授权能力，
并从早期的 Beta API（例如 v1beta3）到 v1 的过程中参与核心 Kubernetes API 的定义与演进。
基于这些贡献，我在 2016 年被标记为 API reviewer，并在 2017 年成为 API approver。
现在，我在 SIG Architecture 里共同负责 API 治理和代码组织两个子项目，同时也是 SIG Auth 的技术负责人。
FM：那你是什么时候开始具体参与 API 治理项目的？
JL：大约在 2019 年。
API 治理的目标与范围
FM：你会如何描述这个子项目的主要目标，以及它介入的领域？
这个领域覆盖 Kubernetes 的各种 API，而且有一些“大家未必意识到它是 API”的接口： 命令行参数、配置文件、二进制如何运行、它们如何与容器运行时这类后端组件通信，以及如何持久化数据。 很多人提到“API”时只想到 REST API。 它当然是最大、最显眼、受众最多的一类，但这些其他表面同样也是 API。 它们的受众更窄，因此灵活性更高一些，但依然需要认真对待。
我们的目标是在保持稳定的同时继续推动创新。 如果你什么都不改，稳定当然最容易做到，但那也和演进、增长的目标相冲突。 所以我们要在“保持稳定”和“允许变化”之间取得平衡。
FM：说到变化。为了确保一致性和质量（这显然也是这个项目存在的原因之一）， Kubernetes 变更生命周期里有哪些具体的质量门禁？ API 治理是在发布周期中介入，还是通过前置指南介入，或者是在两者之间？ 你们在哪些时间点来确保这个职责真正落地？
JL：我们有指南和约定， 既包含 API 通用规范，也包含 API 变更规范。 这些都是“活文档”，会随着新场景不断更新。 它们内容很多、也比较密集，所以我们还会在设计阶段或实现阶段实际参与来配合。
有时候受限于带宽，团队会在没有得到 API Review 反馈的情况下先推进设计。这没问题，但这也意味着实现开始时才会进行 API 评审， 届时可能会出现比较大范围的反馈。 因此，无论是创建新 API，还是修改既有 API，我们都会在设计阶段或实现阶段介入。
FM：这是发生在 Kubernetes Enhancement Proposal（KEP）流程里吗？ 既然增强功能必须走 KEP，我理解其中一部分会和 API 治理交叉。
JL：KEP 的详细程度差异很大。 有些 KEP 会直接给出 API 定义。遇到这种情况，我们就可以在设计阶段做 API 评审， 随后实现阶段主要就是核对是否忠实于设计。
尽早介入是理想状态。但有些 KEP 更偏概念，把细节留给实现阶段。 这并不错误，只是意味着实现会更偏探索式。这样 API Review 的介入就会更晚， 并且可能会建议结构性调整。
无论哪种方式都有取舍：前期做更详细的设计，还是在实现中迭代发现。 不同人和团队有不同工作方式，我们保持灵活，也乐于在前期或实现阶段提供咨询。
FM：这让我想到 Fred Brooks 在《人月神话》中提到的观点： 概念完整性是产品质量的核心。无论流程怎么组织，总得有一个环节去审视即将落地的内容， 确保概念完整性。Kubernetes 到处都在使用 API（对外和对内都有）， 所以 API 治理对维护这种完整性至关重要。这个是如何被固化下来的？
JL：是的，约定文档沉淀了我们长期积累的模式：不同场景下该怎么做。 我们还有自动化 lint 和检查项，来保障例如 spec/status 语义这类模式的正确性。 这些自动化工具能在人工遗漏时帮助我们发现问题。
当新场景出现时（而且一直在出现），我们会思考应对方式，并把结论回灌到文档和工具里。 有时需要尝试几轮，才能收敛到一个真正好用的方案。
FM：确实。每次新的互动都会让指南更好。
JL：没错。有时候第一种做法最后会被证明不够好， 可能要经历两三次迭代才能得到稳健的结果。
Custom Resource Definition 带来的影响
FM：在你的经验里，有没有某个变化、事件或领域特别值得一提，或者特别复杂、特别有意思？
JL：真正的分水岭是 Custom Resources。 在那之前，每个 API 都是我们手工定义并完整评审的。 虽然也有不一致之处，但每个类型和字段我们都清楚、也都能控制。
Custom Resources 出现之后，任何人都可以定义任何内容。 第一个版本甚至不要求 schema。 这让它功能极其强大，立即释放了创新空间，但也让我们在稳定性和一致性方面开始追赶。
当 Custom Resources 晋升到 GA 后，schema 成为必需， 但出于向后兼容仍保留了一些“逃生口”。 从那时起，我们一直在努力让 CRD 作者获得与内置资源接近的校验能力。 而 CRD 的内置校验规则也只是最近几个版本才达到 GA。
所以，CRD 开启了“几乎任何内容都可以定义”的阶段。 而内置校验规则是第二个重要里程碑：把一致性重新带回来。
这一路上的三个核心主题是：定义 schema、校验数据，以及处理既有的无效数据。 借助渐进式收紧校验（在不破坏现有对象的前提下允许数据逐步改进）， 我们现在可以在不破坏既有对象的情况下，引导 CRD 作者遵循约定。
API 治理在整体中的位置
FM：API 治理和 SIG Architecture、API Machinery 分别是什么关系？
JL：API Machinery 提供的是构建 API 的实际代码和工具。 他们不会去评审存储、网络、调度等领域的 API 本身。
SIG Architecture 负责系统整体方向，并与 API Machinery 协作， 确保系统能力能支撑这个方向。 API 治理则和其他基于这套基础设施构建能力的 SIG 协作，定义约定与模式， 确保大家以一致方式使用 API Machinery 提供的能力。
FM：谢谢，这样流程就很清晰了。再回到发布周期： 增强冻结、代码冻结这些阶段会改变你们的工作负载吗？还是说 API 治理更多是持续性的工作？
JL：我们主要在两个地方介入：设计和实现。 增强冻结前，设计相关介入会增加；代码冻结前，实现相关介入会增加。 不过很多工作会跨多个发布周期，所以即便是在相对平缓的阶段， 也始终会有一些面向未来版本的设计与实现在推进。 在这些高强度时段之间，我们通常会有时间投入长期设计工作。
我们看到的一个反模式是：团队构思一个大特性几个月， 然后在增强冻结前三周才拿出来说“这是设计，请评审”。 对这类有 API 影响的大变更，更好的做法是尽早让 API 治理参与进来。
而且发布周期里确实有适合做这件事的窗口期， 比如两个冻结阶段之间，大家带宽相对更充足。 这是做长期评审工作的最佳时机。
如何参与
FM：很明确。那从团队协作和新贡献者角度看，大家可以如何参与 API 治理？ 应该从什么入手？
JL：通常最好的办法是跟一个具体变更，而不是试图一次性学完所有东西。 挑一个小 API 变更，可以是别人正在做的，也可以是你自己想做的， 然后完整观察它的全流程：设计、实现、评审。
高带宽评审（例如视频实时讨论）通常非常有效。 如果你正在做或跟踪某个变更，可以问问是否能约个时间一起过设计或 PR。 旁听这类讨论会非常有帮助。
先从小变更开始，再做更大的，再到一个全新的 API。 这样你会逐步理解这些约定在实践中是如何应用的。
FM：非常好。最后还有什么想补充的吗？
JL：有。我们之所以如此重视兼容性和稳定性，是为了用户。 对贡献者来说，这些要求有时像痛苦的阻碍，妨碍重构或带来繁琐工作； 但用户已经把自己的系统和我们集成在一起，而我们对他们有承诺： 我们希望他们相信，我们不会打破这份契约。 所以即使这意味着更多工作、更慢节奏，甚至需要重复实现，我们依然选择稳定性。
我们并不是想设置障碍，而是希望让用户有更好的使用体验。
我们很多问题都在关注未来：你现在想做的这个东西， 以后如何演进而不破坏兼容性？ 我们假设未来会知道得更多，因此希望设计能为未来变化留出空间。
我们也假设自己会犯错。那关键问题就是：如何给自己留下改进通道， 同时继续履行兼容性承诺？
FM：完全同意。Jordan，谢谢你，我想我们已经覆盖了所有关键点。 这次访谈让大家对 API 治理项目及其在 Kubernetes 全局中的作用有了非常清晰的认识。
JL：谢谢。