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

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

P.S.

Прочетете също в нашия блог:

Източник: habr.com