AI Platform Pipelines升级后Pods随机失败，求助排查方案

这种随机出现的认证故障确实挺棘手的，尤其是升级到v0.5.1后才发生的。既然你已经确认了Workload Identity配置流程没问题，而且Credentials API也已经启用，那咱们可以从以下几个方向深入排查：

• 先确认Workload Identity绑定没遗漏
  升级实例大概率会创建新的Kubernetes Service Account（KSA），或者原有绑定可能被覆盖了。你可以跑这两个命令验证一下：

  # 检查你的GSA是否给对应KSA分配了workloadIdentityUser角色
  gcloud iam service-accounts get-iam-policy <你的GSA邮箱>
  # 查看流水线用的KSA的annotation是否正确指向GSA
  kubectl describe sa <流水线KSA名称> -n <流水线命名空间>
  

  重点要确认新实例用的KSA和GSA是不是跟之前v0.2.5版本一致，有没有漏掉某个组件的KSA绑定。

• 排查Metadata Server的状态
  错误里提到metadata服务返回500，这说明不是权限问题，是Pod访问metadata.google.internal时服务端出错了。你可以试试：

  • 如果失败的Pod还没被清理，进去执行curl http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/?recursive=true -H "Metadata-Flavor: Google"，看看具体返回啥；
  • 去kube-system命名空间下找metadata-agent-开头的Pod，看看它们的日志有没有异常，这是负责处理metadata请求的代理；
  • 确认Pod能正常解析metadata.google.internal到169.254.169.254，DNS解析出问题也会导致这类错误。

• 检查新版本组件的ServiceAccount配置变化
  v0.5.1可能调整了默认使用的ServiceAccount，比如某些组件改用了新的KSA，但这些KSA没配置Workload Identity绑定。你可以：

  • 看看流水线定义里各个组件有没有显式指定ServiceAccount，如果有的话，确认这些KSA都完成了和对应GSA的绑定；
  • 对比v0.2.5和v0.5.1的官方文档，看看有没有关于ServiceAccount配置的变更说明，说不定新版本有新的要求。

• 排查Pod启动时的竞争问题
  随机失败很可能和Pod启动时metadata服务还没就绪有关，尤其是集群资源紧张的时候。你可以试试：

  • 给流水线组件加个初始化容器，在主容器启动前先等metadata服务可用，比如：

    initContainers:
    - name: wait-for-metadata
      image: curlimages/curl
      command: ['sh', '-c', 'until curl -H "Metadata-Flavor: Google" http://metadata.google.internal/computeMetadata/v1/instance; do echo 等待metadata服务就绪...; sleep 2; done']
    

  • 检查Pod的重启策略，改成OnFailure的话，失败的Pod自动重启后说不定就能正常访问metadata服务了。

• 确认GKE集群版本和Pipelines兼容
  不同版本的AI Platform Pipelines对GKE集群版本有要求，v0.5.1可能需要特定版本的GKE支持。你可以查一下官方的兼容矩阵，看看你的集群版本是不是符合要求，要是版本太低，升级到推荐版本再试试。

• 检查网络策略和防火墙规则
  虽然部分Pod正常，但说不定有网络策略限制了某些Pod访问metadata服务。你可以：

  • 看看流水线所在命名空间的网络策略，有没有允许出站访问169.254.169.254（metadata服务的地址）；
  • 确认GKE节点的防火墙规则没阻断内部对metadata服务的请求。

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