Spark on K8s：driver容器创建后即失败 无明确报错仅退出码101

• Shell占位符未完成替换：driver容器实际执行的启动命令中，--class $className是原生占位符形式，没有被替换为实际的主类全限定名。这类未替换的参数传入JVM后，类加载阶段会抛出无法找到主类的未捕获异常，触发JVM以错误码101终止进程；因为日志缓冲机制的问题，异常栈可能来不及刷出到标准输出，就被容器运行时判定为进程退出。
• 部署模式配置错配：提交命令声明使用cluster模式部署，但driver容器内部实际执行的spark-submit命令硬编码了--deploy-mode client。配置不一致会触发Spark启动期的校验逻辑拦截，直接终止进程。

• 第一步：核对提交脚本的变量解析逻辑
  检查spark-submit命令的执行环境，确认是否存在因为字符串单引号包裹、Shell作用域不对导致$className变量没有被实际替换的情况。如果spark-submit拿到的--class参数是字面量字符串$className，类加载阶段会直接抛出类找不到的异常，且因为日志输出缓冲的问题，异常栈可能来不及刷出就被容器终止，最终只看到101的退出码。
  同时需要核对日志里出现的spark-internal、末尾无意义的args占位符，确认是不是镜像内置的启动脚本和自定义参数透传逻辑不兼容，导致传入的业务参数没有被正确接收到启动命令中。
• 第二步：核对K8s侧的权限配置
  确认spark-sa服务账号在pipelines命名空间下的权限：需要具备创建/删除Pod、获取Pod状态、读写配套ConfigMap的权限。权限不足会导致driver启动后无法和K8s API完成交互，直接抛出客户端初始化异常退出。
  可通过kubectl auth can-i命令逐一对校验权限项，不需要额外授权操作。
• 第三步：核对容器运行的基础环境
  检查driver镜像内的启动链路：确认日志中调用的tini进程具备可执行权限，/opt/spark路径下的spark-submit脚本存在且可执行；如果镜像内的Spark发行包被篡改过、路径和内置启动脚本不匹配，会直接导致启动命令执行失败返回101。
  同时核对spark.driver.bindAddress对应的IP，确认该IP是driver容器本身的网卡IP，如果绑定了不属于当前容器的IP，driver的RPC绑定阶段会失败，直接终止进程。

• 调整提交脚本逻辑，确保所有Shell变量（如$className）在spark-submit发起提交请求时就完成替换，不要在driver容器启动阶段再解析未替换的占位符参数；如果是依赖容器环境变量读取配置，需要确保对应变量被正确注入到driver Pod中。
• 对齐部署模式的配置逻辑：如果是cluster模式提交，需要确保driver容器内的启动脚本没有硬编码client模式的参数，保证两端的部署模式配置一致。
• 临时调整日志级别：添加--conf spark.driver.extraJavaOptions=-Dlog4j.rootCategory=DEBUG,console配置，强制把启动阶段的DEBUG级别的日志输出到控制台，避免异常栈因为日志缓冲没来得及输出就被进程终止的情况。

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