4

我们在 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

“主” runc 的父进程是：

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

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

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

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

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

编辑 1：

关于 dockerfiles

虚拟机上运行着很多容器，我无法提供所有的 Dockerfile。我怀疑通过 healthcheck 触发 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
4

0 回答 0