基于 SIG Cloud Provider 2025 年度报告Kubernetes 云厂商集成的最新进展与生态全景【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community导读本文围绕 Kubernetes 社区仓库中 SIG Cloud Provider 的 2025 年度报告annual-report-2025.md系统解读该 SIG 在 2025 年的三大核心事件——基于 informer 的 watch 型路由控制器调谐 KEP-5237、Kubernetes Resource OrchestratorKRO正式成为官方子项目、Cloud Provider Equinix Metal 弃用公告并结合 sigs.yaml、charter.md 与 README.md 中的源码级配置梳理其 12 个云厂商子项目生态、两个关联工作组的治理结构。读完本文你将掌握 SIG Cloud Provider 在 v1.33v1.35 演进期的技术方向、subproject 组织方式与运营治理模式并能据此快速定位社区中的相关代码与文档入口。一、2025 年度核心工作与项目健康度总览SIG Cloud Provider 在 2025 年共列出了三项值得社区关注的重点工作分别覆盖核心控制器重构子项目生态扩张与服务生命周期管理三个维度KEP-5237基于 informer 的 watch 型路由控制器Route Controller调谐——这是 2025 年 SIG 在控制器实现层面最重要的技术推进于 v1.35 进入 Alpha 阶段Kubernetes Resource OrchestratorKRO被 SIG 接纳为官方子项目——标志着 SIG 的业务边界从云厂商集成进一步延伸到复杂自定义资源的创建与管理Cloud Provider Equinix Metal 弃用公告——由于底层云服务本身正在被退役对应的 cloud provider 实现进入弃用流程。这三件事恰好对应了 SIG 治理中KEP 推进、子项目进出、技术债清理三类典型活动与社区对年度报告中值得突出的工作的建议清单KEP 重大进展、非 KEP 追踪的重要举措、技术债偿还、治理与领导层变更一一吻合。值得注意的一个细节是虽然 Equinix Metal 的云服务已进入退役阶段但在年度报告的Continuing持续运营subproject 列表中provider-equinix-metal仍然保留。这表明弃用是一个渐进过程——在相关代码仓库与 OWNERS 文件完成最终迁移或归档之前子项目仍处于被 SIG 托管的状态读者可结合 sigs.yaml 中 subproject 的 OWNERS 声明持续跟踪其变化。二、KEP-5237基于 informer 的 watch 型路由控制器调谐2.1 该 KEP 在年度报告中的位置年度报告的 KEP 工作清单面向 v1.33、v1.34、v1.35 三个版本中2025 年处于Alpha阶段的 KEP 只有一项5237 - Watch-based route controller reconciliation—— 目标版本 v1.35该 KEP 的完整名称是Watch-based route controller reconciliation using informers即使用 informer 机制实现路由控制器的 watch 型调谐。2.2 从 CCM 架构理解该 KEP 的动机要理解这个 KEP 的意义需要先回到 SIG Cloud Provider 的核心产物之一——cloud-controller-managerCCM。根据 charter.md 的 Scope 定义SIG 负责维护被所有云厂商消费的公共接口common interfaces作为集群外部out-of-tree云组件运行的cloud-controller-manager由 CCM 启动、与云厂商资源交互的核心控制器core controllers。路由控制器Route Controller正是这些核心控制器之一它在集群节点注册后负责在底层云网络如 VPC 路由表中为每个节点创建对应的路由条目保证 Pod 网络跨节点可达。从年度报告给出的 KEP 名称可以推断传统实现依赖周期性的全量列举list来比对期望状态与实际路由而 KEP-5237 的目标是将其改造为基于 informer 的事件驱动调谐——通过监听节点等资源的事件变化只在必要时触发路由的增删改从而减少对云厂商 API 的无效调用、降低控制器自身的负载与延迟。informerwatch两个关键词直接点明了这一从轮询式到事件驱动式的实现路径转变以上对实现动机的阐述是基于 KEP 名称与 CCM 控制器职责的合理推断具体实现细节以 kubernetes/enhancements 仓库中该 KEP 的正文 为准。2.3 为什么这对云厂商中立性很重要SIG Cloud Provider 的使命在 sigs.yaml 与 README.md 中表述得非常明确确保 Kubernetes 生态以对公有云和私有云厂商都中立的方式演进并为所有厂商建立必须满足的标准与要求以保证与 Kubernetes 的最优集成。路由控制器是每个云厂商都要实现的核心逻辑之一因此任何对其调谐模型的改进都会通过kubernetes-cloud-provider子项目同步影响 AWS、Azure、GCP 等所有厂商的实现——这正是该 KEP 由 SIG 层面统一推进的原因。三、Kubernetes Resource OrchestratorKRO2025 年新晋官方子项目3.1 KRO 是什么年度报告宣布Kubernetes Resource OrchestratorKRO已被 SIG 正式接纳为官方子项目。在 README.md 中该子项目的定位被描述为一句话Simplify the creation and management of complex custom resources for Kubernetes. 简化 Kubernetes 中复杂自定义资源的创建与管理。结合 SIG 近年对以扩展add-on形式提供云集成的持续投入见 charter.md 的 mission 描述KRO 的加入意味着 SIG 在声明式资源编排方向上承担起新的职责通过更简单的抽象帮助用户组合和管理复杂的 CustomResourceDefinitionCRD资源降低多云场景下资源交付的复杂度。3.2 子项目准入的仓库证据在 sigs.yaml 中kro子项目的条目如下- name: kro description: Simplify the creation and management of complex custom resources for Kubernetes. owners: - https://raw.githubusercontent.com/kubernetes-sigs/kro/refs/heads/main/OWNERS可以看到新子项目在sigs.yaml中登记了独立的 OWNERS 文件其代码托管在kubernetes-sigs组织下。这符合 charter.md 中任何新的云厂商相关子项目除非已有其他 SIG 赞助均由本 SIG 拥有的管辖原则也符合 Kubernetes 社区以 OWNERS 文件界定代码所有权的通用治理模式。3.3 与 SIG 既有版图的关系KRO 的加入使 SIG Cloud Provider 的子项目版图从纯云厂商集成扩展为三类类别子项目核心组件与迁移kubernetes-cloud-provider、cloud-provider-extraction-migration资源编排kro2025 年新增云厂商实现provider-alibaba-cloud、provider-aws、provider-azure、provider-equinix-metal、provider-gcp、provider-huaweicloud、provider-ibmcloud、provider-oci、provider-openstack、provider-vsphere这种核心库 编排层 厂商实现的三角结构正是该 SIG 强调云厂商中立性、同时允许各厂商独立演进的具体体现。四、Cloud Provider Equinix Metal 弃用服务生命周期管理年度报告公布的第三项事件是Cloud Provider Equinix Metal 的弃用公告原因是Equinix Metal 云服务本身正在被退役the service is being retired。这是一次典型的跟随上游服务生命周期的子项目退出案例当底层云服务停止运营后对应的 cloud provider 集成代码便失去了运行依托。从治理角度这提醒所有基于 Kubernetes 的云集成使用者在选型云厂商插件时应关注厂商服务的长期可用性SIG 的 subproject 列表sigs.yaml是判断某个 provider 是否仍被官方托管的第一手依据处于弃用流程中的 provider其代码与 OWNERS 仍保留在 SIG 版图中但会逐步停止功能迭代。五、2025 年社区传播两场 KubeCon Deep Dive年度报告记录了 SIG 在 2025 年的两场社区级技术分享均为 KubeCon 的 SIG Cloud Provider Deep Dive 环节KubeCon EU 2025Testing Cloud Controller Managers——聚焦 CCM 的测试方法与测试框架。这与 charter.md 中Testing and testing frameworks to ensure vendor neutrality across all cloud providers通过测试与测试框架确保跨所有云厂商的中立性的职责直接对应也与 charter 中与 SIG Testing、SIG Release 协作确保各云厂商在 testgrid 上积极测试并上报结果的跨 SIG 流程相印证KubeCon NA 2025Expanding Our Mission——主题呼应 SIG 使命的扩张与 KRO 子项目的加入、业务边界的拓展形成时间线上的呼应。对于想深入了解 CCM 测试体系的读者可以从 charter.md 中列出的测试资产入手Kubernetes 主仓库的test/e2e/cloud目录云厂商特定功能的 e2e 测试以及各 provider 子项目自己的测试基础设施如provider-aws-test-infra、provider-ibmcloud-test-infra均在 sigs.yaml 与 sigs.yaml 中登记。六、Subprojects 全景核心库、迁移计划与 12 个云厂商实现6.1 2025 年的子项目清单年度报告将子项目分为New in 2025与Continuing两类完整清单如下New in 2025kro详见上文第三节Continuing持续运营cloud-provider-extraction-migration云厂商代码提取迁移项目。它是in-tree cloud provider 代码迁出 Kubernetes 主仓库这一历史工程的承载者。在 sigs.yaml 中该子项目的 OWNERS 覆盖apiserver-network-proxy、cloud-pv-admission-labeler、legacy-cloud-providers等仓库反映了它横跨 API Server 网络代理与遗留云厂商代码的广泛管辖范围。仓库中对应的目录见 sig-cloud-provider/cloud-provider-extraction-migrationkubernetes-cloud-providerSIG 的核心库子项目OWNERS 覆盖 k8s.io/cloud-provider 公共接口、CCM 命令行入口cmd/cloud-controller-manager、pkg/cloudprovider与pkg/controller/cloud等 Kubernetes 主仓库关键路径以及staging/src/k8s.io/cloud-provider独立模块见 sigs.yamlprovider-alibaba-cloud / provider-aws / provider-azure / provider-equinix-metal / provider-gcp / provider-huaweicloud / provider-ibmcloud / provider-oci / provider-openstack / provider-vsphere十个云厂商实现子项目。6.2 各云厂商子项目的 OWNERS 与会议配置在 sigs.yaml 中每个 provider 子项目都登记了 OWNERS 仓库列表与部分例会信息。这里列出各子项目的关键代码仓库供读者定位实现代码子项目主要代码仓库OWNERS 来源provider-alibaba-cloudcloud-provider-alibaba-cloud、alibaba-cloud-csi-driverprovider-awscloud-provider-aws、aws-ebs-csi-driver、aws-efs-csi-driver、aws-encryption-provider、aws-file-cache-csi-driver、aws-fsx-csi-driver、aws-fsx-openzfs-csi-driver、aws-iam-authenticator、aws-load-balancer-controller、provider-aws-test-infraprovider-azurecloud-provider-azure、azuredisk-csi-driver、azurefile-csi-driver、azurelustre-csi-driver、blobfuse-csi-driverprovider-gcpcloud-provider-gcp、gcp-compute-persistent-disk-csi-driver、gcp-filestore-csi-driverprovider-huaweicloudcloud-provider-huaweicloudprovider-ibmcloudcluster-api-provider-ibmcloud、ibm-powervs-block-csi-driver、ibm-vpc-block-csi-driver、provider-ibmcloud-test-infraprovider-ocicluster-api-provider-ociprovider-openstackcloud-provider-openstackprovider-vspherecloud-provider-vsphere、vsphere-csi-driver各子项目还维护着各自的例会节奏例如AWS 子项目例会为每两周一次太平洋时间周五 9:00Azure 为每月第三个周二GCP 为每两周一次vSphere 为每月第一个周三——详细配置见 sigs.yaml所有会议信息最终由 README.md 汇总呈现。6.3 kubernetes-cloud-provider所有实现的公共底座在 SIG 的架构中kubernetes-cloud-provider是其他所有 provider 子项目依赖的公共底座。其核心内容包括公共接口common interfaces定义在所有云厂商实现之上的一层抽象位于staging/src/k8s.io/cloud-provider保证各厂商以统一方式接入 Kubernetescloud-controller-manager作为 out-of-tree 组件运行负责启动云相关控制器节点、路由、负载均衡等核心控制器包括节点控制器node controller、路由控制器route controller即 KEP-5237 改造对象与服务控制器service controller等。这套公共接口 控制器 厂商实现的分层正是 SIG 实现云厂商中立性承诺的工程基础。七、Working GroupsNode Lifecycle 加入Structured Logging 持续年度报告还记录了 SIG 赞助的两个工作组的变动7.1 新增WG Node LifecycleNew in 2025的工作组是Node Lifecycle。根据 wg-node-lifecycle/README.md 的定义该工作组致力于探索和改进 Kubernetes 中的节点与 Pod 生命周期目标产出包括更好的节点 drain/维护支持更好的 Pod 干扰与终止disruption/termination处理节点与 Pod 的自动扩缩容改进更好的应用迁移与可用性、负载均衡、调度与反调度节点关机node shutdown以及云厂商与第三方集成。该工作组由 9 个 SIG 联合发起sigs.yaml 中列出 Apps、Autoscaling、CLI、Cloud Provider、Cluster Lifecycle、Network、Node、Scheduling、Storage每周一召开例会组织者来自 Red Hat、Anthropic 与 NVIDIA。云厂商的参与价值在于节点生命周期事件关机、维护、扩缩容最终都要转化为对云资源实例、路由、负载均衡的增删操作这正是 SIG Cloud Provider 的核心领域。7.2 持续WG Structured LoggingContinuing的工作组是Structured Logging其使命是现代化 Kubernetes 核心组件的日志让用户能高效地消费、处理、存储和分析日志信息。该工作组的 Stakeholder SIGs 同样包含 SIG Cloud Provider见 archive/wg-structured-logging/README.md因为 CCM 及各云厂商控制器作为核心组件其日志质量直接关系到多云环境下的可观测性。注意wg-structured-logging的文档目录当前位于仓库的archive/归档区archive/wg-structured-logging说明该工作组已完成或进入社区归档流程而wg-node-lifecycle位于仓库根级wg-node-lifecycle/目录并配有自己的 charter.md属于活跃状态。这种活跃目录 / archive 目录的划分本身就是判断工作组状态的直观信号。八、SIG 治理与运营健康度8.1 2025 年运营检查清单年度报告的 Operational 部分给出了 SIG 在 2025 年完成的五项治理任务全部勾选完成审阅并更新 README.md确保其准确性审阅并更新 CONTRIBUTING.md审阅并更新其他贡献文档如 devel 目录或贡献者指南审阅并更新 sigs.yaml 中的子项目列表及关联 OWNERS 文件核对 sigs.yaml 中 SIG 领导chairs、tech leads、subproject leads的准确性与活跃度并在需要时更新确保 2025 年的会议纪要与录像已链接到 README.md 并完成上传。这套检查清单对应着 committee-steering/governance/sig-governance.md 中对 SIG 的常规运营要求是社区保证各 SIG 文档与人员信息不过期的重要机制。8.2 领导层与治理特色根据 sigs.yaml 与 README.mdSIG 当前领导层为ChairsBridget KromhoutMicrosoft、Michael McCuneRed HatTechnical LeadsWalter FenderGoogle、Michael McCuneRed Hat、Joel SpeedRed HatEmeritus LeadsAndrew Sy Kim、Chris Hoge、Jago Macleod、Nick Turner。SIG 治理在 charter.md 中有两项显著特色值得关注同一公司最多一名 Chair——There should be no more than 1 chair from a single company从制度上防止决策偏向单一云厂商/公司这是云厂商中立使命在治理层面的直接落地Subproject Leads 被赋予额外职责——包括决定子项目发布节奏并产出版本、维护 issue 与 milestone 关联及 bug 分诊、及时处理活跃 PR、以及获得子项目仓库的管理员权限如 Azure 子项目负责人对cloud-provider-azure仓库拥有 admin 权限。结语通过年度报告与仓库配置文件的对照阅读可以清晰地看到 SIG Cloud Provider 在 2025 年完成的三个层面的演进技术层通过 KEP-5237 推动路由控制器从轮询走向 watch/informer 驱动的事件化调谐v1.35 Alpha生态层接纳 KRO 为官方子项目把业务边界从云厂商集成扩展到复杂自定义资源的声明式编排治理层完成 Equinix Metal 弃用公告、新增 WG Node Lifecycle 赞助、并通过运营检查清单保持了 README 与 sigs.yaml 中 12 个 subproject 和两套领导层信息的实时准确。对于希望在多云环境中落地 Kubernetes 的工程团队这份报告的价值在于它给出了判断哪个云厂商集成仍被官方维护、其测试与例会机制如何、核心控制器正在向什么方向演进的第一手权威索引。进一步深入时建议按此路径阅读仓库通读 sig-cloud-provider/README.md 获取 SIG 全貌与全部会议入口对照 sigs.yaml 查看各子项目的 OWNERS 与仓库归属阅读 sig-cloud-provider/charter.md 理解范围边界与治理规则结合 wg-node-lifecycle/README.md 与 archive/wg-structured-logging/README.md 跟踪跨 SIG 协作方向。【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考