Spark Operator中S3a凭证配置不一致问题的分析与解决

问题背景

在使用Spark Operator在Kubernetes集群上运行Spark作业时，开发人员遇到了一个关于S3a凭证提供者配置不一致的问题。具体表现为：虽然已经明确配置了使用WebIdentityTokenCredentialsProvider作为凭证提供者，但Spark作业在访问S3存储时仍然尝试使用默认的SimpleAWSCredentialsProvider，导致认证失败。

问题现象

开发人员配置了以下关键参数：

• spark.hadoop.fs.s3a.aws.credentials.provider=com.amazonaws.auth.WebIdentityTokenCredentialsProvider
• 设置了IRSA(IAM Roles for Service Accounts)相关的服务账户和角色ARN
• 配置了S3a相关的其他参数如文件系统实现类、提交器等

然而，当Spark作业尝试访问S3存储时，出现了以下错误：

java.nio.file.AccessDeniedException: s3a://my/eventlogs: org.apache.hadoop.fs.s3a.auth.NoAwsCredentialsException: SimpleAWSCredentialsProvider: No AWS credentials in the Hadoop configuration

这表明系统仍然在使用SimpleAWSCredentialsProvider而非配置的WebIdentityTokenCredentialsProvider。

根本原因分析

经过深入排查，发现问题源于Spark作业脚本中存在一段硬编码的凭证提供者配置：

.config('spark.hadoop.fs.s3a.aws.credentials.provider',
    'org.apache.hadoop.fs.s3a.SimpleAWSCredentialsProvider')

这段代码是在早期为支持ECS环境而添加的，但在迁移到EKS+Spark Operator环境后未被移除。当SparkSession初始化时，这段代码会覆盖通过Spark Operator配置的凭证提供者设置，导致系统错误地尝试使用SimpleAWSCredentialsProvider。

解决方案

解决此问题的关键在于确保凭证提供者配置的一致性：

1. 移除脚本中的硬编码配置：删除Spark作业脚本中关于凭证提供者的硬编码设置，确保完全依赖外部配置。

2. 统一配置管理：将所有S3相关的配置集中通过Spark Operator的sparkConf或hadoopConf进行管理，避免分散在多处。

3. 验证服务账户配置：虽然本例中服务账户配置正确，但在类似问题排查时，应确认：

   • 服务账户是否正确关联了IAM角色
   • IAM角色的信任关系是否正确配置
   • 所需的S3访问权限是否已授予

4. 配置加载顺序检查：了解Spark配置的加载顺序，确保关键配置不会被后续代码覆盖。Spark配置的优先级通常为：

   • 代码中直接设置的配置（最高优先级）
   • spark-submit或Spark Operator传递的参数
   • 配置文件中的设置（最低优先级）

经验总结

1. 环境迁移时的配置审查：当将Spark作业从一个环境迁移到另一个环境时，必须全面审查所有硬编码配置，特别是与认证、存储相关的敏感配置。

2. 配置的集中管理：对于跨环境部署的Spark作业，建议将环境特定的配置（如凭证提供者）外部化，通过配置文件或部署工具管理，而不是硬编码在作业脚本中。

3. 详细的日志分析：当遇到凭证问题时，应仔细分析日志中显示的完整凭证提供者链，这可以帮助快速定位配置被覆盖的位置。

4. 测试策略：在类似场景下，建议先使用最小化配置进行测试，验证基础功能正常后再添加复杂配置，这有助于隔离问题。

结论

在Kubernetes上使用Spark Operator运行Spark作业时，确保配置的一致性至关重要。特别是在使用S3a等需要认证的存储系统时，任何配置的冲突或覆盖都可能导致认证失败。通过集中管理配置、移除不必要的硬编码设置，并理解配置加载顺序，可以有效避免这类问题。此案例也提醒我们，在环境迁移过程中，全面的配置审查是不可或缺的步骤。