🥇Інструменти для розробників додатків, які запускаються в 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.

Інструмент простий і ефективний, так що може стати у нагоді кожному розробнику. Докладніше про нього ми писали в окремій статті.

Телеприсутність

суть: перенеси додаток на свій комп'ютер. Розробляй та налагоджуй локально.
Сайт; 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.

сквош

суть: налагоджуй процеси прямо в кластері.
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-чарт. Детальніше читайте у документації - Вона нескладна.

лісок

Сайт; 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-маніфестів і не має будь-якої інтерактивності, тому може здатися складним для освоєння. Але в цьому ж і його плюс велика свобода дій.

сад

Сайт; 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 не обмежується. Існує ще багато дуже корисних і практичних утиліт, гідних якщо не окремої статті, то як мінімум згадки. Розкажіть, чим ви користуєтеся, з якими проблемами вам доводилося стикатися і як ви їх вирішували!

PS

Читайте також у нашому блозі:

Джерело: habr.com

Інструменти для розробників додатків, які запускаються в Kubernetes