企业官网建设流程全解析

SIG Cloud Provider 2024 年度报告解读：in-tree 云提供商移除完成与模块化 CCM 测试体系建设

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

导读：本文以 Kubernetes Community 仓库中的 sig-cloud-provider/annual-report-2024.md 年度报告为主体，结合 SIG Charter、SIG README 与 sigs.yaml 等仓库文件，系统解读 SIG Cloud Provider 在 2024 年的关键里程碑：KEP-2395「移除 in-tree 云提供商」在 v1.31 达到 Stable、模块化 Cloud Controller Manager（CCM）测试草案启动、两个子项目正式退休，以及 Kubernetes 历史上最大规模迁移的最终落地。读完本文，你将完整掌握该 SIG 的职责边界、子项目版图、2024 年度技术演进脉络，以及外部云提供商（out-of-tree）迁移的社区工作全貌。

一、背景：SIG Cloud Provider 的使命与治理框架

SIG Cloud Provider（云提供商特别兴趣小组）在 charter.md 中明确定义了其使命：将云提供商集成简化为 Kubernetes 集群的扩展（extensions/add-ons）来开发与维护，并确保 Kubernetes 生态对所有（公有与私有）云提供商保持中立。

从 README.md 的官方表述可以看到，该 SIG 的核心职责包括：

• 建立所有云提供商必须满足的标准与要求，确保与 Kubernetes 的最优集成；
• 负责未被更专门的 SIG（如存储、网络）覆盖的云提供商集成与扩展点；
• 提供高效供给/回收云资源（节点、路由、负载均衡器等）的 API 与接口；
• 配置集群组件以启用云提供商集成；
• 建设测试体系与测试框架，保证跨云提供商的厂商中立性。

在治理层面，charter.md 还做出了若干对供应商中立的硬性约束，例如来自同一公司的 Chair 不得超过 1 人，以避免决策偏向单一云厂商；同时授权各子项目负责人承担发布节奏、backlog 梳理、PR 时效与仓库管理权限等额外职责。

二、2024 年最大的里程碑：KEP-2395 在 v1.31 达到 Stable

2024 年度报告中最重要的技术事件，是KEP-2395：Removing In-Tree Cloud Providers（移除 in-tree 云提供商）在 v1.31 达到 Stable 状态。

2.1 该 KEP 的历史脉络

要理解 2024 年的 Stable 意味着什么，需要回溯此前的进展。根据 sig-cloud-provider/annual-report-2023.md 的记录：

• 2023 年，SIG 将 KEP-2395 更新到 Beta（对应 v1.29），并改变了 Kubernetes 的默认行为——默认使用外部云控制器（external cloud controllers）。当时这一更新被认为是 SIG 在 2023 年完成的最大任务，涉及 CI 与测试基础设施的多项关键变更，需要整个 Kubernetes 社区协作推进；
• 2024 年，该 KEP 进一步推进至Stable（v1.31），标志着移除 in-tree 云提供商的正式完成。

2.2 Stable 的意义：最大规模迁移的收官

年度报告引用的社区博客标题将其概括为「Completing the largest migration in Kubernetes history」（完成 Kubernetes 历史上最大规模的迁移）。从实现角度理解，这一迁移的实质是：

• 代码迁移：将原本内嵌在kube-controller-manager中的各云厂商集成逻辑（节点、节点生命周期、路由、服务四大控制器）从 Kubernetes 主仓库中剥离；
• 组件迁移：云相关控制逻辑由独立的 cloud-controller-manager（隶属于 kubernetes-cloud-provider 子项目）承担，各厂商以 out-of-tree 方式维护自己的cloud-provider-*仓库；
• 行为默认化：自 v1.29 起集群默认采用外部云控制器，最终在 v1.31 将该流程正式定为 Stable。

仓库中的 sigs.yaml 对kubernetes-cloud-provider子项目的 OWNERS 归属记录也印证了这一架构——该子项目横跨kubernetes/cloud-provider、主仓库中的cmd/cloud-controller-manager、pkg/cloudprovider、pkg/controller/cloud以及 staging 下的k8s.io/cloud-provider等多个代码区域，是外部云提供商体系的公共底座。

三、2024 年新启动的工作：模块化 CCM 测试草案

在 KEP-2395 进入 Stable 的同时，SIG 将注意力转向了测试体系的升级。2024 年度报告明确指出，SIG 启动了「Modular Cloud Controller Manager Testing」（模块化 CCM 测试）的草案 enhancement。

这一方向与 SIG 的使命一脉相承——charter 中「Testing and testing frameworks to ensure vendor neutrality across all cloud providers」正是四大关注领域之一。结合 sig-cloud-provider/annual-report-2022.md 的记录，SIG 早在 2022 年就开始由 Michael McCune 开展 e2e 测试重构的实验性工作，目标是构建一套通用的、可被所有云厂商复用的 CCM 测试集，以替代当时仅覆盖少数厂商的零散测试。2024 年的模块化草案可以视为这一方向的正式化延续，其核心诉求是：让每个外部云提供商都能用统一、可组合的测试模块来验证自家 CCM 实现的正确性，从而保证「移除 in-tree 云提供商」之后，各厂商的 out-of-tree 实现质量不出现滑坡。

需要说明的是，该草案目前仍处于早期起草阶段，具体技术细节以 enhancement 提案的后续演进为准；但「先完成迁移、再夯实测试」的节奏，清晰反映了 SIG 2024 年的工作优先级。

四、2024 年社区传播：KubeCon 演讲与官方博客

年度报告记录了 SIG 在 2024 年面向整个 Kubernetes 社区的传播活动，主要包括两场 KubeCon 演讲与两篇官方博客：

4.1 KubeCon 演讲

• KubeCon Paris：题为《Kubernetes Is FINALLY Removing in-Tree Cloud Providers》的演讲，由 Bridget Kromhout 与 Chris Privitere 主讲，面向社区解释 in-tree 云提供商移除的来龙去脉与迁移路径；
• KubeCon Salt Lake City：题为《Building a More Resilient Future with Advanced Cloud Provider Testing》的演讲，由 Michael McCune 与 Bridget Kromhout 主讲，呼应了前文提到的模块化 CCM 测试工作，强调通过更先进的测试手段提升云提供商生态的韧性。

4.2 Kubernetes 官方博客

• 《Spotlight on SIG Cloud Provider》：介绍 SIG 的角色定位、日常工作与参与方式；
• 《Completing the largest migration in Kubernetes history》：宣布历史上最大规模云提供商迁移的正式完成。

这些社区活动表明，2024 年 SIG 的工作重心已从「迁移实施」转向「迁移收尾与生态质量保障」，并通过 KubeCon 与官方博客向用户和厂商同步进展、给出行动指引。

五、子项目版图：2024 年的退休与继续运营

5.1 2024 年退休的子项目

年度报告显示，2024 年有两个子项目正式退休：

• provider-baiducloud（百度云）：结合 sig-cloud-provider/annual-report-2023.md 的记录，其对应仓库自 2021 年 4 月起便无更新，2023 年 SIG 即已明确将审查其状态与归属、考虑移除；2024 年该子项目正式从活跃名单中退出；
• cloud-provider-sample（示例云提供商）：作为参考实现性质的样例项目，在 in-tree 移除完成、外部实现模式成熟后完成了其历史使命，正式退休。

5.2 继续运营的 13 个子项目

年度报告列出的继续运营子项目包括：

这些子项目的详细信息（OWNERS 归属、例会时间等）统一维护在 sigs.yaml 中，并由仓库根部的生成器产出到 README.md。例如 cloud-provider-extraction-migration 的 OWNERS 文件 记录了该子项目的 reviewers（andrewsykim、cheftako、nckturner）与 approvers，以及sig/cloud-provider标签，是了解子项目治理的直接入口。

从 sigs.yaml 可以看到各厂商子项目的 OWNERS 链接分散在kubernetes/cloud-provider-*与kubernetes-sigs/*-csi-driver等仓库中，且多数子项目配有独立例会（如 AWS 每两周一次、Azure 每月第三个周二、OpenStack 每两周一次等），反映出「以厂商为单元、各自自治」的联邦式治理结构。

六、Working Group：Structured Logging 继续运营

2024 年，SIG Cloud Provider 持续赞助Structured Logging（结构化日志）工作组的运营。结构化日志是 Kubernetes 可观测性改造的重要组成部分，其目标是将各组件日志从非结构化的自由文本逐步迁移为键值对形式的结构化输出，从而支持统一的日志采集、解析与告警。

结合仓库中的治理文档 committee-steering/governance/sig-governance.md 对工作组（WG）的定义，SIG 赞助的 WG 用于处理跨 SIG 边界的横切议题，Structured Logging 正是这类「既影响云提供商组件、又辐射整个 Kubernetes 代码库」的横切工作，因此在年度报告中以「Continuing」状态持续跟进。

七、治理运营：2024 年 Operational 检查清单

年度报告的 Operational 部分完整记录了 SIG 按照 committee-steering/governance/sig-governance.md 要求执行的年度治理任务，2024 年全部勾选完成：

• 复核并更新 sig-cloud-provider/README.md 的准确性；
• 复核并更新 sig-cloud-provider/CONTRIBUTING.md；
• 复核其他贡献文档（如 devel 目录或贡献者指南）；
• 复核 sigs.yaml 中的子项目列表及关联 OWNERS 文件；
• 确认 sigs.yaml 中的 SIG 负责人（chairs、tech leads、subproject leads）准确且活跃；
• 确认 2024 年会议纪要与录制已链接至 README.md 并及时更新。

这一清单体现了 Kubernetes SIG 自治模式的关键实践：每年通过「文档复核 + 人员活跃度审查 + 元数据对齐」来防止治理僵化。其中「SIG leaders 活跃度确认」与 2024 年子项目退休动作（provider-baiducloud、cloud-provider-sample）之间存在直接关联——正是通过这类年度审查，SIG 才能及时识别并清理长期无活跃维护者的子项目。

从仓库根目录的 OWNERS_ALIASES 与 sigs.yaml 的 leadership 字段可以看到，2024 年 SIG 的领导层为：Chairs——Bridget Kromhout（Microsoft）、Michael McCune（Red Hat）；Tech Leads——Walter Fender（Google）、Michael McCune、Joel Speed（Red Hat）；Steering Committee Liaison 为 Maciej Szulik。charter 中「同一公司 Chair 不超过 1 人」的约束在此得到体现（两位 Chair 分属 Microsoft 与 Red Hat）。

八、如何了解与参与 SIG Cloud Provider

如果你希望跟进或参与该 SIG 的工作，仓库提供了完整的入口：

• 社区联系：#sig-cloud-providerSlack 频道、邮件列表，以及每两周一次（周三 9:00 PT）的常规 SIG 会议，会议纪要与录制的归档链接均维护在 sig-cloud-provider/README.md 的 Meetings 小节；
• GitHub 团队分工：README.md 的 Contact 小节按职责拆分了 8 个 GitHub 团队，包括sig-cloud-provider-api-reviews（API 变更评审）、sig-cloud-provider-bugs（Bug 分类排查）、sig-cloud-provider-feature-requests（功能请求）、sig-cloud-provider-pr-reviews（PR 评审）、sig-cloud-provider-test-failures（测试失败分类）等，可按你的兴趣直接对号入座；
• 贡献指南：sig-cloud-provider/CONTRIBUTING.md 提供了从认领 issue（按size/S到size/XL预估工作量）、每周更新状态，到通过@kubernetes/sig-cloud-provider-*团队升级受阻 issue/PR/KEP 的完整流程；由于 out-of-tree 云提供商代码具有强厂商属性，该指南建议新贡献者优先选择自己最关注的云厂商子项目，与既有维护者结对或在 bugfix 上合作；
• 总体贡献规则：所有贡献需遵循 CONTRIBUTING.md（仓库根）与 community-membership.md 中定义的贡献者梯队（Contributor → Member → Reviewer → Approver）。

九、总结：2024 年 SIG Cloud Provider 的关键词

回顾 sig-cloud-provider/annual-report-2024.md 的全文，SIG Cloud Provider 在 2024 年的演进可以概括为三个关键词：

1. 收官：KEP-2395 于 v1.31 达到 Stable，「移除 in-tree 云提供商」这一横跨多年的最大规模迁移正式完成；
2. 加固：在迁移完成的同时，启动模块化 CCM 测试草案，并借助 KubeCon 与官方博客向社区推广先进的云提供商测试方法论，确保 out-of-tree 生态的质量下限；
3. 瘦身：基于年度治理审查，正式退休 provider-baiducloud 与 cloud-provider-sample 两个子项目，让 13 个继续运营的子项目与 Structured Logging 工作组聚焦于持续演进。

对于 Kubernetes 用户与云厂商开发者而言，这份年度报告传递的核心信号是：外部云控制器已成为 Kubernetes 的默认且唯一形态，接下来衡量各云提供商实现优劣的标尺，将从「能否运行」转向「测试是否完备、可观测性是否达标」——而这正是模块化 CCM 测试与结构化日志工作组在 2024 年持续推进的方向。

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