Kubernetes Ingress-Nginx 镜像仓库迁移：从 GCR 到 AR 的技术实践

在 Kubernetes 生态系统中，容器镜像的存储和分发是基础设施中至关重要的一环。近期，Google Container Registry（GCR）服务即将在2025年3月正式停止服务，这促使 Kubernetes Ingress-Nginx 项目团队完成了从 GCR 到 Artifact Registry（AR）的镜像仓库迁移工作。

背景与挑战

Google Cloud 宣布其容器注册表服务 GCR 将被更现代的 Artifact Registry 服务取代。这一变化影响了 Kubernetes 生态系统中许多项目的镜像存储方式，包括 Ingress-Nginx 这样的核心组件。

迁移工作面临几个关键挑战：

1. 需要确保现有的 CI/CD 流程不受影响
2. 保持镜像的可靠性和可用性
3. 确保下游用户能够无缝过渡
4. 更新所有相关文档和配置

技术实现细节

Ingress-Nginx 团队采取了分阶段迁移策略：

1. 镜像推送配置更新

团队首先修改了 test-infra 仓库中的镜像推送配置，将目标仓库从 gcr.io/k8s-staging-ingress-nginx 更新为 us-central1-docker.pkg.dev/k8s-staging-images/ingress-nginx。这一变更确保了新构建的镜像会被推送到正确的 AR 仓库。

2. 构建系统适配

在项目本体的 cloudbuild.yaml 配置文件中，团队更新了所有与 GCR 相关的引用，替换为对应的 AR 端点。这一变更涉及多个发布分支，需要确保每个活跃的发布分支都得到更新。

3. 镜像推广机制调整

团队更新了 k8s.io 仓库中的镜像推广配置，确保推广流程能够从新的 AR 仓库正确拉取镜像并推送到 registry.k8s.io。值得注意的是，registry.k8s.io 本身已经基于 AR 构建，因此这部分变更主要涉及中间环节的调整。

4. 文档同步更新

所有相关文档中的示例和说明都被更新，以反映新的镜像仓库位置。这包括开发文档、部署指南和贡献指南等。

迁移效果验证

团队通过完整的 CI/CD 流程验证了迁移效果：

• 新镜像能够成功构建并推送到 AR 仓库
• 镜像推广流程能够正常工作
• 最终用户通过 registry.k8s.io 获取的镜像不受影响
• 所有自动化测试通过

对用户的影响

对于大多数终端用户来说，这次迁移是完全透明的。因为 registry.k8s.io 作为最终镜像分发点没有变化，用户仍然可以通过相同的地址获取 Ingress-Nginx 镜像。只有直接使用 staging 镜像的开发者和贡献者需要注意新的仓库地址。

经验总结

这次迁移工作展示了 Kubernetes 生态系统应对基础设施变更的成熟流程：

1. 提前规划迁移时间表
2. 分阶段实施变更
3. 全面验证每个环节
4. 确保变更的向后兼容性
5. 及时更新文档

对于其他面临类似迁移的项目，Ingress-Nginx 的经验表明，通过系统性的规划和执行，这类基础设施变更可以做到对终端用户无感知，同时保证系统的长期可维护性。