Question

我们在一个集群环境中使用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

“主” runc的父进程是：

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

我阅读了一些有关containerd-shim和runc的内容（包括this one和that other one，还有更多内容）...我想我知道runc用于启动无妖的容器，然后进行容器化-shim接管容器进程的父级。
因此，我理解为什么每次启动容器时都会将runc短暂地视为容器填充的子进程。

但是仍然有一些事情让我无法逃脱：

为什么有几个级别的runc（一个runc调用另一个）？
为什么它不叫“ runc”而是“ exe”，因此看起来非常可疑（听起来像是合法的）？是容器（或另一个容器）的主要过程吗？
这个奇怪的进程叫什么“ 4”，其可执行路径是“ /”？是容器（或主要容器）过程的一部分吗？
我猜curl是在容器中执行的运行状况检查（这是一个以healtcheck为本地主机的apache容器）。我说的对吗？
提供的容器的主要过程不是“ 4”个，我应该看到它吗，怎么用类似的方式看到它？

同时，该过程刚刚停止使用整个CPU。每次启动容器时，它看起来都很简洁（但听起来很合法），但占用的百分比不超过百分之几。因此，我认为它的CPU使用率过高与我们容器中的某些问题有关。无论如何，解决cpu问题不是我的意思。

编辑1：

关于dockerfiles

VM上运行着很多容器，我不能提供所有的Dockerfile。我怀疑通过Healthcheck触发卷曲的是一个Apache httpd（基于centOs）图像。它与CentOS one非常接近，主要带有一些标签，清洁（未使用的模块）和附加的健康提示：

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

关于监视

我们将rsyslog与针对远程服务器的基本配置一起使用，然后启动auditctl来监视进程触发：

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

寻找有关容器填充/ runc子进程的解释

0 个答案: