Spark on K8s Operator中Yunikorn任务组内存计算问题分析

问题背景

在Spark on K8s Operator项目的最新版本中，当用户为PySpark应用配置spark.executor.pyspark.memory参数时，发现了一个与Yunikorn调度器任务组内存计算相关的问题。该问题会导致Executor Pod无法被正确调度，始终处于Pending状态。

问题现象

用户在使用SparkApplication CRD提交PySpark作业时，如果设置了spark.executor.pyspark.memory配置项，会出现以下现象：

1. Executor Pod的资源请求（requests.memory）会正确包含三部分内存之和：

   • 基础内存（spec.executor.memory）
   • 内存开销（spec.executor.memoryOverhead）
   • PySpark专用内存（spark.executor.pyspark.memory）

2. 但是Yunikorn任务组注解（yunikorn.apache.org/task-groups）中的minResources.memory仅计算了前两部分，忽略了PySpark专用内存。

3. 这导致Yunikorn调度器在分配资源时，发现实际Pod请求的内存大于任务组预留的内存，从而拒绝调度。

技术原理

在Spark on K8s架构中，当使用Yunikorn作为批处理调度器时，Operator会为Spark作业创建任务组（TaskGroup）注解。这个注解用于告诉Yunikorn：

1. 作业需要的最小资源量（minResources）
2. 各角色（Driver/Executor）的最小实例数（minMember）

对于PySpark应用，Spark会为Python进程分配额外的内存空间，这部分通过spark.executor.pyspark.memory参数配置。在资源计算时，这部分内存应该被包含在Executor的总内存需求中。

影响范围

该问题影响以下使用场景：

• 使用Spark on K8s Operator v2.0.0-rc.0版本
• 启用了Yunikorn调度器
• 运行PySpark应用
• 配置了spark.executor.pyspark.memory参数

解决方案

项目维护者已经确认了这个问题，并正在开发修复方案。修复的核心思路是：

1. 在计算Yunikorn任务组内存需求时，需要额外考虑PySpark专用内存配置
2. 确保任务组minResources.memory与实际Pod请求的内存一致

临时规避方案

在官方修复发布前，用户可以采取以下临时方案：

1. 将PySpark需要的内存合并到基础内存或内存开销中配置
2. 暂时不使用Yunikorn的硬性Gang Scheduling特性

总结

这个问题揭示了Spark on K8s Operator在特殊场景下资源计算的不一致性。对于PySpark用户来说，理解各种内存参数的用途和计算方式非常重要。项目团队正在积极修复这个问题，预计将在下一个版本中包含相关修复。