» » Плагин kubectl-debug для отладки в pod'ах Kubernetes

 

Плагин kubectl-debug для отладки в pod'ах Kubernetes

Автор: admin от 15-01-2019, 11:40, посмотрело: 61

Плагин kubectl-debug для отладки в pod'ах Kubernetes


В конце прошлого года на Reddit представили плагин к kubectl, помогающий производить отладку в pod'ах кластера Kubernetes — kubectl-debug. Эта идея сразу же показалась интересной и полезной нашим инженерам, так что мы решили посмотреть на её воплощение и рады поделиться своими результатами с читателями хабры.документации проекта.



Что требуется для работы?



Автор 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 в репозитории проекта, на что разработчик откликнулся положительно и пообещал реализацию в ближайшее время. Очень порадовала быстрая и адекватная обратная связь. Так что будем с нетерпением ждать новых возможностей утилиты и её дальнейшего развития!



    P.S.



    Читайте также в нашем блоге:





    Источник: Хабр / Интересные публикации

    Категория: Программирование

    Уважаемый посетитель, Вы зашли на сайт как незарегистрированный пользователь.
    Мы рекомендуем Вам зарегистрироваться либо войти на сайт под своим именем.

    Добавление комментария

    Имя:*
    E-Mail:
    Комментарий:
    Полужирный Наклонный текст Подчеркнутый текст Зачеркнутый текст | Выравнивание по левому краю По центру Выравнивание по правому краю | Вставка смайликов Выбор цвета | Скрытый текст Вставка цитаты Преобразовать выбранный текст из транслитерации в кириллицу Вставка спойлера
    Введите два слова, показанных на изображении: *