Контейнер не обязан иметь shell внутри себя. Если приложение работает, но
docker exec недоступен или сам контейнерный userspace сломан, namespace можно открыть непосредственно с хостаСначала находим PID основного процесса контейнера
docker inspect -f '{{.State.Pid}}' <container>Допустим, получили
4217Проверяем его namespaces:
ls -l /proc/4217/ns/
Например:
net -> net:[4026532456]
mnt -> mnt:[4026532457]
pid -> pid:[4026532458]
Заходим сразу во все основные namespace
nsenter -t 4217 -m -u -i -n -p -C
Теперь shell работает в namespace процесса контейнера
Проверка:
hostname
ip addr
mount
ps aux
При этом команды выполняются с host kernel, но видят изолированное окружение контейнера
Можно войти только в нужный namespace
Например, посмотреть сетевую конфигурацию контейнера с хоста:
nsenter -t 4217 -n ip addr
Или его mount namespace:
nsenter -t 4217 -m mount
Это удобно, когда проблема именно в одном namespace и нет смысла запускать полноценный shell
Почему nsenter особенно полезен при авариях
docker exec фактически зависит от container runtime и возможности запустить новый процесс внутри контейнераnsenter работает иначе: он использует namespace уже существующего процесса через /proc/<PID>/nsПоэтому если внутри контейнера сломан shell, отсутствуют утилиты или runtime не может выполнить
exec, диагностику всё ещё можно проводить с хоста
Важный нюанс: namespace изолирует пространство имён, но не создаёт отдельное ядро. Процессы контейнера и хоста используют одно Linux kernel, просто смотрят на разные namespace
