使用@aws-sdk/client-sqs从EKS Pod推送至AWS SQS时遇CredentialsProviderError

错误本质 #

这个CredentialsProviderError并非SQS队列URL解析问题，而是AWS SDK在获取访问凭证时出现了异常：SDK尝试访问ECS容器元数据服务（地址169.254.170.23），但EKS集群的Pod并不依赖该服务，因此报错。

Prod环境异常的核心原因 #

Prod集群节点组的coredns和kube-proxy sidecar容器，大概率触发了以下一种或多种情况：

• 环境变量干扰：sidecar注入了AWS_CONTAINER_CREDENTIALS_RELATIVE_URI或AWS_CONTAINER_METADATA_URI环境变量，AWS SDK会优先使用这些变量指向的容器元数据服务，但EKS环境中不存在该服务。
• DNS解析错误：coredns的自定义配置将AWS元数据相关域名（如metadata.internal）错误解析到了ECS的元数据IP（169.254.170.23），而非EKS实例元数据服务（IMDS）的标准IP 169.254.169.254。
• 网络访问拦截：sidecar的网络策略或节点安全组规则，阻止了Pod访问IMDS的169.254.169.254地址，导致SDK fallback到错误的凭证获取路径。

Dev环境无此类sidecar，Pod默认通过IMDS或正确的IAM角色绑定服务账号（IRSA）获取凭证，因此运行正常。

修复步骤 #

1. 清除干扰性环境变量
   在Pod的YAML配置中显式清除相关AWS容器元数据环境变量：

   spec:
     containers:
       - name: your-app-container
         env:
           - name: AWS_CONTAINER_CREDENTIALS_RELATIVE_URI
             value: ""
           - name: AWS_CONTAINER_METADATA_URI
             value: ""
   

   也可以在Pod启动前执行unset AWS_CONTAINER_CREDENTIALS_RELATIVE_URI AWS_CONTAINER_METADATA_URI。

2. 验证IRSA配置（推荐方案）
   如果使用IRSA（EKS推荐的凭证管理方式），确认：

   • Pod关联的ServiceAccount已添加eks.amazonaws.com/role-arn注解，指向正确的IAM角色。
   • IAM角色已配置允许访问目标SQS队列的权限。
     AWS SDK会自动识别IRSA配置，无需访问IMDS。

3. 检查coredns配置
   查看prod集群的coredns ConfigMap：

   kubectl get configmap coredns -n kube-system -o yaml
   

   确认没有将元数据域名解析到169.254.170.23的自定义规则，如有则删除。

4. 测试IMDS访问
   在prod的Pod内执行以下命令，验证是否能正常访问IMDS：

   curl http://169.254.169.254/latest/meta-data/
   

   如果无法访问，检查节点安全组是否允许Pod访问该IP，或sidecar的网络策略是否拦截了相关流量。

内容的提问来源于stack exchange，提问作者Wall-E