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、CustomResourceDefinitionCRD与 webhook具体包括 API 注册与发现、通用 CRUD 语义、准入控制admission control、编解码、转换、默认值、OpenAPI、informer 库、垃圾回收、命名空间生命周期与客户端库。这也解释了年度报告中为什么会出现从 Consistent Reads from CacheAPI server 读路径到 Remove gogo protobuf编解码层再到 CRD Validation RatchetingCRD 校验等跨度极大的 KEP——它们全部落在上述 scope 之内。值得注意的是章程明确说明单个 API 的内容归 SIG Architecture 所有charter.md即 API Machinery 管的是 API 的机制而非语义。2025 年该 SIG 的治理班子见 README由两位 ChairDavid Eads/Red Hat、Federico Bongiovanni/Google和三位 Tech LeadDavid Eads、Joe Betz/Google、Stefan Schimanski/Upbound构成其中 Stefan Schimanski 是在 2024 年正式加入的第三位 tech lead见 annual-report-2024.md。二、2025 年三大结构性动作新子项目、新工作组、新例会年度报告开篇即点明了 2025 年 SIG 在组织结构上的三件大事这比单个 KEP 更值得先理解因为它们决定了后续若干年的工作方向。1. 新子项目 crdify 与 kube-api-linterSIG 在 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/crdifykube-api-linter 对应kubernetes-sigs/kube-api-linter并各自关联 OWNERS 文件符合 Kubernetes 社区对子项目必须拥有活跃 OWNERS的治理要求。2. 新工作组 WG AI IntegrationSIG 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 ValidationKEP-5073、CRD Validation RatchetingKEP-4008乃至 crdify、kube-api-linter 都是这些目标的直接延续体现了社区工作组孵化→子项目承接的典型生命周期。三、2025 年 KEP 全景Stable 毕业的七项关键能力年度报告第 4 节给出了 2025 年三个版本周期v1.33、v1.34、v1.35的完整 KEP 清单。先看晋级Stable的七项它们共同刻画了控制平面更快、更稳、更安全的演进主线1. Consistent Reads from CacheKEP-2340v1.34 Stable从 watch cache 提供一致性读替代直接读 etcd。官方描述为 dramatically improving API server scalability大幅提升 API server 可扩展性。其核心思想是让 API server 的读路径尽量命中内存中的 watch cache只有必要时才下沉到 etcd从而显著降低 etcd 负载与读延迟。该项 2024 年已进入 Beta见 annual-report-2024.md2025 年正式毕业。2. Streaming List Responses / Streaming EncodingKEP-5116v1.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 DeletionKEP-5080v1.34 Stable为命名空间删除建立确定性的资源删除顺序。官方明确指出这一特性用于缓解非确定性删除带来的安全风险并关联了漏洞CVE-2024-7598。非确定性的删除顺序可能让资源以意外的先后次序被清理进而被利用有序删除保证了可预期的回收行为。4. Resilient Watch Cache InitializationKEP-4568v1.34 Stable让 watch cache 的初始化对故障更具韧性官方描述为 improving control plane robustness提升控制平面健壮性。初始化阶段的失败不再轻易导致整个缓存重建或级联问题。5. Remove gogo protobuf dependencyKEP-5589v1.35 Stable将 Kubernetes API 类型从已弃用的 gogo protobuf 库迁移到标准 Go protobuf 库。这是依赖治理层面的重要里程碑gogo protobuf 长期缺乏维护迁移到标准库降低了供应链风险并简化了工具链。该 KEP 在报告中同时出现在 Stable 毕业名单与 v1.35 Stable 版本清单中。6. Transition from SPDY to WebSocketsKEP-4006v1.35 完成完成 exec/attach/port-forward 从 SPDY 协议向 WebSockets 的全面迁移。SPDY 已被现代 HTTP/2 取代且在各语言生态中支持参差不齐WebSocket 是标准化的替代方案。该项在 2024 年已列入 Stable 名单见 annual-report-2024.md2025 年完成收尾。7. Coordinated Leader ElectionKEP-3962v1.33 起协调式领导者选举官方描述为 Leader election improvements for better control plane stability改进领导者选举以提升控制平面稳定性。它允许多个控制器组件在共享协调机制下更平滑地交接领导权减少因领导者抖动导致的控制面不稳定。四、2025 年进入 Beta 的 KEP能力放大的前夜与 Stable 并列的是 2025 年晋级Beta的四项它们大多会在后续版本继续走向 GAWatch List / Streaming Initial ListKEP-3157client-go 在 v1.34 中默认启用允许 informer 通过流式 watch 获取初始数据替代分块chunkedLIST官方描述为 reducing API server memory pressure降低 API server 内存压力。它与 KEP-5116 同属流式化主线一个作用于 informer 的初始数据获取一个作用于 LIST 响应的编码方式。Declarative Validation of Kubernetes Native TypesKEP-5073基于 CEL 的声明式校验规则使用 validation-gen 代码生成器为内建 Kubernetes 类型生成校验逻辑v1.33 起默认启用。这是用声明式校验替代手写校验函数的关键一步也是 crdify 与 Declarative APIs and Linters 子项目生态的核心技术底座之一。Snapshottable API Server CacheKEP-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.35CEL for CRD AdditionalPrinterColumnsKEP-4595v1.34让 CRD 的 AdditionalPrinterColumnskubectl get输出列支持 CEL 表达式。此前该字段仅支持 JSONPath引入 CEL 后表达能力更强、语义更明确与 CRD 校验全面 CEL 化KEP-5073、KEP-4008形成呼应。Graceful Leader TransitionKEP-5366v1.35在 Coordinated Leader ElectionKEP-3962基础上进一步实现优雅的领导权交接减少交接窗口内的服务中断。Stale Controller HandlingKEP-5647v1.35处理陈旧控制器问题——即运行了较旧代码版本的控制器实例它们可能不理解集群当前的状态或新 API 语义需要被识别并妥善处理以提升控制平面的整体正确性。六、子项目与工作组全景新增与持续并存年度报告用专门小节汇总了子项目与工作组清单这些条目同样可在 sigs.yaml 中找到登记与 OWNERS 关联子项目Subprojects2025 新增crdify、kube-api-linter2025 持续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-machineryapimachinery 核心库、server-*apiserver/aggregator/crd/frameworks/sdk/binaries、kubernetes-clients多语言客户端、idl-schema-client-pipeline代码生成与 OpenAPI 管线、json/yaml序列化库、control-plane-featuresGC、命名空间、配额等控制器。其中 component-base、server-frameworks 等子项目直接对应 kubernetes 主仓库staging/src/k8s.io/下的预发布模块见 README 的 owners 列表。工作组Working Groups2025 新增AI Integration2025 持续Structured Logging结构化日志其档案见 archive/wg-structured-logging七、贡献者认可2025 年三个方向的代表人物年度报告公布了 2025 年 SIG API Machinery 贡献者奖项2025 Contributor Awards三位获奖者分别对应本年度三条技术主线获奖者代表贡献对应技术方向Aaron Prindleaaron-prindle推动声明式校验框架KEP-5073创建 validation-gen 代码生成器Declarative ValidationJoel SpeedJoelSpeed对 kube-api-linter 的宝贵贡献改进 API 质量与一致性工具API 质量工具链Yongrui Linyongruilinvalidation-gen 的大量亲手开发与打磨并集成进 Kubernetes 代码库Declarative Validation这三位获奖者的工作高度集中于声明式 API 与校验这一 2025 年 SIG 的绝对主线也从侧面印证了新子项目crdify、kube-api-linter与 KEP-5073 之间的有机联系。八、社区传播两场 KubeCon 与两篇特性博客年度报告第 3 节记录了 2025 年的社区级更新KubeCon EU 2025伦敦SIG API Machinery 项目更新与发布规划演讲Joe Betz, GoogleKubeCon NA 2025亚特兰大主题演讲SIG API Machinery and AI: What Comes NextJoe 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 需要外部帮助的四个领域这些也是潜在的贡献入口Server Side ApplySSA声明式对象合并语义的持续演进Resource Lifecycle垃圾回收Garbage Collection、Storage Version Migrator、命名空间删除、CRD 生命周期等Controllers Infrastructure控制器基础设施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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考