Comments 5
Ну, я так понял, что в сам исследуемый контейнер в поде эта утилита никакие ping/curl etc. не устанавливает. Т.е. в под инжектируется именно отдельный отладочный контейнер. Т.о. получается, что это не интерфейс к самому проблемному контейнеру в поде, а отдельная штука, которая может отладку только запутать (хотя действительно отмечу, что если есть сетевые проблемы, то они скорее всего распространяются на ВЕСЬ под, а не на конкретный контейнер сервиса, запущенный в поде — и этот кейс вышеописанный в статье инструментарий отлавливает). И в чем тогда преимущество от прямого выполнения команд в проблемном контейнере!?
Ну вообще-то не совсем так.
В документации сообщается, что:
Соответственно мы разделяем все основные окружения с целевым контейнером, т.е. находимся в том же контексте, включая сеть, процессы и тд.
Так что не вижу вариантов, при которых это может запутать отладку.
Когда проблемный под крашится — тут да, новый функционал утилиты будет «форкать» по сути существующий под, запускать отладочный под/контейнер и в него монтировать ФС проблемного контейнера. Но при этом доступен тот же chroot который поможет запускать процессы «как бы» в конечном контейнере.
В документации сообщается, что:
The agent runs a debug container with tty and stdin opened, the debug contaienr will join the pid, network, ipc and user namespace of the target container.
Соответственно мы разделяем все основные окружения с целевым контейнером, т.е. находимся в том же контексте, включая сеть, процессы и тд.
Так что не вижу вариантов, при которых это может запутать отладку.
Когда проблемный под крашится — тут да, новый функционал утилиты будет «форкать» по сути существующий под, запускать отладочный под/контейнер и в него монтировать ФС проблемного контейнера. Но при этом доступен тот же chroot который поможет запускать процессы «как бы» в конечном контейнере.
Sign up to leave a comment.
Плагин kubectl-debug для отладки в pod'ах Kubernetes