Bitnami Spark Docker集群Worker CPU分配报错排查咨询

云上老周

2026-8-26

排查思路

这个报错是Spark TaskScheduler做参数校验时，检测到单任务分配的CPU核数≤0抛出的，后续资源申请失败是连锁反应，按以下优先级排查即可，不需要盲目调整无关配置：

校验全集群配置一致性
不要只检查本地写的compose文件，直接进入容器内读取实际加载的运行配置：
1. 进入Master容器执行cat /opt/bitnami/spark/conf/spark-defaults.conf，确认spark.task.cpus参数值为1（Spark默认值），不存在被篡改为0的情况
2. 分别进入两个Worker容器执行相同命令，重点对比报错节点的配置，排查是否存在配置文件挂载遗漏、错误配置只同步到单节点的问题。bitnami镜像支持通过SPARK_TASK_CPUS环境变量覆盖该参数，同步检查compose中对应Worker的环境变量配置，排除误写为0的情况
3. 启动spark-shell时显式传参做校验：spark-shell --conf spark.task.cpus=1 --master spark://<master内网IP>:7077，如果此时报错消失，说明是默认配置加载异常
校验Worker节点的CPU资源识别逻辑
bitnami版Spark启动Worker时会自动读取容器cgroup的CPU配额计算自身可用资源，如果cgroup配置读取异常，识别到的可用CPU为0，也会触发该报错：
1. 检查docker-compose 3.6的资源配置写法：CPU、内存配额必须写在deploy.resources.limits字段下，不要混用旧版本的cpu_quota、cpu_shares等废弃字段，正确配置片段参考：
```
spark-worker:
  image: bitnami/spark:3.3
  deploy:
    resources:
      limits:
        cpus: '2.0'
        memory: 1G
```
注意非Swarm模式下运行compose，需要Docker Engine版本≥20.10才能正确识别deploy段的资源限制，旧版本Docker会忽略该配置，导致cgroup配额值异常
2. 进入报错Worker容器执行两条命令校验cgroup值：cat /sys/fs/cgroup/cpu/cpu.cfs_quota_us、cat /sys/fs/cgroup/cpu/cpu.cfs_period_us，如果quota值为-1说明CPU配额未生效，两个值相除结果为0时就会触发CPU数校验错误
3. 访问Master节点的8080 WebUI，查看两个Worker上报的可用资源，如果报错Worker的Available Cores显示为0，即可确认是资源识别环节故障
排除常驻Akka服务的干扰
1. 检查Akka-HTTP服务的启动参数，确认没有通过-Dspark.*JVM参数篡改Spark全局配置，尤其排查是否存在误写spark.task.cpus=0、spark.executor.cores=0的情况
2. 临时停掉Akka-HTTP服务，重启集群后再启动spark-shell测试，排除服务抢占资源、动态修改Spark配置的影响
校验Application资源申请参数
进入Master 8080 UI的Running Applications页，查看spark-shell对应的任务申请的Executor核数、单task核数，确认不存在参数值为0的情况。如果Executor申请的核数大于Worker剩余可用核数，也会触发资源分配失败，但不会抛出CPUs per task的报错，这一点可以用来区分故障层级

修复方案

强制统一全集群配置
在Master、所有Worker的compose配置中统一添加固定环境变量，避免配置漂移：

environment:
  - SPARK_TASK_CPUS=1
  - SPARK_EXECUTOR_CORES=1

重建容器时删除旧的配置持久化卷，避免历史错误配置残留，执行命令：docker-compose down -v && docker-compose up -d
2. 修正资源配置
替换所有废弃的CPU、内存配置字段，按上述规范写在deploy.resources段，确认Docker版本支持资源限制加载，重建后在Master UI确认每个Worker正确上报2核、1G可用资源
3. 分步验证
先不启动Akka-HTTP服务，启动spark-shell后执行简单测试任务：

sc.parallelize(1 to 100).count()

任务执行成功后，再启动Akka-HTTP服务复跑测试，确认无配置冲突即可

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