Thanos Compactor组件S3存储访问问题分析与解决方案

问题背景

在使用Thanos监控系统时，Compactor组件是负责处理长期存储数据的关键服务。它执行块压缩、降采样和保留策略管理等重要任务。近期在AWS EKS环境中部署Thanos时，发现Compactor组件在尝试删除标记为删除状态的块时出现了"Access Denied"错误，导致整个组件运行失败。

错误现象分析

从日志中可以清晰地看到错误链：

1. Compactor开始清理标记为删除的块
2. 尝试删除特定块(01J1AYPJ079SQG86D2HJ859JDV/meta.json)时遇到访问拒绝
3. 组件状态变为not-ready和not-healthy
4. 最终导致整个Compact命令失败

值得注意的是，其他组件如receive和store-gateway工作正常，只有Compactor出现权限问题。

根本原因

经过深入排查，发现问题根源在于Kubernetes Service Account的配置上。在AWS EKS环境中，要为Pod赋予AWS IAM角色需要通过Service Account的特定注解来实现。虽然Compactor的Pod关联了Service Account，但缺少关键的注解配置：

serviceAccount:
  annotations:
    "eks.amazonaws.com/role-arn": ${s3_role_arn}

由于这一缺失，Compactor Pod实际上没有获得预期的IAM角色，导致对S3存储的删除操作被拒绝。而其他组件可能从其他途径获得了部分权限（如节点IAM角色），所以能够正常工作。

AWS EKS IAM角色集成机制

在AWS EKS环境中，为Pod分配IAM权限的最佳实践是通过IAM Roles for Service Accounts (IRSA)。这一机制允许将IAM角色直接关联到Kubernetes Service Account，而不是节点。实现这一集成需要：

1. 创建IAM OIDC身份提供者
2. 创建具有必要权限的IAM角色
3. 为该角色配置信任关系，允许特定Service Account担任该角色
4. 在Service Account上添加注解指定角色ARN

解决方案实现

对于Thanos Compactor组件，完整的解决方案包括以下步骤：

1. 确保已创建具有足够S3权限的IAM角色
2. 在Helm values中正确配置Service Account注解

compactor:
  serviceAccount:
    create: true
    annotations:
      "eks.amazonaws.com/role-arn": "arn:aws:iam::ACCOUNT_ID:role/THANOS_COMPACT_ROLE"

3. 确认IAM角色策略包含必要的S3权限，如示例中的完全访问权限（生产环境建议遵循最小权限原则）

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:*"
            ],
            "Resource": [
                "arn:aws:s3:::BUCKET_NAME/*",
                "arn:aws:s3:::BUCKET_NAME"
            ]
        }
    ]
}

最佳实践建议

1. 权限最小化：虽然示例中使用了s3:*权限，生产环境应根据实际需要细化权限
2. 多环境配置：为不同环境（开发、测试、生产）配置不同的IAM角色和S3存储桶
3. 日志监控：配置CloudTrail和S3访问日志，监控Thanos组件的存储访问情况
4. 定期审计：定期审查IAM角色和策略，确保没有过度授权
5. 测试验证：在部署前使用aws-cli或类似工具验证权限是否配置正确

总结

Thanos Compactor组件的S3访问问题在AWS EKS环境中是一个常见配置问题。通过正确配置Service Account注解和关联IAM角色，可以解决权限不足的问题。这一案例也提醒我们，在云原生环境中，权限管理需要同时考虑Kubernetes和云平台两个层面的配置，任何一方的缺失都可能导致功能异常。