如何通过Cloud Build部署Kubeflow组件？镜像推送失败求优化方案

错误原因 #

你的第二步骤通过挂载Cloud Build宿主的/var/run/docker.sock，让dcgp容器内的kfp component build调用宿主Docker daemon构建了镜像，但第三步骤的docker push运行在独立的cloud-builders/docker容器中——该容器默认未挂载宿主的Docker sock，因此无法访问宿主上已构建的镜像，导致推送失败。

简化部署方案（推荐） #

无需自行构建自定义Docker镜像，直接使用官方KFP CLI镜像完成组件构建与推送，Cloud Build配置大幅简化：

steps:
  # 直接用官方KFP CLI构建并推送组件镜像
  - name: 'gcr.io/kubeflow-images-public/kfp-cli:1.8.20'  # 根据你的KFP版本替换
    args:
      - 'component'
      - 'build'
      - 'stages/simple'
      - '--push-image'
      - '--component-filepattern=*.py'  # 组件为Python文件时指定，可省略（默认自动识别）
    volumes:
      - name: 'docker-sock'
        path: '/var/run/docker.sock'
    id: 'build-push-component'

# 配置选项：确保Cloud Build有推送权限
options:
  logging: CLOUD_LOGGING_ONLY

核心优势 #

• 省去自定义镜像构建：直接使用官方维护的KFP CLI镜像，避免环境不一致问题。
• 一步完成构建推送：通过--push-image参数，让kfp component build直接完成镜像推送，无需单独的push步骤。
• 权限与环境兼容：挂载docker-sock卷，让KFP CLI能调用Cloud Build宿主的Docker daemon执行操作，确保镜像能被正确推送。

注意：需确保Cloud Build服务账号拥有Artifact Registry Writer角色权限，允许其向目标镜像仓库推送镜像。

原有配置修正方案（若需保留自定义镜像） #

如果必须使用你自己的dcgp镜像，只需给第三步骤添加Docker sock挂载，让它能访问宿主上已构建的镜像：

steps:
  - name: gcr.io/cloud-builders/docker
    args: [ 'build', '-t', 'dcgp', '-f', 'cloudbuild/DockerfileDeploy', '.', '--network=cloudbuild']
    id: 'dcgp-build'
  - name: gcr.io/cloud-builders/docker
    args: [ 'run', '--network=cloudbuild', '-v', '/var/run/docker.sock:/var/run/docker.sock',
    'dcgp', 'kfp', 'component', 'build', 'stages/simple', '--no-push-image' ]
    id: 'stages-build'
  - name: gcr.io/cloud-builders/docker
    args: [ 'push', 'europe-west2-docker.pkg.dev/my-project/stages/simple:latest' ]
    waitFor: ['stages-build']
    id: 'stages-deploy'
    volumes:
      - name: 'docker-sock'
        path: '/var/run/docker.sock'

内容的提问来源于stack exchange，提问作者Alexander Townsend