Kubeflow Pipelines 容器镜像构建与存储架构演进

在 Kubeflow Pipelines 项目的持续演进过程中，技术团队正在推动一项重要的基础设施改造：将现有的 Google Container Registry（GCR）和 Cloud Build 构建系统迁移到更加开放和中立的平台。这一变革源于项目作为 CNCF 托管项目的定位，需要降低对单一云厂商的依赖。

当前架构中，Kubeflow Pipelines 的容器镜像构建和存储主要依赖 Google 云平台的两项服务：

1. Cloud Build 作为核心构建机制
2. Google Container Registry 作为镜像存储仓库

这种架构存在两个潜在风险点：

• 构建流程与特定云平台深度耦合
• 镜像存储存在潜在的访问限制风险

技术团队评估了 GitHub 生态的替代方案，认为 GitHub Actions 配合 GitHub Container Registry（GHCR）能够提供更优解：

• GitHub Actions 提供跨平台的构建能力，支持多种运行环境
• GHCR 作为镜像仓库，对开源项目提供慷慨的存储配额和拉取速率限制
• 与代码仓库的无缝集成，利用 GITHUB_TOKEN 实现自动认证

迁移方案的技术优势体现在：

1. 构建流程标准化：通过 GitHub Actions 的声明式工作流定义，实现可复用的构建管道
2. 权限管理简化：利用 GitHub 的内置安全机制，避免额外的凭证管理
3. 成本优化：GHCR 对公开仓库免费，且提供更高的请求配额

值得注意的是，整个 Kubeflow 生态系统的镜像存储策略仍在讨论中。当前阶段，Pipelines 组件采用 GHCR 作为过渡方案，既满足了项目独立性需求，也为未来可能的统一存储方案预留了调整空间。这种渐进式架构演进方式，体现了云原生项目的基础设施选型原则：在保证当前可用性的同时，为未来的标准化留出接口。

对于终端用户而言，这一变更将带来更稳定的镜像获取体验。开发者则能获得更透明的构建过程和更灵活的定制能力，这些都是开源项目健康发展的重要基础。