🥇Инструменти за разработчици на приложения, които се стартират в Kubernetes

Съвременният подход към експлоатацията решава множество належащи проблеми на бизнеса. Контейнерите и оркестраторите позволяват лесно мащабиране на проекти с всякаква сложност, опростяват релизите на нови версии, правят ги по-надеждни, но заедно с това създават и допълнителни проблеми за разработчиците. Програмистът, на първо място, се интересува от своя код: архитектурата, качеството, производителността, елегантността, — а не как той ще работи в Kubernetes и как да го тества и отстранява след въвеждането дори на минимални поправки. Поради това е напълно естествено, че активно се развиват инструменти за Kubernetes, които помагат за решаване на проблеми дори на най-„архаичните“ разработчици и им позволяват да се концентрират върху важните аспекти.

В този преглед е представена кратка информация за някои инструменти, които опростяват живота на програмистите, чийто код работи в pod'ите на Kubernetes клъстера.

Прости помощници

Kubectl-debug

Същност: добави своя контейнер в Pod и виж какво се случва в него.
GitHub.
Кратка статистика GH: 715 звезди, 54 комита, 9 транспортни сътрудници.
Език: Go.
Лицензия: Apache License 2.0.

Този плъгин за kubectl позволява да се създаде допълнителен контейнер вътре в интересуващия pod, който ще споделя именната пространство на процесите с останалите контейнери. В него може да се извършва отстраняване на грешки в работата на 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-a на файловата система. Тази грешка е забелязана при работа с големи папки — с много вложени файлове и директории. Ние създадохме съответстваща задача в проекта 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. Тя ще събере контейнера, ще го зареди в репозитория, ще приложи разгръщането в кластер и ще стартира пренос на портове и синхронизация на контейнера с локалната директория.

По желание ще бъде предложено да преминете в контейнера с терминала. Не си струва да отказвате, тъй като в действителност контейнерът стартира с команда 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.

Работният процес в различни варианти се описва декларативно във файла 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 не е изчерпателен. Има много полезни и практични утилити, които заслужават, ако не отделен материал, то поне — споменаване. Разкажете ни какви инструменти използвате, с какви проблеми сте се сблъсквали и как сте ги решили!