Golang API应用Azure Pipeline发布至AKS失败求助

1. 验证AKS与ACR的关联权限 #

• 检查AKS集群的身份权限：
  • 若使用托管身份，执行命令确认是否已分配ACR的AcrPull角色：

    az role assignment list --assignee <AKS托管身份ID> --scope <ACR资源ID> --role AcrPull
    

  • 若使用服务主体，确认主体密码未过期，且对应的imagePullSecrets已配置在目标命名空间，同时检查Helm Chart中是否正确引用该Secret：

    kubectl get secret <镜像拉取Secret名> -n <命名空间> -o yaml
    

    确保Secret的.dockerconfigjson字段包含有效的ACR认证信息。

2. 确认镜像的存在性与标签准确性 #

• 直接验证目标镜像是否已推送到ACR：

  az acr repository show --name serverdev.azurecr.io --repository xxxx.golang-app.go-ver --tag 86895
  

  避免因Pipeline推送失败、标签拼写错误导致镜像不存在。

3. 对比同环境.NET Core应用的配置差异 #

• 检查两个应用的Deployment/Helm配置差异：
  • 是否使用不同的imagePullSecrets？
  • 是否依赖AKS集群默认托管身份拉取镜像（而非自定义Secret）？
  • 确认两个应用所在命名空间的权限配置一致：

    kubectl describe namespace <命名空间>
    

4. 临时关闭Helm原子发布以便排查 #

• 报错中atomic being set会在发布失败时自动回滚，导致无法保留现场。临时关闭该参数重新发布：

  helm install golang-app <Chart路径> --atomic=false --namespace <命名空间>
  

  发布失败后查看Pod的详细状态与事件：

  kubectl describe pod <失败Pod名> -n <命名空间>
  

5. 验证Pipeline的镜像推送与发布一致性 #

• 确认Pipeline中镜像推送步骤和Helm发布步骤使用同一套ACR认证信息，避免权限主体不一致。
• 检查Helm values文件中的image.tag与推送的镜像标签完全匹配（注意大小写、特殊字符）。

6. 检查ACR网络访问限制 #

• 若ACR设置了防火墙规则，确认AKS集群的节点IP范围或虚拟网络已加入ACR允许列表：

  az acr network-rule list --name serverdev.azurecr.io
  

  AKS 1.25.6的镜像拉取流程需要节点能正常访问ACR的认证服务。

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