聚焦 SIG Architecture：API治理
Source: Kubernetes Blog
（未提供需要翻译的正文内容。如需翻译，请粘贴完整的文章文本。）
SIG Architecture 聚焦 – API 治理
这是 SIG Architecture Spotlight 系列的第五次访谈，涵盖不同子项目。在本期我们采访 Jordan Liggitt，API Governance 子项目的负责人。
介绍
FM: 你好，Jordan，感谢你的时间。请介绍一下你自己、你的角色以及你是如何参与 Kubernetes 的。
JL: 我叫 Jordan Liggitt。是一名基督徒、丈夫、四个孩子的父亲，白天在 Google 做软件工程师，业余时暗中当一名业余音乐人。我出生于德克萨斯（仍然喜欢把它当作我的出生地），但大部分人生都在北卡罗来纳州度过。
我自 2014 年起开始在 Kubernetes 上工作。当时我在 Red Hat 从事身份验证和授权工作，我的第一个 Kubernetes Pull Request 试图向 Kubernetes API Server 添加一个 OAuth 服务器。它一直停留在进行中状态，最终我采用了另一种方式，在一个独立项目中在核心 Kubernetes API Server 之上叠加实现（剧透：这是一种前兆），并在六个月后关闭了该 PR，未合并。
尽管起步不顺，我仍然坚持参与，帮助构建了 Kubernetes 的身份验证和授权能力，并参与了核心 Kubernetes API 的定义和演进——从早期的 v1beta3 等 beta API 到 v1。基于这些贡献，我在 2016 年被标记为 API reviewer，并在 2017 年加入 API approver 行列。
如今，我负责 SIG Architecture 下的 API Governance 与 code‑organization 子项目，并且是 SIG Auth 的技术负责人。
FM: 那么你具体是什么时候加入 API Governance 项目的？
JL: 大约在 2019 年。
API Governance 的目标与范围
FM: 你如何描述该子项目的主要目标和介入领域？
JL:
- 覆盖面： Kubernetes 所拥有的所有各种 API。很多人没有意识到，命令行标志、配置文件、二进制文件的运行方式、它们如何与后端组件（例如容器运行时）通信，以及数据的持久化方式，这些也都是 API。
- 常见误解： “API” 常被认为只有 REST API——这是最大、最显眼、受众最广的那一个。其他表面（如上所述）的受众更窄，灵活性更大，但同样需要慎重考虑。
目标：
- 保持稳定 同时 支持创新。
- 在 “保持稳定” 与 “允许变更” 之间取得平衡。
质量门槛与生命周期参与
FM: 说到变更，为了确保一致性和质量（这显然是该项目存在的原因之一），Kubernetes 变更的生命周期中有哪些具体的质量门槛？API Governance 是在发布周期中介入，还是通过指南在之前介入，亦或是介于两者之间？在什么节点上你们确保角色得到履行？
JL:
- 我们维护 API 通用指南和约定，以及 API 变更指南。这些是活文档，会随着新场景的出现而更新。
- 由于文档篇幅长且密集，我们还会在 设计阶段 或 实现阶段 提供 实操参与。
- 如果某个团队在没有 API Review 反馈的情况下推进设计工作（通常是因为带宽受限），这没有问题——但当进入实现阶段时，API Review 必然会介入，并可能给出大量反馈。
底线： 我们会在 创建新 API 或 修改已有 API 时介入，无论是在设计时还是实现时。
与 KEP 的交互
FM: 这是否发生在 Kubernetes Enhancement Proposal（KEP）流程中？既然 KEP 对增强是强制性的，我想这部分工作会与 API Governance 有交集？
JL:
- 是的，可能会。 KEP 的细节程度各不相同。有些 KEP 会直接包含 API 相关的内容……
Source: …
definitions, allowing us to perform an API review at the design stage and then check fidelity during implementation.
- Other KEPs are more conceptual, leaving details to the implementation. In those cases, API Review typically gets involved later, possibly recommending structural changes.
There’s a trade‑off: detailed design upfront vs. iterative discovery during implementation. Teams work differently, and we’re flexible—happy to consult early or later as needed.
Maintaining Conceptual Integrity
FM: This reminds me of what Fred Brooks wrote in The Mythical Man‑Month about conceptual integrity being central to product quality. No matter how you structure the process, there must be a point where someone looks at what is coming and ensures conceptual integrity. Kubernetes uses APIs everywhere—externally and internally—so API Governance is critical to maintaining that integrity. How is this captured?
JL:
- The conventions document captures patterns we’ve learned over time: what to do in various situations.
- We also have automated linters and checks (e.g., for
spec/statussemantics) that catch issues even when humans miss them. - As new scenarios arise—and they do constantly—we think through how to approach them, then fold the results back into our documentation and tools.
- Sometimes it takes a few attempts before we settle on an approach that works well.
FM: Exactly. Each new interaction improves the guidelines.
JL: Right. And sometimes the first approach turns out to be wrong; it may take two or three iterations before we land on something robust.
The Impact of Custom Resource Definitions
FM: Is there any particular change, episode, or domain that stands out as especially noteworthy, complex, or interesting in your experience?
JL: The watershed moment was Custom Resources.
Prior to that, every API was handcrafted by us and fully reviewed. There were inconsistencies, but we…
(Interview continues…)
API治理 – 访谈记录
自定义资源和内置验证
Speaker: Jordan
“良好且受控的每种类型和字段。当自定义资源出现时，任何人都可以定义任何东西。第一个版本甚至不需要模式。这使它极其强大——能够立即进行更改——但也让我们在稳定性和一致性上一直在追赶。
当自定义资源晋升为正式可用（GA）时，模式变为必需，但仍保留了向后兼容的逃生口。此后，我们一直在努力为 CRD 作者提供与内置资源相当的验证能力。内置验证规则对 CRD 仅在最近几次发布中才正式 GA。
因此，CRD 开启了“任何事皆有可能”的时代。内置验证规则是第二个重要里程碑：恢复一致性。
三个主要主题是定义模式、验证数据以及处理已有的无效数据。通过递进式验证（允许数据在不破坏现有对象的情况下改进），我们现在可以在不破坏整个系统的前提下，引导 CRD 作者遵循约定。”
API治理背景
(访谈在此之后继续。)