Github Workflow部署AKS时ACR镜像拉取认证失败问题

• 配置了GitHub Workflow流水线，用于构建镜像并部署到Azure Kubernetes Cluster（AKS）
• 流水线整体显示构建和部署成功，但展开部署任务的「Deploys application」子任务时，出现ACR镜像拉取认证失败错误
• 浏览器通过负载均衡IP访问应用时显示连接超时
• Django应用本地运行正常，本地构建镜像部署到AKS后可正常访问；仅将代码推送到GitHub启用自动部署时出现上述问题
• 附相关文件：Dockerfile、Kubernetes清单restauapp.yaml、Workflow文件newapp-workflow.yaml，以及项目结构、集群和容器注册表角色分配截图

1. 确认ACR与AKS的权限关联 #

AKS拉取ACR镜像的权限配置是核心问题：

• 若使用AKS托管身份，执行以下命令确保集群已关联ACR并拥有AcrPull权限：

  az aks update -n <你的AKS集群名> -g <资源组名> --attach-acr <你的ACR名称>
  

• 若使用镜像拉取密钥，检查Kubernetes部署清单中是否配置了imagePullSecrets，且流水线中是否正确创建了对应的secret：

  kubectl create secret docker-registry acr-secret \
    --docker-server=<ACR登录服务器地址> \
    --docker-username=<服务主体ID> \
    --docker-password=<服务主体密钥> \
    --docker-email=<你的邮箱>
  

  同时确保部署清单中引用了该secret：

  spec:
    containers:
    - name: restauapp
      image: <ACR地址>/restauapp:<标签>
    imagePullSecrets:
    - name: acr-secret
  

2. 验证镜像地址与推送状态 #

• 核对GitHub Workflow中构建推送的镜像标签，是否与Kubernetes清单中的镜像地址完全一致（比如是否使用了${{ github.sha }}作为动态标签，但清单中未同步）
• 登录Azure门户进入ACR，确认对应tag的镜像已成功推送；或执行命令检查：

  az acr repository show-tags -n <你的ACR名称> --repository restauapp
  

3. 检查GitHub Workflow的权限配置 #

• 确认Workflow中使用的Azure服务主体（AZURE_CREDENTIALS）拥有足够权限：需要AKS的Contributor权限，以及ACR的AcrPush（推送镜像）和AcrPull（部署拉取）权限
• 检查azure/login步骤的凭据是否有效，避免凭据过期或权限被修改

4. 排查负载均衡超时根源 #

镜像拉取失败会导致Pod无法启动，负载均衡没有可用后端节点，因此先解决镜像问题：

• 执行kubectl get pods查看Pod状态，若显示ImagePullBackOff或ErrImagePull，则聚焦镜像拉取问题
• 若Pod正常启动，检查服务配置：

  kubectl get services
  

  确认负载均衡IP正确，且服务的targetPort与容器暴露的端口（比如Django默认8000）一致
• 检查AKS集群的网络安全组（NSG），确保负载均衡使用的端口（如80/443）已开放入站规则

5. 对比本地与流水线的配置差异 #

• 对比本地部署用的Kubernetes清单和流水线中部署的清单，确认镜像地址、环境变量、端口映射等完全一致
• 查看Workflow中镜像构建步骤的日志，确认Dockerfile执行无异常（比如依赖安装失败、端口暴露错误）

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