企业官网建设流程全解析

Kubernetes SIG K8s Infra 2024 年度报告解读：Azure 集成、Prow 迁移与镜像仓库去 Google 化之路

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

SIG K8s Infra（Kubernetes 基础设施特别兴趣小组）负责将 Kubernetes 项目全部基础设施的归属与管理权从 google.com GCP 组织（或其他厂商）迁移到 CNCF，目标是让项目能够不依赖任何外部厂商即可自主持续运营。本文以仓库中 sig-k8s-infra/annual-report-2024.md 为骨架，结合 SIG 宪章、SIG 主页 与根目录 sigs.yaml 中的权威元数据，系统解读该 SIG 在 2024 年的核心工作、待支援领域、子项目全景与治理运营状态，帮助读者理解 Kubernetes 社区基础设施"去厂商锁定"的整体演进路径。

一、SIG K8s Infra 的使命与治理范围

在进入 2024 年度工作盘点之前，有必要先明确该 SIG 的定位。根据 charter.md 的定义，SIG K8s Infra 的核心使命是：

将 Kubernetes 项目全部基础设施的归属与管理从 google.com GCP 组织（或其他 IaaS 厂商托管位置）迁移到 CNCF，使 Kubernetes 项目能够在没有外部厂商或实体直接协助的情况下可持续地自主运营。

宪章中还有一句广为流传的"口号式"表述：消除"哦，那是 Vendor X 员工才能做的事，我们只能等他们响应"这句话的存在空间。也就是说，基础设施必须由社区自己掌握代码、数据与策略，而不是被任何单一云厂商绑架。

宪章明确的职责范围（In scope）涵盖：

• 策略定义与执行：界定项目基础设施的范围内/范围外、谁能访问哪部分基础设施（团队定义与审查标准）、基础设施应如何管理（命名规范、可接受工具、on-call 与升级策略）等；
• 配置管理：kubernetes.io GCP 组织内所有资源与服务使用，包括 API/服务启用、BigQuery 数据集、DNS 记录（k8s.io、kubernetes.io 等域名）、GCB、GCP 项目/实例/镜像、GCR 仓库、GCS 桶、GKE 集群（社区基础设施集群、prow 构建集群）、GSM 密钥、Google Groups、IAM 角色/服务账号/策略、KMS 密钥、托管证书等；
• 运营报告：匿名流量报告、基础设施当前配置审计报告、预算支出账单报告。

值得注意的是，宪章也划定了 Out of scope：SIG 不负责运行在基础设施之上的应用代码（除非属于本 SIG 子项目），不负责 GitHub 等非 IaaS 服务的问题（应路由给 SIG Contributor Experience），也不负责尚未迁移到 CNCF 的基础设施。

二、2024 年三大核心工作

年度报告第一部分"Current initiatives and Project Health"明确列出了 2024 年最值得关注的成果，共三项，全部围绕"去厂商依赖"这一主轴展开。

2.1 与 Microsoft Azure 的集成

2024 年 SIG K8s Infra 引入了与 Microsoft Azure 的集成。结合 2025 年报告（annual-report-2025.md）可以看到，这一多云化战略在 2025 年延续为 IBM Cloud、Datadog 的集成，方向是一致的：让 Kubernetes 项目基础设施从单一 GCP 依赖走向多厂商、多区域、可互相备份的格局。从 sigs.yaml 中可以看到，2024 年期间领导层也发生了相应调整——Chairs 中加入来自 Microsoft 的 Ciprian Hacman（@hakman），这正是云厂商合作加深在治理层面的体现。

2.2 prow.k8s.io 迁移到社区基础设施

prow.k8s.io 是 Kubernetes 项目 CI/CD 系统 Prow 的前端入口。报告明确指出 2024 年完成了prow.k8s.io 向社区基础设施的迁移。这里需要理解宪章中的一个关键设定：prow 构建集群等 GKE 集群属于 SIG K8s Infra 负责的配置管理范围，而 Prow 本身的代码与运维历史上归属 SIG Testing；宪章中"我们不是运行在基础设施之上的代码的责任方"的例外条款，正是为了处理这种跨 SIG 协作。迁移意味着该站点从原先依赖厂商托管的部署位置，正式落到社区自有的 GKE 集群（community infra cluster、prow build clusters）之上，从而减少对外部厂商的响应依赖。

2.3 从 Google GCR 到 Google Artifact Registry 的迁移需求梳理

2024 年 SIG 完成了从 Google Container Registry（GCR）迁移到 Google Artifact Registry（GAR）的需求梳理（Requirements）。这是仓库基础设施演进的重要铺垫：GAR 提供更强的制品管理与生命周期能力。结合宪章中"GCR repositories"属于配置管理范围可知，制品仓库的迁移是 SIG 的日常核心事务之一。该迁移需求在 2025 年报告中进一步落实为"Migration from GCR to Artifact registry"的执行项，因此 2024 年的需求梳理是后续落地的前提。

2.4 关于 KEP 工作

报告第四项明确标注 2024 年（v1.30、v1.31、v1.32 三个版本周期）的 KEP 工作为NONE。这并不代表 SIG 无所作为——基础设施类工作大多不通过 KEP（Kubernetes Enhancement Proposal）跟踪，而是直接以 k8s.io 仓库中的议题、PR 和跨 SIG 协作推进。报告模板中的注释也说明，KEP 列表是从 kubernetes/enhancements 仓库的元数据自动生成的，若发现差异需先核对 KEP 元数据。

三、需要帮助的领域：安全、资源与可观测性

报告第二部分坦诚列出了三个需要社区支援的方向，对理解该 SIG 的当前短板很有价值：

其中资源消耗优化是长期议题：社区基础设施由多家厂商捐赠预算支撑（详见宪章 "Project Infrastructure Budget" 条款），因此资源利用率直接关系到项目可持续性。宪章明确 SIG 有权在出现意外或过度支出时删除或缩减基础设施，这使得资源优化不仅是效率问题，更是治理红线。这三个议题均可通过 k8s.io 仓库的 issue 跟踪器参与。

四、社区范围内的公开更新

2024 年 SIG 在社区层面进行了两场公开分享（报告第三部分）：

1. Kubernetes Infra SIG: Intro and Updates——介绍 SIG 当前工作与状态更新；
2. Intro & Deep Dive Kubernetes Infrastructure——基础设施深入剖析。

这类 KubeCon/社区演讲是社区了解基础设施进展的主要窗口。需要说明的是，报告模板将此类更新限定为"例如 KubeCon 演讲"等公开内容，其记录载体包括邮件列表、幻灯片与录像，可通过 SIG 会议纪要归档（README.md 中列出的 go.k8s.io/sig-k8s-infra-notes）持续跟进。

五、子项目与工作组全景（2024 年状态）

报告列出了 6 个继续运行（Continuing）的子项目与 1 个工作组。与 2023 年报告（annual-report-2023.md）对照可知：community-images 于 2023 年新增，2024 年全部 6 个子项目保持稳定，无新增也无退役。以下是各子项目的职责与治理信息（数据来源：根目录 sigs.yaml 与 README.md）：

两个重定向器（porche 与 registry.k8s.io）是"多云制品分发"架构的关键：它们本身不存储制品，而是按需将请求重定向到多个后端存储/镜像仓库。这正是 SIG 使命的技术落点——即便底层厂商存储可以多元化，社区仍能通过统一入口（dl.k8s.io 的二进制分发与 registry.k8s.io 的镜像分发）保持对用户一致的体验。

工作组方面，2024 年继续运行的为LTS工作组（与根目录 wg-lts/README.md 对应），该组在 2023 年作为工作组新增，2024 年延续。

治理信息同样记录在 sigs.yaml 中：SIG 的 GitHub 团队包括sig-k8s-infra（活跃贡献者）与sig-k8s-infra-leads（chairs 与 tech leads），Steering Committee 联络人为 Rita Zhang。需要提醒的是，README.md 文件头部声明其为自动生成文件——内容由根目录 sigs.yaml 经 generator 生成，因此若要更新子项目或领导层信息，正确做法是修改 sigs.yaml 而非直接编辑 README。

六、年度运营检查清单（Operational Checklist）

报告末尾是依据 committee-steering/governance/sig-governance.md 执行的年度运营自检清单，反映了 SIG 在治理文书维护上的完成度：

这份清单的治理依据是 sig-governance.md 中规定的 SIG 年度运营义务，其中 README、sigs.yaml 与领导层信息的核对属于重点项，而贡献文档与会议纪要在 2024 年仍有待补齐。这种"透明暴露未完成项"的做法，本身也是 Kubernetes 社区治理文化的一部分——年度报告既是对外成绩单，也是对内的待办清单。

七、从 2023 到 2025：SIG 演进脉络

将三年报告串联，可以看到 SIG K8s Infra 的清晰演进轨迹：

• 2023 年（annual-report-2023.md）：新增 community-images 子项目与 LTS 工作组，报告主体多为占位注释，属于"蓄力期"；
• 2024 年（本报告）：交出三项硬成果——Azure 集成、prow.k8s.io 迁移、GCR→GAR 迁移需求梳理，并坦诚列出安全、资源、可观测性三块短板；
• 2025 年（annual-report-2025.md）：在 2024 年基础上继续扩展——IBM Cloud 集成、GCR 到 Artifact Registry 的实际迁移、kOps 与 CAPV 的 CI 迁移到社区基础设施、Datadog 集成，同时完成领导层交接（@hakman、@GenPage 成为新 Co-Chair，@BenTheElder、@dims 转入 emeritus）。

从这条脉络可以得出一个结论：2024 年是 SIG K8s Infra 从"准备"转向"大规模落地"的转折年。2025 年报告中出现的多云扩展与制品仓库迁移，其需求基础正是 2024 年完成的工作；而 2025 年新暴露的"registry 维护"与"AWS 基础设施维护"需求，也与 2024 年点名的"需要帮助"领域一脉相承。

结语

通过这份年度报告，读者可以完整看到 Kubernetes 项目基础设施治理的全貌：一个以"消除厂商依赖"为使命的 SIG，如何通过多云集成、CI 入口迁移、制品仓库换代三项工程，加上一套以 sigs.yaml 为单一事实来源、以 charter.md 为边界约束的治理体系，稳步把社区基础设施掌握在自己手中。对于希望参与 Kubernetes 基础设施工作的开发者，建议从三个入口切入：一是阅读 README.md 了解子项目分工并加入会议；二是对照 sigs.yaml 找到感兴趣的 OWNERS 文件开始贡献；三是关注报告点名的安全、资源优化与可观测性三个待支援方向——这些正是社区最需要人手的地方。

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