- PVSM.RU - https://www.pvsm.ru -
В конце прошлого года на Reddit представили [1] плагин к kubectl, помогающий производить отладку в pod'ах кластера Kubernetes — kubectl-debug [2]. Эта идея сразу же показалась интересной и полезной нашим инженерам, так что мы решили посмотреть на её воплощение и рады поделиться своими результатами с читателями хабры.
На данный момент существует серьезное неудобство в процессе отладки чего-либо в рамках pod'ов. Основная цель при сборке образа контейнера — минимизировать его, т.е. сделать как можно меньшим в размере и содержащим как можно меньше «лишнего» внутри. Однако когда доходит дело до проблем в работе конечного софта в контейнерах либо отладки его коммуникации с другими сервисами в кластере/снаружи… минимализм играет с нами злую шутку — ведь в контейнерах ничего нет для собственно процесса поиска проблем. Как правило, недоступны такие утилиты, как netstat/ip/ping/curl/wget и т.п.
И зачастую всё заканчивается тем, что инженер на скорую руку ставит необходимый софт прямо в работающем контейнере, чтобы «прозреть» и увидеть проблему. Именно для таких случаев плагин kubectl-debug и показался весьма полезным инструментом — ведь он спасает от насущной боли.
С его помощью можно одной командой запустить контейнер со всеми необходимыми инструментами на борту в контексте проблемного pod'а и изучать все процессы «со стороны», находясь внутри. Если вы уже когда-либо сталкивались с troubleshooting'ом в Kubernetes, то звучит привлекательно, не так ли?
В общих чертах архитектура данного решения выглядит как связка из плагина для kubectl и агента, запускающегося с помощью контроллера DaemonSet. Плагин обслуживает команды, начинающиеся с kubectl debug …
, и взаимодействует с агентами на узлах кластера. Агент в свою очередь запускается в хостовой сети, а также в pod агента монтируется хостовый docker.sock
для полного доступа к контейнерам на этом сервере.
Соответственно, при запросе на запуск отладочного контейнера в указанном pod'е:
происходит процесс по выявлению hostIP
pod'а, а также отправляется запрос агенту (работающему на подходящем хосте) о запуске отладочного контейнера в пространствах имён (namespaces), соответствующих целевому pod'у.
Более детальное представление об этих этапах доступно в документации проекта [3].
Автор kubectl-debug заявляет о наличии совместимости с версиями клиента/кластера Kubernetes 1.12.0+, однако у меня под рукой оказался K8s 1.10.8, на котором всё заработало без видимых проблем… с единственным примечанием: для того, чтобы команда kubectl debug
работала именно в таком виде, требуется версия kubectl именно 1.12+. В ином же случае все команды аналогичны, но вызываются только через kubectl-debug …
.
При запуске описанного в README
шаблона DaemonSet'а стоит не забывать про используемые вами taint'ы на узлах: без соответствующих toleration'ов pod'ы агента туда не поселятся и, как следствие, к pod'ам, живущим на таких узлах, вы не сможете подключиться отладчиком.
Help у отладчика весьма полный и, похоже, описывает все текущие возможности по запуску/конфигурированию плагина. В целом утилита радует большим количеством директив для запуска: можно подкладывать сертификаты, указывать контекст kubectl, указывать отдельный kubectl config или адрес API-сервера кластера и другое.
Установка до момента «всё работает» сводится к двум этапам:
kubectl apply -f agent_daemonset.yml
;Как же им пользоваться? Допустим, у нас следующая проблема: не происходит сбор метрик одного из сервисов в кластере — и нам хочется проверить, есть ли сетевые проблемы между Prometheus и целевым сервисом. Как легко догадаться, в образе Prometheus не хватает требуемых инструментов.
Попробуем подключиться в контейнер с Prometheus (если в pod'е несколько контейнеров — потребуется указать, к какому конкретно подключаться, а иначе отладчик выберет первый по умолчанию):
kubectl-debug --namespace kube-prometheus prometheus-main-0
Defaulting container name to prometheus.
pulling image nicolaka/netshoot:latest...
latest: Pulling from nicolaka/netshoot
4fe2ade4980c: Already exists
ad6ddc9cd13b: Pull complete
cc720038bf2b: Pull complete
ff17a2bb9965: Pull complete
6fe9f5dade08: Pull complete
d11fc7653a2e: Pull complete
4bd8b4917a85: Pull complete
2bd767dcee18: Pull complete
Digest: sha256:897c19b0b79192ee5de9d7fb40d186aae3c42b6e284e71b93d0b8f1c472c54d3
Status: Downloaded newer image for nicolaka/netshoot:latest
starting debug container...
container created, open tty...
[1] →
root @ /
Предварительно мы выяснили, что проблемный сервис живет на адресе 10.244.1.214 и слушает порт 8080. Конечно, мы можем проверять доступность и с хостов, однако для достоверного процесса отладки эти операции необходимо воспроизводить в идентичных (или максимально приближенных к этому) условиях. Поэтому проверка из pod'а/контейнера с Prometheus — лучший вариант. Начнём с простого:
[1] → ping 10.244.1.214
PING 10.244.1.214 (10.244.1.214) 56(84) bytes of data.
64 bytes from 10.244.1.214: icmp_seq=1 ttl=64 time=0.056 ms
64 bytes from 10.244.1.214: icmp_seq=2 ttl=64 time=0.061 ms
64 bytes from 10.244.1.214: icmp_seq=3 ttl=64 time=0.047 ms
64 bytes from 10.244.1.214: icmp_seq=4 ttl=64 time=0.049 ms
^C
--- 10.244.1.214 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 61ms
rtt min/avg/max/mdev = 0.047/0.053/0.061/0.007 ms
Всё хорошо. Может, порт недоступен?
[1] → curl -I 10.244.1.214:8080
HTTP/1.1 200 OK
Date: Sat, 12 Jan 2019 14:01:29 GMT
Content-Length: 143
Content-Type: text/html; charset=utf-8
И тут нет проблем. Тогда проверим, происходит ли собственно общение между Prometheus и endpoint'ом с метриками:
[2] → tcpdump host 10.244.1.214
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
14:04:19.234101 IP prometheus-main-0.prometheus-operated.kube-prometheus.svc.cluster.local.36278 > 10.244.1.214.8080: Flags [P.], seq 4181259750:4181259995, ack 2078193552, win 1444, options [nop,nop,TS val 3350532304 ecr 1334757657], length 245: HTTP: GET /metrics HTTP/1.1
14:04:19.234158 IP 10.244.1.214.8080 > prometheus-main-0.prometheus-operated.kube-prometheus.svc.cluster.local.36278: Flags [.], ack 245, win 1452, options [nop,nop,TS val 1334787600 ecr 3350532304], length 0
14:04:19.290904 IP 10.244.1.214.8080 > prometheus-main-0.prometheus-operated.kube-prometheus.svc.cluster.local.36278: Flags [P.], seq 1:636, ack 245, win 1452, options [nop,nop,TS val 1334787657 ecr 3350532304], length 635: HTTP: HTTP/1.1 200 OK
14:04:19.290923 IP prometheus-main-0.prometheus-operated.kube-prometheus.svc.cluster.local.36278 > 10.244.1.214.8080: Flags [.], ack 636, win 1444, options [nop,nop,TS val 3350532361 ecr 1334787657], length 0
^C
4 packets captured
4 packets received by filter
0 packets dropped by kernel
Запросы-ответы приходят. По итогу этих операций можно заключить, что проблем на уровне сетевого взаимодействия нет, а значит (скорее всего) — смотреть надо с прикладной стороны. Подключаемся к контейнеру с exporter'ом (тоже, конечно, с помощью рассматриваемого отладчика, т.к. exporter'ы всегда имеют крайне минималистичные образы) и… с удивлением обнаруживаем, что есть проблема в конфигурации сервиса — например, забыли направить exporter на правильный адрес конечного приложения. Дело раскрыто!
Разумеется, в описанной здесь ситуации возможны и другие пути отладки, но их мы оставим за рамками статьи. Итог же таков, что у kubectl-debug предостаточно возможностей для использования: ведь в работу можно запустить совершенно любой образ, а при желании — даже собрать какой-то свой специфичный (с необходимым набором инструментария).
Какие ещё варианты применения сразу приходит в голову?
В целом же очевидно, что ситуаций, в которых такой инструмент может пригодиться, сильно больше. Инженеры, сталкивающиеся с ними в работе каждый день, смогут оценить потенциал утилиты в плане «живой» отладки.
Kubectl-debug — полезный и перспективный инструмент. Конечно, есть кластеры Kubernetes и приложения, для которых он не имеет большого смысла, но всё же вероятнее случаи, когда он окажет неоценимую помощь в отладке — в особенности, если речь заходит о боевом окружении и необходимости быстро, прямо здесь и сейчас, найти причины возникшей проблемы.
Первый опыт использования выявил острую потребность в возможности подключения к pod'у/контейнеру, который запускается не до конца (например, «висит» в CrashLoopbackOff
), как раз с целью на ходу проверять причины «незапуска» приложения. По этому поводу я создал соответствующий issue [5] в репозитории проекта, на что разработчик откликнулся положительно и пообещал реализацию в ближайшее время. Очень порадовала быстрая и адекватная обратная связь. Так что будем с нетерпением ждать новых возможностей утилиты и её дальнейшего развития!
Читайте также в нашем блоге:
Автор: Андрей Радыгин
Источник [10]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/otladka/305293
Ссылки в тексте:
[1] представили: https://www.reddit.com/r/devops/comments/a8vnt5/i_wrote_a_tool_to_debug_kubernetes_pods_more/
[2] kubectl-debug: https://github.com/aylei/kubectl-debug
[3] документации проекта: https://github.com/aylei/kubectl-debug#details
[4] здесь: https://github.com/aylei/kubectl-debug#quick-start
[5] соответствующий issue: https://github.com/aylei/kubectl-debug/issues/8
[6] Kubernetes tips & tricks: доступ к dev-площадкам: https://habrahabr.ru/company/flant/blog/427745/
[7] kubebox и другие консольные оболочки для Kubernetes: https://habrahabr.ru/company/flant/blog/426985/
[8] Представляем loghouse — Open Source-систему для работы с логами в Kubernetes: https://habr.com/company/flant/blog/341386/
[9] Мониторинг и Kubernetes (обзор и видео доклада): https://habr.com/company/flant/blog/412901/
[10] Источник: https://habr.com/ru/post/436112/?utm_source=habrahabr&utm_medium=rss&utm_campaign=436112
Нажмите здесь для печати.