Spark-on-K8s-Operator 中 Spark 3.5.0 应用启动问题分析与解决方案

问题背景

在使用 Spark-on-K8s-Operator 部署 Spark 应用时，用户从 Spark 3.1.1 升级到 3.5.0 版本后遇到了应用无法启动的问题。核心错误表现为 Spark 尝试删除 /opt/spark-jars/DataAnalyticsReporting.jar 文件时失败，导致整个应用启动流程中断。

错误现象分析

从日志中可以观察到两个关键错误点：

1. 文件删除失败警告：Spark 首先尝试使用 Unix 原生命令删除 JAR 文件失败，随后回退到 Java IO 方式删除仍然失败。
2. 权限问题：错误信息表明 Spark 进程没有足够的权限操作 /opt/spark-jars/ 目录下的文件。

根本原因

深入分析后，发现问题的根源在于：

1. 用户和权限配置不当：Spark 3.5.0 基础镜像使用 UID/GID 为 185 的 spark 用户运行，而用户 Dockerfile 中设置的权限和用户配置与之不匹配。
2. 工作目录冲突：Dockerfile 中将工作目录设置为 /opt/spark-jars/，同时又将 JAR 文件放在同一目录，这可能导致 Spark 内部文件管理逻辑冲突。

解决方案

经过多次尝试，最终有效的解决方案包括以下几个关键点：

1. 正确的 Dockerfile 配置

FROM spark:3.5.0

WORKDIR /opt/spark-jars/

ADD build/libs/DataAnalytics*.jar ./DataAnalytics.jar
ADD log4j-core-2.19.0.jar ./log4j-core-2.19.0.jar
ADD log4j-api-2.19.0.jar ./log4j-api-2.19.0.jar
ADD src/main/resources/log4j2.xml ./log4j2.xml
ADD spark-3-rules.yaml ./spark-3-rules.yaml
ADD jmx_prometheus_javaagent-0.11.0.jar ./jmx_prometheus_javaagent-0.11.0.jar

# Spark 基础镜像使用 UID/GID 185
USER root
RUN chown -R 185:185 /opt/spark-jars && chmod 777 /opt/spark-jars/*

WORKDIR /opt/spark/work-dir
USER spark

2. 关键配置要点

• 明确用户和组：Spark 3.5.0 基础镜像中的 spark 用户 UID/GID 为 185，必须确保文件权限正确设置
• 合理的工作目录：最终工作目录应设置为 /opt/spark/work-dir，这是 Spark 期望的工作目录
• 文件权限设置：需要为 /opt/spark-jars/ 目录下的所有文件设置正确的所有者和权限

3. SparkApplication YAML 配置建议

虽然问题主要出在 Docker 镜像构建上，但在 SparkApplication 资源配置中也需要注意：

• 确保 securityContext 和 podSecurityContext 配置与镜像中的用户一致
• 检查所有挂载卷的权限设置
• 验证服务账户是否有足够的权限

经验总结

1. 版本升级注意事项：Spark 不同版本的基础镜像可能有不同的默认用户配置，升级时需要特别注意
2. 权限管理：在容器化环境中，文件权限和用户配置是常见问题源，需要特别关注
3. 目录结构：遵循 Spark 官方镜像的预期目录结构可以减少兼容性问题
4. 日志配置：虽然解决了启动问题，但用户反映日志输出异常，这提示我们还需要检查日志配置文件的路径和权限

后续优化建议

对于遇到类似问题的开发者，建议：

1. 首先验证基础镜像中的默认用户和权限设置
2. 使用最小化的 Dockerfile 配置逐步测试
3. 检查所有挂载点的权限设置
4. 考虑使用更精细的权限控制而非简单的 777 权限

通过系统性地解决权限和工作目录问题，可以确保 Spark 应用在 Kubernetes 环境中稳定运行。