Kubernetes Engine无法从非私有/GCR仓库拉取镜像导致部署失败求助

我之前也碰到过几乎一模一样的情况——原本能顺利部署到GKE，搭完Cloud Container Builder流水线后，不管用不用流水线都出现Pod拉取镜像失败的问题，明明镜像存在、本地CLI能拉，权限也给了。这种情况大概率是流水线搭建过程中意外修改了集群的核心配置，给你几个针对性的排查方向：

1. 检查Pod关联的服务账号权限 #

首先确认Pod使用的服务账号有没有镜像仓库的读取权限：

• 查看Pod的服务账号：

  kubectl describe pod <你的Pod名称> | grep "Service Account"
  

• 验证该服务账号是否拥有roles/storage.objectViewer权限（针对GCR/Artifact Registry）：

  gcloud projects get-iam-policy <你的项目ID> --filter="bindings.members:serviceAccount:<服务账号名称>@<项目ID>.iam.gserviceaccount.com"
  

  注意：Cloud Builder默认服务账号可能在流水线配置过程中，意外修改了项目IAM绑定，甚至覆盖了原有节点池服务账号的权限。

2. 验证镜像拉取密钥（ImagePullSecret）是否有效 #

本地CLI能拉取不代表集群内的Pod有权限，可能是集群内的拉取密钥过期或未正确关联：

• 检查Pod所在Namespace的拉取密钥：

  kubectl get secrets -n <你的Namespace>
  

  找类型为kubernetes.io/dockerconfigjson的密钥。
• 验证密钥内容是否正确：

  kubectl get secret <密钥名称> -o jsonpath='{.data.\.dockerconfigjson}' | base64 -d
  

  确认指向的镜像仓库地址正确，且密钥内的token未过期。
• 如果没有有效密钥，重新创建并关联到Deployment：

  kubectl create secret docker-registry gcr-json-key \
    --docker-server=gcr.io \
    --docker-username=_json_key \
    --docker-password="$(cat 你的服务账号密钥文件.json)" \
    --docker-email=any@example.com
  

  然后在Deployment的spec.template.spec中添加：

  imagePullSecrets:
    - name: gcr-json-key
  

3. 核对镜像地址和标签是否完全一致 #

流水线构建时可能误将镜像推送到不同区域的仓库，或打错标签，导致Deployment里的镜像地址和你CLI拉取的不一致：

• 查看Deployment中的镜像地址：

  kubectl get deployment <你的Deployment名称> -o jsonpath='{.spec.template.spec.containers[0].image}'
  

  和你本地拉取的镜像地址完全对比，包括仓库域名（比如gcr.io vs us.gcr.io vs europe-west1-docker.pkg.dev）和标签。

4. 检查节点池服务账号权限 #

GKE节点默认使用节点池绑定的服务账号，如果这个账号的权限被流水线配置改动，所有Pod都会受影响：

• 查看节点池的服务账号：

  gcloud container node-pools describe <节点池名称> --cluster <集群名称> --zone <集群区域> | grep serviceAccount
  

• 确认该账号拥有roles/container.nodeServiceAgent和roles/storage.objectViewer权限，缺失的话补充：

  gcloud projects add-iam-policy-binding <你的项目ID> \
    --member=serviceAccount:<节点池服务账号>@<项目ID>.iam.gserviceaccount.com \
    --role=roles/storage.objectViewer
  

5. 排查网络通信问题 #

流水线搭建时可能配置了VPC网络政策，阻止了节点与镜像仓库的通信：

• 在节点上测试与GCR的连通性：

  curl https://gcr.io/v2/
  

  如果返回{"errors":[{"code":"UNAUTHORIZED","message":"Anonymous users does not have permission to read repository"}]}，说明网络正常，是权限问题；如果无法连接，需要检查VPC防火墙规则或网络政策。

我当时的问题是流水线部署时不小心替换了节点池的服务账号，导致原有权限丢失，重新给节点服务账号添加roles/storage.objectViewer后就解决了。你按这个顺序排查，应该能快速定位问题。

内容的提问来源于stack exchange，提问作者Thijs Koerselman