共计 959 个字符，预计需要花费 3 分钟才能阅读完成。
昨天（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 工作可能顺利执行实现。但还须要察看一段时间。
正文完
