🥇Устройството на Helm и неговите подводни камъни

Концепция грузового судна Typhon, Антон Свенепоел

Меня зовут Дмитрий Сугробов, я разработчик в «Леруа Мерлен». В этой статье расскажу, зачем нужен Helm, как он упрощает работу с Kubernetes, что изменилось в третьей версии и как с его помощью обновлять приложения в продакшене без простоя.

Это конспект выступления на конференции @Kubernetes Conference от Mail.ru Cloud Solutions — если не хотите читать, смотрите видео.

Почему мы используем Kubernetes в продакшене

«Леруа Мерлен» — лидер на рынке DIY-ритейла в России и Европе. В нашей компании более ста разработчиков, 33 000 внутренних сотрудников и огромное количество людей, посещающих гипермаркеты и сайт. Чтобы сделать всех их счастливыми, мы решили придерживаться стандартных подходов в индустрии. Разрабатывать новые приложения, используя микросервисную архитектуру; для изоляции окружений и правильной доставки использовать контейнеры; а для оркестрации использовать Kubernetes. Цена использования оркестраторов стремительно снижается: на рынке растет количество инженеров, владеющих этой технологией, появляются провайдеры, предлагающие Kubernetes как сервис.

Всё, что делает Kubernetes, конечно, можно сделать другими способами, например, обмазав скриптами какой-нибудь Jenkins и docker-compose, но зачем усложнять жизнь, если есть готовое и надежное решение? Поэтому мы пришли к Kubernetes и уже год его используем в продакшене. Сейчас у нас двадцать четыре кластера Kubernetes, самый старый из которых больше года, в нем порядка двухсот подов.

Проклятие большого количества YAML-файлов в Kubernetes

Для запуска микросervиса в Kubernetes создадим по меньшей мере пять YAML-файлов: для Deployment, Service, Ingress, ConfigMap, Secrets — и отправим в кластер. Для следующего приложения напишем тот же набор файлов, для третьего — еще один и так далее. Умножим количество документов на количество окружений, и уже получим сотни файлов, и это ещё не учитывая динамические окружения.

Адам Рис, основной поддерживатель Helm, ввел понятие «Цикл разработки в Kubernetes», который выглядит так:

Copy YAML — копировать YAML-файл.
Paste YAML — вставить его.
Fix Indents — починить отступы.
Repeat — повторить заново.

Вариант рабочий, но приходится много раз копировать YAML-файлы. Чтобы изменить этот цикл, и придумали Helm.

Что такое Helm

Во-первых, Helm — мениджър на пакети, който помага да се намерят и инсталират необходимите програми. За инсталиране, например, на MongoDB не е нужно да се влиза в официалния сайт и да се свалят бинарни файлове, достатъчно е да изпълните командата helm install stable/mongodb.

На второ място, Helm — шаблонизатор, който помага да се параметризират файловете. Нека се върнем на ситуацията с YAML файловете в Kubernetes. По-лесно е да се напише същият YAML файл, да се добавят някои плейсхолдери, в които Helm да подстави стойности. Тоест вместо голям набор от YAML файлове ще имаме набор от темплейти (шаблони), в които в подходящия момент ще се подставят нужните стойности.

На трето място, Helm — експерт по разгръщане. С негова помощ можете да инсталирате, откатите и обновите приложения. Нека разберем как да го направим.

Как да използваме Helm за деплой на собствени приложения

Ще инсталираме клиента Helm на компютъра, следвайки официалната инструкции. След това ще създадем набор от YAML файлове. Вместо да зададем конкретни стойности, ще оставим плейсхолдери, които в бъдеще Helm ще запълни с информация. Наборът от такива файлове се нарича Helm чарт. В клиентската конзола Helm може да се изпрати по три начина:

да посочите папката с шаблоните;
да опаковате в .tar архив и да посочите него;
да поставите шаблона в отдалечен репозиторий и да добавите връзка към репозитория в клиента Helm.

Също така е необходим файл със стойности — values.yaml. Данните от него ще се подставят в шаблона. Нека създадем и него.

Във втората версия на Helm има допълнително сървърно приложение — Tiller. То остава извън Kubernetes и изчаква заявки от клиента Helm, а при повикване подставя нужните стойности в шаблона и ги изпраща в Kubernetes.

Helm 3 е по-прост: вместо обработка на шаблони на сървъра, информацията сега се обработва изцяло от страната на клиента Helm и се изпраща директно в Kubernetes API. Това опростяване повишава сигурността на кластерите и улеснява схемата на разгръщането.

Как всичко това работи

Изпълняваме командата helm install. Ще посочим името на релиза на приложението, ще дадем пътя до values.yaml. В края ще посочим репозитория, в който се намира чартът и името на чарта. В примера това са «lmru» и «bestchart» съответно.

helm install --name bestapp --values values.yaml lmru/bestchart

Изпълнението на командата е възможно само веднъж, при повторно изпълнение вместо инсталиране трябва да се използва upgrade. За удобство вместо две команди може да се изпълни командата upgrade с допълнителен ключ --install. При първото изпълнение Helm ще изпрати команда за инсталиране на релиза, а впоследствие ще го актуализира.

helm upgrade --install bestapp --values values.yaml lmru/bestchart

Капаните на разполагането на нови версии на приложението с Helm

В този момент от историята играя с публиката в „Кой иска да стане милионер“, и изясняваме как да накараме Helm да обнови версията на приложението. Гледайте видеото.

Когато изучавах работата на Helm, ме изненада странното поведение при опити за обновление на версиите на стартираните приложения. Кодът на приложението е актуализиран, новият образ е качен в docker registry, командата за разполагане е изпратена – и нищо не се случи. По-долу ще видите няколко не чак толкова удачни начина за обновление на приложения. Изучавайки всеки от тях по-подробно, започваш да разбираш вътрешната работа на инструмента и причините за такова неочевидно поведение.

Метод 1. Да не се променя информацията от последното стартиране

Както гласи официалният сайт Helm, „Kubernetes чартовете могат да бъдат големи и сложни, затова Helm се стреми да не променя нищо без причина“. Следователно, ако актуализирате latest версията на образа на приложението в docker registry и изпълните командата helm upgrade, нищо не ще се случи. Helm ще мисли, че нищо не е променено и няма да изпрати команда за обновление на приложението в Kubernetes.

Тук и по-нататък тагът latest е показан единствено като пример. При указване на този таг Kubernetes ще изтегля образа от docker registry всеки път, независимо от параметъра imagePullPolicy. Използването на latest в продукцията не се препоръчва и води до странични ефекти.

Метод 2. Актуализирайте LABEL в образа

Както е написано в същия документацията, „Helm ще обнови приложението, само ако то е променено след последния релиз“. Логичният вариант за това е актуализиране на етикета LABEL в самия docker образ. Въпреки това, Helm не надниква в образите на приложенията и не знае за никакви промени в тях. Следователно, при актуализация на етикетите в образа Helm няма да разбере за тях, и командата за обновление на приложението в Kubernetes няма да бъде изпратена.

Метод 3. Използвайте ключ --force

Нека да се обърнем към ръководствата и да потърсим нужния ключ. Най-подходящ по смисъл е ключът --force. Въпреки говорещото име, поведението се различава от очакваното. Вместо принудително обновление на приложението, реалната му цел е възстановяване на релиза в статусFAILED. Ако не се използва този ключ, трябва последователно да се изпълнят командите helm delete && helm install --replace. Вместо това се предлага да се използва ключът --force, който автоматизира последователното изпълнение на тези команди. Повече информация в този пулл-реквест.. За да накарате Helm все пак да обнови версията на приложението, за съжаление, този ключ няма да е подходящ.

Метод 4. Промяна на labels директно в Kubernetes.

Актуализация на label директно в кластера с помощта на командата kubectl edit — лоша идея. Тази операция ще доведе до несъответствие между информацията в работещото приложение и това, което първоначално е било изпратено за деплой. Поведението на Helm при деплой в този случай е различно от версията му: Helm 2 няма да направи нищо, докато Helm 3 ще деплойне нова версия на приложението. За да разберете причината, трябва да разберете как работи Helm.

Как функционира Helm.

За да определи дали приложението се е променило от последния релиз, Helm може да използва:

работещото приложение в Kubernetes;
новия values.yaml и актуалния чарт;
вътрешна информация на Helm за релизите.

За най-любопитните: къде Helm съхранява вътрешната информация за релизите?Изпълнявайки командата helm history, получаваме цялата информация за версиите, инсталирани с помощта на Helm.

Има още подробна информация за изпратените шаблони и стойности. Можем да я изискаме:

Във втората версия на Helm тази информация се съхранява в същия namespace, където работи Tiller (по подразбиране — kube-system), в ConfigMap, обозначен с етикет "OWNER=TILLER":

С настъпването на третата версия на Helm информацията беше преместена в секрети, при което в същия namespace, в който е инсталирано приложението. Благодарение на това стана възможно стартирането едновременно на множество приложения в различни namespaces с еднакво име на релиз. Във втората версия това беше голяма болка, когато namespaces са изолирани, но могат да влияят един на друг.

Вторият Helm, когато се опитва да разбере дали е необходимо обновление, използва само два източника на информация: това, което му е предоставено в момента, и вътрешната информация за релизите, която се съхранява в ConfigMap.

Третият Helm използва стратегия three-way merge: освен информацията, взима предвид и приложението, което в момента работи в Kubernetes.

Поради тази причина старата версия на Helm няма да направи нищо, тъй като не отчита информацията за приложението в клъстера, докато Helm 3 ще получи измененията и ще изпрати новото приложение за разгръщане.

Метод 5. Използване на ключа —recreate-pods

С помощта на ключа --recreate-pods можем да постигнем това, което първоначално се е планирало с ключа --force. Контейнерите ще бъдат рестартирани и, съгласно политиката imagePullPolicy: Always за етикета latest (за това в бележката по-горе), Kubernetes ще изтегли и стартира новата версия на образа. Това ще се случи не по най-добрия начин: без да отчита StrategyType на разгръщането, ще изключи рязко всички стари инстанции на приложението и ще започне да стартира новите. По време на рестартирането системата няма да работи, потребителите ще страдат.

В самия Kubernetes подобен проблем също съществуваше дълго време. И ето, след 4 години след откритие Проблем, проблемът беше решен и от версия 1.15 на Kubernetes се появи възможността за rolling-restart на подовете.

Helm просто изключва всички приложения и стартира нови контейнери до тях. В продукционна среда не трябва да се прави така, за да не се предизвика простои на приложението. Такова действие е нужно само за нуждите на разработката, може да се изпълнява само в stage-окружения.

Как да обновим версията на приложението с помощта на Helm?

Ще променим стойностите, изпращани до Helm. Обикновено това са стойности, които се подставят на мястото на етикета на образа. В случая с latest, който се използва често за непродуктивни среди, изменяемата информация е анотация, която за самия Kubernetes е безполезна, а за Helm ще бъде сигнал за необходимостта от обновление на приложението. Варианти за попълване на стойността на анотацията:

Случайна стойност с помощта на стандартната функция — {{ randAlphaNum 6 }}.
Има нюанс: след всяко разгръщане, използвайки чарт с такава променлива, стойността на анотацията ще бъде уникална, и Helm ще предполага, че има промени. Получава се, че винаги ще рестартираме приложението, дори и да не сме променили версията му. Това не е критично, тъй като няма да имаме простои, но все пак е неприятно.
Да вставим текущата дата и час — {{ .Release.Date }}.
Вариантът наподобява случайна стойност с постоянно уникална променлива.
По-правилният начин е да се използва контролнни суми. Това е SHA на образа или SHA на последния комит в git — {{ .Values.sha }}.
Трябва да се изчислят и изпратят на Helm клиента от повикващата страна, например в Jenkins. Ако приложението се е променило, контролната сума също ще се променя. Следователно, Helm ще актуализира приложението само когато е необходимо.

Да обобщим нашите опити

Helm прави промените по най-малко инвазивния начин, така че всяка промяна на ниво образ на приложение в Docker Registry няма да доведе до актуализация: след изпълнение на командата няма да се случи нищо.
Ключ --force се използва за възстановяване на проблемни релизи и не е свързано с принудителното обновление.
Ключ --recreate-pods принудително ще обнови приложенията, но ще го направи по вандалски начин: рязко ще изключи всички контейнери. От това ще пострадат потребителите, на продукция не трябва да се прави така.
Не трябва да внасяте директни промени в кластера Kubernetes с командата, kubectl edit защото ще нарушим консистентността, а поведението ще се различава в зависимост от версията на Helm.
С излизането на новата версия на Helm се появиха много нюанси. Въпросите в репозитория Helm са описани с разбираем език и ще помогнат да разберете детайлите.
Добавянето на променлива анотация в чарт ще го направи по-гъвкав. Това ще позволи правилното разгръщане на приложението без престой.

Мисъл от вида „мир във всемир“, работеща във всички сфери на живота: чета инструкцията преди употреба, а не след. Само с пълната информация можете да изградите надеждни системи и да направите потребителите щастливи.

Други свързани линкове:

Тази презентация за първи път прозвуча на @Kubernetes Conference от Mail.ru Cloud Solutions. Вижте видеото други изказвания и се абонирайте за анонсите на събитията в Telegram Около Kubernetes в Mail.ru Group.

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