Azure K8s Pod中从ACR拉取大Docker镜像中途失败求助

问题场景 #

在Azure Kubernetes集群的Pod内，使用具备私有ACR拉取权限的服务主体完成docker login后，拉取小镜像（如hello-world）一切正常，但拉取1.24GB的大镜像xxx.azurecr.io/infrastructure-github-actions-image:latest时，下载部分层后突然触发pull access denied错误。本地可正常拉取该大镜像，且Pod内拉取Docker Hub的大镜像（如7.3GB的cimg/android）也无异常。

排查调试建议 #

1. 验证服务主体登录令牌的有效期 #

服务主体的登录令牌可能存在较短的过期时间，小镜像拉取速度快，令牌未过期；大镜像拉取耗时久，中途令牌失效导致权限校验失败。

• 重新登录ACR后立即拉取大镜像，验证是否能成功
• 解码Docker配置文件中的令牌查看有效期：

  # 查看auth信息并解码
  cat ~/.docker/config.json | jq '.auths["xxx.azurecr.io"].auth' | tr -d '"' | base64 -d
  

2. 排查网络超时导致的会话中断 #

大镜像拉取耗时较长，Pod与ACR之间的网络连接可能因超时重置，导致ACR重新校验权限时失败。

• 检查Pod所在K8s节点的网络监控（如丢包率、延迟指标），确认网络稳定性
• 修改Docker daemon的超时配置，在/etc/docker/daemon.json中添加：

  {
    "timeout": 300,
    "max-concurrent-downloads": 2
  }
  

  执行systemctl restart docker后重试拉取
• 尝试添加--disable-content-trust参数减少拉取时的校验环节：

  docker pull --disable-content-trust xxx.azurecr.io/infrastructure-github-actions-image:latest
  

3. 确认ACR仓库的权限细节 #

确保服务主体对目标镜像所在的仓库拥有明确的acrpull权限，避免ACR级别的权限在仓库层出现继承问题：

• 在Azure门户中检查该服务主体对infrastructure-github-actions-image仓库的权限分配
• 使用Azure CLI验证权限：

  az acr repository show-permissions --name xxx --repository infrastructure-github-actions-image --assignee <服务主体客户端ID>
  

4. 检查镜像层的权限与完整性 #

大镜像的部分层可能存在权限异常或损坏：

• 在本地重新推送该大镜像到ACR，确保所有层上传完整
• 尝试单独拉取失败时正在下载的层，定位是否为特定层的问题：

  docker pull xxx.azurecr.io/infrastructure-github-actions-image@sha256:<失败层的哈希值>
  

5. 确认拉取过程中Docker登录状态是否保持 #

拉取大镜像过程中，Docker的登录状态可能意外失效，可在拉取前和失败后分别验证：

# 检查登录状态
docker info | grep -A5 "Registry"
# 或拉取小镜像验证权限是否有效
docker pull xxx.azurecr.io/hello-world

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