Что произойдёт с хост-машиной, если процесс внутри Docker-контейнера вызовет kernel panic?

Последствия зависят от причины паники ядра (kernel panic).

1. Паника вызвана проблемой в пространстве пользователя (userspace) контейнера:

• Хост не пострадает. Контейнеры разделяют ядро хоста, но изолированы. Ошибка в приложении (например, сегфолт) завершит только процесс в контейнере.
• Контейнер перейдёт в статус Exited, и Docker может перезапустить его в зависимости от политики --restart.

2. Паника вызвана уязвимостью или ошибкой в самом ядре хоста:

• Хост-машина упадёт полностью. Если процесс в контейнере, используя определённые capability (например, SYS_ADMIN), или через уязвимость, спровоцирует критическую ошибку в общем ядре, оно прекратит работу. Это затронет всю систему.

Пример опасной команды, которая может вызвать панику на хосте (если контейнеру даны повышенные права):

docker run --rm --privileged alpine sh -c "echo c > /proc/sysrq-trigger"

Best practices для предотвращения:

• Минимизируйте права: Используйте --cap-drop=ALL и добавляйте только необходимые capabilities (--cap-add=...).
• Избегайте --privileged: Это даёт контейнеру почти все права хоста.
• Read-only корневая ФС: Запускайте контейнеры с --read-only где возможно.
• Обновляйте: Регулярно обновляйте ядро хоста и Docker Engine для устранения известных уязвимостей.