引言 昨天(2023-02-22)开始发现公司 Spark 集群上出现一些任务执行时间过长最后失败,具体表现包括: 大量执行失败的 Task,最终任务也是失败的 在 Spark Master 管理界面上看到任务的
引言
昨天(2023-02-22)开始发现公司 Spark 集群上出现一些任务执行时间过长最后失败,具体表现包括:
大量执行失败的 Task,最终任务也是失败的
- 在 Spark Master 管理界面上看到任务的 Driver 地址不是真实 IP 地址,而是一个叫做“host.containers.internal”的主机名;
- Spark 的 worker 节点上能观察到在不停的创建 Java 进程,然后进程瞬间就结束了;
- 进入 worker 节点的日志目录查看日志内容,发现异常信息为连接 “host.containers.internal” 这个地址失败。
所以显然当前出现的问题跟“host.containers.internal”有关系。
背景说明:我们的 Spark 集群是运行在 podman 容器里的,而且是在非 root 用户下运行。
经过在互联网上搜索,发现这个主机名是容器分配给内部进程用来连接容器所在主机自身的。再进一步查看 podman 参考文档,按照里面的说法,仅当容器运行网络模式为 slirp4netns,即带上参数 "--network=slirp4netns"
时,才会有 host.containers.internal 这个主机名。
但我运行容器时带的参数是 "--network=host"
啊。
再仔细看文档才知道,slirp4netns 模式是非 root 运行容器的默认模式。按照我遇到的实际情况,难道我给的 "--network=host"
参数并没有起作用?但是用 podman inspect xxx | grep NetworkMode
命令查看容器得到的结果是:
"NetworkMode": "host"
不懂,先把这个放到一边,那么如何访问 host.containers.internal 这个主机呢,有两种方式:
- 参数改为
"--network=slirp4netns:allow_host_loopback=true"
- 修改
/usr/share/containers/containers.conf
,修改或添加配置network_cmd_options
的值为["allow_host_loopback=true"]
在不修改 --network
参数的前提下,我用第二种方法试试。
修改配置文件然后重启各个 worker 容器,故障消失,Spark 任务能够顺利执行完成。但还需要观察一段时间。
以上就是Spark 集群执行任务失败的故障处理方法的详细内容,更多关于Spark 集群任务失败故障处理的资料请关注自由互联其它相关文章!