Ищу объяснение о дочерних процессах containerd-shim/runc

Мы используем докер в среде роя. Все в порядке... но для странного процесса с именем "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 % ЦП.
Мы пытались понять, откуда он взялся, но он был очень нестабильным, а его 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» и чей путь к исполняемому файлу «/»? Это часть процессов в контейнере (или основной)?
• Я предполагаю, что завиток — это проверка работоспособности, выполняемая в контейнере (это контейнер Apache с проверкой работоспособности, нацеленной на локальный хост). Я прав?
• При условии, что основной процесс контейнера не «4», должен ли я его видеть и как я могу увидеть его аналогичным образом?

Тем временем процесс просто перестал использовать весь процессор. Он появляется ненадолго (но звучит правдоподобно) каждый раз при запуске контейнера, но занимает не более нескольких процентов. Поэтому я думаю, что чрезмерное использование ЦП было связано с какой-то проблемой в нашем контейнере. В любом случае, решение проблемы процессора не было моей целью.

Редактировать 1:

О файлах докеров

На виртуальной машине работает много контейнеров, и я не могу предоставить все файлы Dockerfile. Тот, который, как я подозреваю, запускает завиток через Healthcheck, — это образ apache httpd (на основе CentOs). Он очень близок к CentOS, в основном некоторая маркировка, очистка (неиспользуемые модули) и дополнительная проверка здоровья:

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