寻找有关containerd-shim/runc子进程的解释

Question

我们在 swarm 环境中使用 docker。一切都很好......但是对于几天前出现的一个名为“exe”的奇怪进程：

14126 root      20   0  446836  33648    184 R  49.0  0.2   0:05.98 exe
    1 root      20   0   52356    532    332 S  34.3  0.0   2750:22 systemd
13789 root      20   0 5424660  49784      0 S   5.6  0.3   2381:57 dockerd

它确实占用了 100% 的 CPU。
我们试图了解它来自哪里，但它非常不稳定，它的 pid 每 3-4 秒就会改变一次。你可以猜想，这样的行为引发了一些警报。
最终，我们设置了一些监控工具（使用auditd）来拍摄它的快照，并看到：

Syscall event   curl    /usr/bin/curl   24242   24234
Syscall event   4       /               24240   24234
Syscall event   exe     /usr/bin/runc   24240   24234
Syscall event   runc    /usr/bin/runc   24234   10444

“main”runc 的父进程是：

root 10444 2621 0 Nov13 ? 00:07:07 containerd-shim

我读了一些关于containerd-shim和runc的东西（包括这一篇和那一篇，还有更多）...我想我理解runc用于启动无恶魔容器，然后containerd-shim接管作为容器进程'家长。
因此，我明白为什么每次启动容器时我都会短暂地将 runc 视为 containerd-shim 的子进程。

但仍有一些事情我仍然无法理解：

• 为什么 runc 有多个级别（一个 runc 调用另一个 runc）？
• 为什么它不被称为“runc”而是“exe”，因此看起来非常可疑（当它听起来像是合法的时候）？它是容器（或另一个容器）的主进程吗？
• 这个名为“4”且其可执行路径为“/”的奇怪进程是什么？它是容器（或主要进程）中进程的一部分吗？
• 我猜curl是在容器中执行的健康检查（它是一个apache容器，其健康检查针对本地主机）。我对吗？
• 如果容器的主进程不是“4”进程，我应该看到它吗？我怎样才能以类似的方式看到它？

与此同时，该进程刚刚停止使用整个CPU。每次启动容器时，它都会短暂出现（但听起来合法），但不会超过几个百分点。所以我认为它的CPU使用率过高与我们容器中的某些问题有关。无论如何，解决cpu的问题不是我这里的重点。

编辑1：

关于 dockerfile

虚拟机上运行着很多容器，我无法提供所有 Dockerfile。我怀疑通过健康检查触发curl的是一个apache httpd（基于centOs）图像。它与CentOS非常接近，主要有一些标签、清理（未使用的模块）和一个额外的健康检查：

HEALTHCHECK --interval=5s --timeout=3s CMD curl --noproxy '*' --fail http://localhost:80/ || exit 1 

关于监控

我们使用rsyslog和针对远程服务器的基本conf，然后启动auditctl 来监视进程触发：

service rsyslog restart
service auditd start
auditctl -a always,exit -F arch=b64 -S execve -F key=procmon