企业官网建设流程全解析

Kubernetes SIG API Machinery 2025 年度报告解读：控制平面演进、KEP 落地与 CRD 工具链新生

【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community

本篇基于 Kubernetes Community 仓库中 sig-api-machinery/annual-report-2025.md 年度报告，结合 SIG README、章程、sigs.yaml 及相关工作组的档案资料，系统梳理 SIG API Machinery 在 2025 年（Kubernetes v1.33、v1.34、v1.35 三个版本周期）的核心工作：7 项 KEP 晋级 Stable、5 项进入 Beta、3 项新开 Alpha，以及 crdify、kube-api-linter 两个新子项目和 WG AI Integration 的落地。读完本文，你将掌握 API 服务器可扩展性、声明式校验、Watch 缓存快照等关键特性的来龙去脉，以及这些工作在本仓库中的组织与管理证据。

一、SIG API Machinery 的职责边界：为什么这些 KEP 归它管

在展开年度报告之前，先明确该 SIG 的技术版图。依据 SIG API Machinery Charter 与 README 的官方定义，SIG API Machinery 负责 Kubernetes 集群控制平面的开发与增强，范围覆盖：API server、持久化层（etcd）、controller manager、cloud controller manager、CustomResourceDefinition（CRD）与 webhook，具体包括 API 注册与发现、通用 CRUD 语义、准入控制（admission control）、编解码、转换、默认值、OpenAPI、informer 库、垃圾回收、命名空间生命周期与客户端库。

这也解释了年度报告中为什么会出现从 "Consistent Reads from Cache"（API server 读路径）到 "Remove gogo protobuf"（编解码层）再到 "CRD Validation Ratcheting"（CRD 校验）等跨度极大的 KEP——它们全部落在上述 scope 之内。值得注意的是，章程明确说明"单个 API 的内容归 SIG Architecture 所有"（charter.md），即 API Machinery 管的是 API 的"机制"而非"语义"。

2025 年该 SIG 的治理班子（见 README）由两位 Chair（David Eads/Red Hat、Federico Bongiovanni/Google）和三位 Tech Lead（David Eads、Joe Betz/Google、Stefan Schimanski/Upbound）构成，其中 Stefan Schimanski 是在 2024 年正式加入的第三位 tech lead（见 annual-report-2024.md）。

二、2025 年三大结构性动作：新子项目、新工作组、新例会

年度报告开篇即点明了 2025 年 SIG 在组织结构上的三件大事，这比单个 KEP 更值得先理解，因为它们决定了后续若干年的工作方向。

1. 新子项目 crdify 与 kube-api-linter

SIG 在 2025 年新建了两个子项目，官方表述为 "reflecting ongoing investment in CRD tooling and API quality"（反映对 CRD 工具与 API 质量的持续投入）：

• crdify：聚焦 CRD 工具链。在贡献者奖项中，Aaron Prindle 获奖理由是"推动声明式校验框架（KEP-5073）并创建 validation-gen 代码生成器"，可推断 crdify 属于将 API 定义转化为 CRD 形态的工具方向。
• kube-api-linter：聚焦 API 质量与一致性工具。贡献者奖项中 Joel Speed 的获奖理由即"对 kube-api-linter 项目的宝贵贡献，改进了 API 质量与一致性工具"。

这两个仓库均已登记在 sigs.yaml 的子项目列表中（crdify 对应kubernetes-sigs/crdify，kube-api-linter 对应kubernetes-sigs/kube-api-linter），并各自关联 OWNERS 文件，符合 Kubernetes 社区对子项目"必须拥有活跃 OWNERS"的治理要求。

2. 新工作组 WG AI Integration

SIG API Machinery 在 2025 年发起成立了WG AI Integration。依据其 README 与 charter，该工作组致力于实现 AI/ML 控制平面与 Kubernetes 的无缝集成，并为在 Kubernetes 上大规模部署、管理与运维 AI 应用提供标准化模式；Stakeholder SIG 包括 API Machinery、Apps、Architecture、Auth、CLI 五个。其 2025 年度报告（annual-report-2025.md）显示，作为新成立的工作组，2025 年主要围绕已有的或正在积极开发的 AI/ML 控制平面组件展开讨论，包括 agent-sandbox、modelcontextprotocol/registry、toolhive、agentgateway 等项目，探索如何将它们原生集成进 Kubernetes。WG 的产出边界清晰：不开发 AI/ML 框架、不管理推理负载、不管理加速器设备，最终退出标准是"Kubernetes 项目对如何与这些新兴系统集成给出共享建议"。

3. 新例会：Declarative APIs and Linters 子项目会议

报告明确写道：SIG 创建了Declarative APIs and Linters子项目例会（每两周一次，周二 9:00 PT），承接已退休的 WG API Expression 的目标，首次会议于 2025 年 9 月 23 日举行，该子项目涵盖新的 crdify 与 kube-api-linter 两个仓库。

从 archive/wg-api-expression/README.md 可以看到被承接的 WG API Expression 的完整遗产：这是一个由 SIG API Machinery 与 SIG Architecture 联合发起的项目，目标是"让 API 作者更好地服务 API 消费者"，其交付物包括——文档化的 API schema 特性"期望状态"（unions、不可变字段、静态字段校验、默认值等应如何表达）；API 演进（版本间与版本内变更）的分类指南（100% 安全、不安全但必要、不允许）；可作 presubmit 运行的 API 变更安全性/合规性评估工具；以及"ratcheting"（棘轮）技术——逐步安全地推出边际不安全变更。可以说，2025 年的 Declarative Validation（KEP-5073）、CRD Validation Ratcheting（KEP-4008）乃至 crdify、kube-api-linter 都是这些目标的直接延续，体现了社区"工作组孵化→子项目承接"的典型生命周期。

三、2025 年 KEP 全景：Stable 毕业的七项关键能力

年度报告第 4 节给出了 2025 年三个版本周期（v1.33、v1.34、v1.35）的完整 KEP 清单。先看晋级Stable的七项，它们共同刻画了控制平面"更快、更稳、更安全"的演进主线：

1. Consistent Reads from Cache（KEP-2340，v1.34 Stable）

从 watch cache 提供一致性读，替代直接读 etcd。官方描述为 "dramatically improving API server scalability"（大幅提升 API server 可扩展性）。其核心思想是：让 API server 的读路径尽量命中内存中的 watch cache，只有必要时才下沉到 etcd，从而显著降低 etcd 负载与读延迟。该项 2024 年已进入 Beta（见 annual-report-2024.md），2025 年正式毕业。

2. Streaming List Responses / Streaming Encoding（KEP-5116，v1.34 Stable）

为 JSON 与 Protobuf 的 LIST 响应引入流式编码，官方描述为 "eliminating large memory allocations on the API server"（消除 API server 上的大内存分配）。其价值在于：当列表数据量很大时，传统一次性构造完整响应体需要与数据量成正比的内存；流式编码边序列化边发送，使 API server 的内存占用与数据规模解耦。Kubernetes v1.33 发布博客曾以《Streaming List responses》为主题进行社区传播（见年度报告第 3 节）。

3. Ordered Namespace Deletion（KEP-5080，v1.34 Stable）

为命名空间删除建立确定性的资源删除顺序。官方明确指出这一特性用于缓解非确定性删除带来的安全风险，并关联了漏洞CVE-2024-7598。非确定性的删除顺序可能让资源以意外的先后次序被清理，进而被利用；有序删除保证了可预期的回收行为。

4. Resilient Watch Cache Initialization（KEP-4568，v1.34 Stable）

让 watch cache 的初始化对故障更具韧性，官方描述为 "improving control plane robustness"（提升控制平面健壮性）。初始化阶段的失败不再轻易导致整个缓存重建或级联问题。

5. Remove gogo protobuf dependency（KEP-5589，v1.35 Stable）

将 Kubernetes API 类型从已弃用的 gogo protobuf 库迁移到标准 Go protobuf 库。这是依赖治理层面的重要里程碑：gogo protobuf 长期缺乏维护，迁移到标准库降低了供应链风险并简化了工具链。该 KEP 在报告中同时出现在 Stable 毕业名单与 v1.35 Stable 版本清单中。

6. Transition from SPDY to WebSockets（KEP-4006，v1.35 完成）

完成 exec/attach/port-forward 从 SPDY 协议向 WebSockets 的全面迁移。SPDY 已被现代 HTTP/2 取代，且在各语言生态中支持参差不齐；WebSocket 是标准化的替代方案。该项在 2024 年已列入 Stable 名单（见 annual-report-2024.md），2025 年完成收尾。

7. Coordinated Leader Election（KEP-3962，v1.33 起）

协调式领导者选举，官方描述为 "Leader election improvements for better control plane stability"（改进领导者选举以提升控制平面稳定性）。它允许多个控制器组件在共享协调机制下更平滑地交接领导权，减少因领导者抖动导致的控制面不稳定。

四、2025 年进入 Beta 的 KEP：能力放大的前夜

与 Stable 并列的是 2025 年晋级Beta的四项，它们大多会在后续版本继续走向 GA：

• Watch List / Streaming Initial List（KEP-3157）：client-go 在 v1.34 中默认启用，允许 informer 通过流式 watch 获取初始数据，替代分块（chunked）LIST，官方描述为 "reducing API server memory pressure"（降低 API server 内存压力）。它与 KEP-5116 同属"流式化"主线，一个作用于 informer 的初始数据获取，一个作用于 LIST 响应的编码方式。
• Declarative Validation of Kubernetes Native Types（KEP-5073）：基于 CEL 的声明式校验规则，使用 validation-gen 代码生成器为内建 Kubernetes 类型生成校验逻辑，v1.33 起默认启用。这是"用声明式校验替代手写校验函数"的关键一步，也是 crdify 与 Declarative APIs and Linters 子项目生态的核心技术底座之一。
• Snapshottable API Server Cache（KEP-4988）：允许 watch cache 生成高效的"时间点快照"（point-in-time snapshots），使分页 LIST 请求可以完全由缓存服务（v1.34 起为 Beta）。Kubernetes v1.34 发布博客以《Snapshottable API server cache》为主题介绍该特性。
• List from Cache Snapshot：与 KEP-4988 同属一个问题空间——kube-apiserver 可以从缓存快照而非 etcd 服务"此前资源版本"（previous resource versions）的 LIST 请求。两个条目在报告中共同指向 4988 号 issue，可视为同一能力的两个侧面：一个是"快照生成"，一个是"快照消费"。

五、2025 年新开 Alpha 的 KEP：三条前沿探索

年度报告列出 2025 年新进入Alpha的三项，分别对应 v1.34 与 v1.35：

• CEL for CRD AdditionalPrinterColumns（KEP-4595，v1.34）：让 CRD 的 AdditionalPrinterColumns（kubectl get输出列）支持 CEL 表达式。此前该字段仅支持 JSONPath，引入 CEL 后表达能力更强、语义更明确，与 CRD 校验全面 CEL 化（KEP-5073、KEP-4008）形成呼应。
• Graceful Leader Transition（KEP-5366，v1.35）：在 Coordinated Leader Election（KEP-3962）基础上进一步实现"优雅的领导权交接"，减少交接窗口内的服务中断。
• Stale Controller Handling（KEP-5647，v1.35）：处理"陈旧控制器"问题——即运行了较旧代码版本的控制器实例，它们可能不理解集群当前的状态或新 API 语义，需要被识别并妥善处理，以提升控制平面的整体正确性。

六、子项目与工作组全景：新增与持续并存

年度报告用专门小节汇总了子项目与工作组清单，这些条目同样可在 sigs.yaml 中找到登记与 OWNERS 关联：

子项目（Subprojects）

• 2025 新增：crdify、kube-api-linter
• 2025 持续：cel-admission-webhook、component-base、control-plane-features、idl-schema-client-pipeline、json、kubernetes-clients、server-api-aggregation、server-binaries、server-crd、server-frameworks、server-sdk、universal-machinery、yaml

从命名即可看出该 SIG 的资产结构：universal-machinery（apimachinery 核心库）、server-*（apiserver/aggregator/crd/frameworks/sdk/binaries）、kubernetes-clients（多语言客户端）、idl-schema-client-pipeline（代码生成与 OpenAPI 管线）、json/yaml（序列化库）、control-plane-features（GC、命名空间、配额等控制器）。其中 component-base、server-frameworks 等子项目直接对应 kubernetes 主仓库staging/src/k8s.io/下的预发布模块（见 README 的 owners 列表）。

工作组（Working Groups）

• 2025 新增：AI Integration
• 2025 持续：Structured Logging（结构化日志，其档案见 archive/wg-structured-logging）

七、贡献者认可：2025 年三个方向的代表人物

年度报告公布了 2025 年 SIG API Machinery 贡献者奖项（2025 Contributor Awards），三位获奖者分别对应本年度三条技术主线：

这三位获奖者的工作高度集中于"声明式 API 与校验"这一 2025 年 SIG 的绝对主线，也从侧面印证了新子项目（crdify、kube-api-linter）与 KEP-5073 之间的有机联系。

八、社区传播：两场 KubeCon 与两篇特性博客

年度报告第 3 节记录了 2025 年的社区级更新：

• KubeCon EU 2025（伦敦）：SIG API Machinery 项目更新与发布规划演讲（Joe Betz, Google）
• KubeCon NA 2025（亚特兰大）：主题演讲"SIG API Machinery and AI: What Comes Next"（Joe Betz, Google 与 David Eads, Red Hat），呼应了 WG AI Integration 的成立
• Kubernetes v1.33 博客：Streaming List Responses 特性介绍
• Kubernetes v1.34 博客：Snapshottable API server cache 特性介绍

两条传播线索清晰可见：一是对外讲清楚"流式化"（Streaming List、Snapshottable Cache）这一年度最大的性能主线；二是面向 AI 时代布局下一阶段方向。此外，按照社区治理要求，committee-steering/governance/sig-governance.md 规定的运营任务（README、CONTRIBUTING、sigs.yaml 准确性复核，会议纪要归档等）在 2025 年全部完成，勾选状态详见 annual-report-2025.md 的 Operational 小节。

九、需要帮助的领域：四个长期人力缺口

年度报告第 2 节明确列出了 SIG 需要外部帮助的四个领域，这些也是潜在的贡献入口：

1. Server Side Apply（SSA）：声明式对象合并语义的持续演进
2. Resource Lifecycle：垃圾回收（Garbage Collection）、Storage Version Migrator、命名空间删除、CRD 生命周期等
3. Controllers Infrastructure：控制器基础设施
4. Clients ecosystem：多语言客户端生态

这些领域与 archive/wg-api-expression/README.md 中"完成 SSA 并实现缺失的 API 构造"的未竟目标相互印证，说明 SIG 有意在 2026 年继续投入。对希望参与 Kubernetes 核心控制平面开发的贡献者而言，这四个方向就是官方盖章的"招人启事"。

十、从年度报告到社区资产：如何在本仓库中继续深入

如果你希望基于这份年度报告进一步研究，本仓库提供了完整的治理与档案证据链：

• 阅读 sig-api-machinery/README.md 获取 SIG 全部子项目的 OWNERS 链接、例会时间与领导层信息；例会包含常规 SIG 会议、Kubebuilder 会议，以及 2025 年新增的 Declarative APIs and Linters 会议
• 对比 sig-api-machinery/annual-report-2024.md 可看出跨年度演进脉络（例如 Consistent Reads from Cache、Watch List、SPDY→WebSockets 均从 2024 年 Beta 延续到 2025 年毕业）
• 查看 archive/wg-api-expression/README.md 了解被 Declarative APIs and Linters 子项目承接的历史使命
• 查看 archive/wg-ai-integration/charter.md 与 archive/wg-ai-integration/annual-report-2025.md 追踪 AI 集成工作组的进展
• 在 sigs.yaml 中核对所有子项目与工作组的最新登记状态

结语

回顾 2025 年，SIG API Machinery 交出的成绩单可以概括为三条主线：读路径性能革命（Consistent Reads from Cache、Streaming List、Snapshottable Cache 三者合力，让 API server 的大规模读请求从 etcd 迁移到内存缓存与流式传输）；声明式 API 生态成型（KEP-5073 默认启用、CRD Ratcheting 毕业、crdify 与 kube-api-linter 双子项目落地、Declarative APIs and Linters 例会启动）；面向 AI 时代的组织布局（WG AI Integration 成立，KubeCon NA 主题演讲定调）。这三条主线共同指向同一个判断：Kubernetes 控制平面正在从"功能完善"走向"规模化性能与可编程性"的深水区，而 SIG API Machinery 依旧是这场演进的核心引擎。

【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community