Инструменты для разработчиков приложений, запускаемых в Kubernetes

Современный подход к эксплуатации решает множество насущных проблем бизнеса. Контейнеры и оркестраторы позволяют легко масштабировать проекты любой сложности, упрощают релизы новых версий, делают их более надежными, но вместе с тем создают и дополнительные проблемы для разработчиков. Программиста, в первую очередь, заботит его код: архитектура, качество, производительность, элегантность, — а не то, как он поедет в Kubernetes и как его тестировать и отлаживать после внесения даже минимальных правок. Посему весьма закономерно и то, что активно развиваются инструменты для Kubernetes, помогающие решать проблемы даже самых «архаичных» разработчиков и позволяя им сосредоточиться на главном.

В этом обзоре представлена краткая информация о некоторых инструментах, которые упрощают жизнь программисту, чей код крутится в pod’ax Kubernetes-кластера.

Простые помощники

Kubectl-debug

• Суть: добавь свой контейнер в Pod и посмотри, что в нем происходит.
• GitHub.
• Краткая статистика GH: 715 звёзд, 54 коммита, 9 контрибьюторов.
• Язык: Go.
• Лицензия: Apache License 2.0.

Этот плагин для kubectl позволяет создать внутри интересующего pod'a дополнительный контейнер, который будет делить пространство имен процессов с остальными контейнерами. В нем можно производить отладку работы pod'а: проверить работу сети, послушать сетевой трафик, сделать strace интересующего процесса и т.п.

Также можно переключиться в контейнер процесса, выполнив chroot /proc/PID/root — это бывает очень удобно, когда нужно получить root shell в контейнере, для которого в манифесте выставлен securityContext.runAs.

Инструмент прост и эффективен, так что может пригодиться каждому разработчику. Подробнее о нём мы писали в отдельной статье.

Telepresence

• Суть: перенеси приложение на свой компьютер. Разрабатывай и отлаживай локально.
• Сайт; GitHub.
• Краткая статистика GH: 2131 звезда, 2712 коммитов, 33 контрибьютора.
• Язык: Python.
• Лицензия: Apache License 2.0.

Идея этой оснастки заключается в запуске контейнера с приложением на локальном пользовательском компьютере и проксировании всего трафика из кластера в него и обратно. Такой подход позволяет вести разработку локально, просто изменяя файлы в своей любимой IDE: результаты будут доступны сразу же.

Плюсы локального запуска — удобство правок и моментальный результат, возможность отлаживать приложение привычным способом. Из минусов — требовательность к скорости соединения, что особенно заметно, когда приходится работать с приложением с достаточно высоким RPS и трафиком. Кроме того, у Telepresence есть проблемы с volume mounts в Windows, что может стать решающим ограничителем для разработчиков, привыкшим к этой ОС.

Мы уже делились своим опытом использования Telepresence здесь.

Ksync

• Суть: почти мгновенная синхронизация кода с контейнером в кластере.
• GitHub.
• Краткая статистика GH: 555 звёзд, 362 коммита, 11 контрибьюторов.
• Язык: Go.
• Лицензия: Apache License 2.0.

Утилита позволяет синхронизировать содержимое локальной директории с каталогом контейнера, запущенного в кластере. Такой инструмент отлично подойдет для разработчиков на скриптовых языках программирования, основная проблема у которых — доставить код в работающий контейнер. Ksync призван снять эту головную боль.

При однократной инициализации командой ksync init в кластере создается DaemonSet, который используется для отслеживания состояния файловой системы выбранного контейнера. На своем локальном компьютере разработчик запускает команду ksync watch, которая следит за конфигурациями и запускает syncthing, осуществляющую непосредственную синхронизацию файлов с кластером.

Остается проинструктировать ksync, что и с чем синхронизировать. Например, такая команда:

ksync create --name=myproject --namespace=test --selector=app=backend --container=php --reload=false /home/user/myproject/ /var/www/myproject/

… создаст watcher с именем myproject, который будет искать pod с меткой app=backend и пытаться синхронизировать локальную директорию /home/user/myproject/ с каталогом /var/www/myproject/ у контейнера под названием php.

Проблемы и примечания по ksync из нашего опыта:

• На узлах Kubernetes-кластера должна использоваться overlay2 в качестве storage driver для Docker. Ни с какими другими утилита работать не будет.
• При использовании Windows в качестве ОС клиента возможна некорректная работа watcher'а файловой системы. Данный баг замечен при работе с крупными каталогами — с большим количеством вложенных файлов и директорий. Мы создали соответствующий issue в проекте syncthing, но прогресса по нему пока (с начала июля) нет.
• Используйте файл .stignore для того, чтобы указать пути или шаблоны файлов, которые не нужно синхронизировать (например, каталоги app/cache и .git).
• По умолчанию ksync будет перезагружать контейнер при каждом изменении файлов. Для Node.js это удобно, а для PHP — совершенно излишне. Лучше выключить opcache и использовать флаг --reload=false.
• Конфигурацию можно всегда исправить в $HOME/.ksync/ksync.yaml.

Squash

• Суть: отлаживай процессы прямо в кластере.
• GitHub.
• Краткая статистика GH: 1154 звёзд, 279 коммитов, 23 контрибьютора.
• Язык: Go.
• Лицензия: Apache License 2.0.

Данный инструмент предназначен для отладки процессов непосредственно в pod'ах. Утилита проста и в интерактивном режиме позволяет выбрать нужный отладчик (см. ниже) и namespace + pod, в процесс которого нужно вмешаться. В настоящее время поддерживаются:

• delve — для приложений на Go;
• GDB — через target remote + проброс порта;
• проброс порта JDWP для отладки Java-приложений.

Со стороны IDE поддержка есть лишь в VScode (с помощью расширения), однако в планах на текущий (2019) год значатся Eclipse и Intellij.

Для отладки процессов Squash запускает на узлах кластера привилегированный контейнер, поэтому необходимо сперва ознакомиться с возможностями безопасного режима во избежание проблем с безопасностью.

Комплексные решения

Переходим к тяжелой артиллерии — более «масштабным» проектам, призванным сразу закрыть многие потребности разработчиков.

NB: В этом списке, безусловно, есть место и нашей Open Source-утилите werf (ранее известной как dapp). Однако мы уже не раз писали и рассказывали о ней, а посему решили не включать в обзор. Для желающих ознакомиться с её возможностями поближе рекомендуем прочитать/послушать доклад «werf — наш инструмент для CI/CD в Kubernetes».

DevSpace

• Суть: для тех, кто хочет начать работать в Kubernetes, но не хочет глубоко залезать в его дебри.
• GitHub.
• Краткая статистика GH: 630 звёзд, 1912 коммитов, 13 контрибьюторов.
• Язык: Go.
• Лицензия: Apache License 2.0.

Решение от одноименной компании, предоставляющей managed-кластеры с Kubernetes для командной разработки. Утилита была создана для коммерческих кластеров, однако отлично работает и с любыми другими.

При запуске команды devspace init в каталоге с проектом вам предложат (в интерактивном режиме):

• выбрать рабочий Kubernetes-кластер,
• использовать имеющийся Dockerfile (или сгенерировать новый) для создания контейнера на его базе,
• выбрать репозиторий для хранения образов контейнеров и т.д.

После всех этих подготовительных действий можно начинать разработку, выполнив команду devspace dev. Она соберёт контейнер, загрузит его в репозиторий, выкатит deployment в кластер и запустит проброс портов и синхронизацию контейнера с локальным каталогом.

Опционально будет предложено перейти терминалом в контейнер. Отказываться не стоит, потому как в реальности контейнер стартует с командой sleep, а для реального тестирования приложение требуется запускать вручную.

Наконец, команда devspace deploy выкатывает приложение и связанную с ним инфраструктуру в кластер, после чего все начинает функционировать в боевом режиме.

Вся конфигурация проекта хранится в файле devspace.yaml. Помимо настроек окружения для разработки в нем же можно найти описание инфраструктуры, похожее на стандартные манифесты Kubernetes, только сильно упрощенные.

Архитектура и основные этапы работы с DevSpace

Кроме того, в проект легко добавить предопределенный компонент (например, СУБД MySQL) или Helm-чарт. Подробнее читайте в документации — она несложная.

Skaffold

• Сайт; GitHub.
• Краткая статистика GH: 7423 звезды, 4173 коммита, 136 контрибьюторов.
• Язык: Go.
• Лицензия: Apache License 2.0.

Эта утилита от Google претендует на то, чтобы покрыть все потребности разработчика, чей код так или иначе будет запускаться в кластере Kubernetes. Начать пользоваться им не так просто, как devspace'ом: никакой интерактивности, определения языка и автосоздания Dockerfile здесь вам не предложат.

Впрочем, если это не пугает — вот что позволяет делать Skaffold:

• Отслеживать изменения исходного кода.
• Синхронизировать его с контейнером pod'а, если он не требует сборки.
• Собирать контейнеры с кодом, если ЯП — интерпретируемый, или же компилировать артефакты и упаковывать их в контейнеры.
• Получившиеся образы автоматически проверять с помощью container-structure-test.
• Тегировать и загружать образы в Docker Registry.
• Разворачивать приложение в кластере, используя kubectl, Helm или kustomize.
• Делать проброс портов.
• Отлаживать приложения, написанные на Java, Node.js, Python.

Workflow в различных вариациях декларативно описывается в файле skaffold.yaml. Для проекта можно также определить несколько профилей, в которых частично или полностью изменять стадии сборки и деплоя. Например, для разработки указать удобный для разработчика базовый образ, а для staging и production — минимальный (+ использовать securityContext у контейнеров или же переопределить кластер, в котором приложение будет развернуто).

Сборка Docker-контейнеров может осуществляться локально или удаленно: в Google Cloud Build или в кластере с помощью Kaniko. Также поддерживаются Bazel и Jib Maven/Gradle. Для тегирования Skaffold поддерживает множество стратегий: по git commit hash, дате/времени, sha256-сумме исходников и т.п.

Отдельно стоит отметить возможность тестирования контейнеров. Уже упомянутый фреймворк container-structure-test предлагает следующие методы проверки:

• Выполнение команд в контексте контейнера с отслеживанием exit-статусов и проверкой текстового «выхлопа» команды.
• Проверка наличия файлов в контейнере и соответствия атрибутов указанным.
• Контроль содержимого файлов по регулярным выражениям.
• Сверка метаданных образа (ENV, ENTRYPOINT, VOLUMES и т.п.).
• Проверка совместимости лицензий.

Синхронизация файлов с контейнером осуществляется не самым оптимальным способом: Skaffold просто создает архив с исходниками, копирует его и распаковывает в контейнере (должен быть установлен tar). Поэтому, если ваша основная задача — в синхронизации кода, лучше посмотреть в сторону специализированного решения (ksync).

Основные этапы работы Skaffold

В целом же инструмент не позволяет абстрагироваться от Kubernetes-манифестов и не имеет какой-либо интерактивности, поэтому может показаться сложным для освоения. Но в этом же и его плюс — большая свобода действий.

Garden

• Сайт; GitHub.
• Краткая статистика GH: 1063 звезды, 1927 коммитов, 17 контрибьюторов.
• Язык: TypeScript (планируется разбить проект на несколько компонентов, некоторые из которых будут на Go, а также сделать SDK для создания дополнений на TypeScript/JavaScript и Go).
• Лицензия: Apache License 2.0.

Как и Skaffold, Garden нацелен на автоматизацию процессов доставки кода приложения в K8s-кластер. Для этого сперва необходимо описать структуру проекта в YAML-файле, после чего запустить команду garden dev. Она сделает всю магию:

• Соберет контейнеры с различными частями проекта.
• Проведет интеграционные и unit-тесты, если таковые были описаны.
• Выкатит все компоненты проекта в кластер.
• В случае изменения исходного кода — заново запустит весь пайплайн.

Основной упор при использовании этого инструмента делается на совместное использование удаленного кластера командой разработчиков. В этом случае, если какие-то стадии сборки и тестирования уже были сделаны, это значительно ускорит весь процесс, поскольку Garden сможет использовать закэшированные результаты.

Модулем проекта может быть контейнер, Maven-контейнер, Helm-чарт, манифест для kubectl apply или даже OpenFaaS-функция. Причем любой из модулей можно подтянуть из удаленного Git-репозитория. Модуль может определять (а может и нет) сервисы, задачи и тесты. Сервисы и задачи могут иметь зависимости, благодаря чему можно определить последовательность деплоя того или иного сервиса, упорядочить запуск заданий и тестов.

Garden предоставляет пользователю красивый dashboard (пока в экспериментальном состоянии), в котором отображается граф проекта: компоненты, последовательность сборки, выполнения задач и тестов, их связи и зависимости. Прямо в браузере можно просмотреть и логи всех компонентов проекта, проверить, что выдает тот или иной компонент по HTTP (если, конечно, для него объявлен ресурс ingress).

Панель для Garden

Есть у этого инструмента и режим hot-reload, который просто синхронизирует изменения скриптов с контейнером в кластере, многократно ускоряя процесс отладки приложения. У Garden хорошая документация и неплохой набор примеров, позволяющих быстро освоиться и начать пользоваться. Кстати, совсем недавно мы публиковали перевод статьи от его авторов.

Заключение

Разумеется, данным списком инструментарий для разработки и отладки приложений в Kubernetes не ограничивается. Существует еще много весьма полезных и практичных утилит, достойных если не отдельной статьи, то — как минимум — упоминания. Расскажите, чем пользуетесь вы, с какими проблемами вам доводилось сталкиваться и как вы их решали!

P.S.

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

• «werf — наш инструмент для CI/CD в Kubernetes (обзор и видео доклада)»;
• «Garden v0.10.0: Вашему ноутбуку не нужен Kubernetes»;
• «Kubernetes tips & tricks: о локальной разработке и Telepresence»;
• «Плагин kubectl-debug для отладки в pod'ах Kubernetes».

Автор: Vadim Lazovskiy

Источник