AWS EKS中thanos-store Pod因S3权限拒绝崩溃的排查求助

环境与问题描述 #

• 部署架构：AWS EKS集群中部署kube-thanos，采用无Prometheus sidecar的"remote write"架构，整合S3、thanos-receive与thanos-store
• 问题现象：thanos-store Pod持续处于CrashLoopBackOff状态，日志报错：

  err="bucket store initial sync: sync block: BaseFetcher: iter bucket: Access Denied"
  

已完成的配置 #

• IRSA权限配置：创建了具备S3所需权限的thanos IAM角色，并已将角色ARN正确注解到thanos-store对应的ServiceAccount上
• 对象存储配置：通过Kubernetes Secret传递S3配置，Secret内容如下：

  type: S3
  config:
    bucket: gd9-thanos
    endpoint: s3.us-east-2.amazonaws.com
  

• Pod环境变量：已配置IRSA所需的全部环境变量：

  - name: AWS_STS_REGIONAL_ENDPOINTS
    value: regional
  - name: AWS_DEFAULT_REGION
    value: us-east-2
  - name: AWS_REGION
    value: us-east-2
  - name: AWS_ROLE_ARN
    value: arn:aws:iam::xxxxxxxxxxx:role/thanos
  - name: AWS_WEB_IDENTITY_TOKEN_FILE
    value: /var/run/secrets/eks.amazonaws.com/serviceaccount/token
  

• 已尝试操作：参考Thanos官方存储文档相关建议，未解决问题
• 当前Pod状态：

  k get pods -n monitoring | grep thanos
  thanos-query-75f5bbf7c-62528                                1/1     Running            0             4h10m
  thanos-receive-ingestor-default-0                           1/1     Running            0             4h10m
  thanos-receive-router-76576bf5cb-ld6jh                      1/1     Running            0             4h10m
  thanos-store-0                                              0/1     CrashLoopBackOff   8 (44s ago)   21m
  

• 验证IAM角色权限细节

  • 确认IAM角色的权限策略包含S3桶的ListBucket、GetObject、ListMultipartUploads、ListBucketMultipartUploads、AbortMultipartUpload操作——同步块过程需要遍历桶的权限，仅基础读写权限可能不足
  • 检查权限策略的资源是否准确指定了目标桶arn:aws:s3:::gd9-thanos以及桶内所有对象arn:aws:s3:::gd9-thanos/*

• 检查IRSA信任关系

  • 确认IAM角色的信任策略正确配置，允许EKS OIDC身份提供商访问，信任策略需包含以下结构（替换集群OIDC地址和ServiceAccount信息）：

    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Effect": "Allow",
          "Principal": {
            "Federated": "arn:aws:iam::xxxxxxxxxxx:oidc-provider/oidc.eks.us-east-2.amazonaws.com/id/<YOUR_CLUSTER_OIDC_ID>"
          },
          "Action": "sts:AssumeRoleWithWebIdentity",
          "Condition": {
            "StringEquals": {
              "oidc.eks.us-east-2.amazonaws.com/id/<YOUR_CLUSTER_OIDC_ID>:sub": "system:serviceaccount:monitoring:<YOUR_THANOS_STORE_SA>"
            }
          }
        }
      ]
    }
    

  • 确保ServiceAccount的名称和命名空间与信任策略中的sub字段完全匹配

• 验证Pod的IRSA配置有效性

  • 在同命名空间下启动测试Pod，使用相同的ServiceAccount，执行aws s3 ls s3://gd9-thanos命令验证S3访问权限
  • 测试Pod可使用amazonlinux:2镜像，安装AWS CLI后执行验证：

    curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
    unzip awscliv2.zip
    ./aws/install
    aws s3 ls s3://gd9-thanos
    

• 检查S3桶的访问控制列表（ACL）

  • 确认桶的ACL没有拒绝IAM角色的访问权限，避免桶级别的权限覆盖IAM策略

• 优化Thanos Store的对象存储配置

  • 在S3配置中添加signature_version: v4，明确指定签名版本：

    type: S3
    config:
      bucket: gd9-thanos
      endpoint: s3.us-east-2.amazonaws.com
      signature_version: v4
    

  • 确认Secret已正确挂载到Pod中，且OBJSTORE_CONFIG环境变量正确指向Secret的内容

• 查看详细日志

  • 启动thanos-store时添加--log.level=debug参数，获取更详细的权限错误日志，确认具体被拒绝的操作

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