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

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

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

Това е резюме, вдъхновено от представяне на конференция @Kubernetes Conference by Mail.ru Cloud Solutions — ако не искате да четете, гледайте видеото.

Защо използваме Kubernetes в продукцията

„Леруа Мерлен“ е лидер на пазара на DIY ритейл в Русия и Европа. В нашата компания работят над сто разработчици, 33 000 вътрешни служители и огромен брой хора, посещаващи хипермаркетите и сайта. За да направим всички тях щастливи, решихме да се придържаме към стандартни подходи в индустрията. Разработваме нови приложения, използвайки микросервизна архитектура; за изолация на околната среда и правилно разпространение използваме контейнери; а за оркестрация — Kubernetes. Цената на използването на оркестратори стремително пада: на пазара се увеличава броят на инженерите, които владеят технологията, появяват се доставчици, предлагащи Kubernetes като услуга.

Всичко, което прави Kubernetes, разбира се, може да се направи и с други начини, например, с помощта на скриптове на Jenkins и docker-compose, но защо да усложняваме живота, ако имаме готово и надеждно решение? Затова се спряхме на Kubernetes и вече го използваме в продукцията от година. В момента имаме двадесет и четири клъстера Kubernetes, най-старият от тях е на повече от година и има около двеста пода.

Проклятието на многото YAML-файлове в Kubernetes

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

Адам Рийз, основен поддържащ Helm, въведе понятието „Цикъл на разработка в Kubernetes“, който изглежда така:

Копиране на YAML — копирайте YAML файла.
Вмъкване на YAML — вмъкнете го.
Поправяне на отстъпи — коригирайте отстъпите.
Повторете — повторете отново.

Вариантът е работещ, но трябва много пъти да копираме YAML файлове. За да променим този цикъл, е създаден Helm.

Какво е Helm

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

На второ място, Helm — шаблонизатор, помага за параметризиране на файловете. Нека се върнем на ситуацията с YAML файловете в Kubernetes. По-лесно е да напишеш същия YAML файл, да добавиш някои placeholder-ы, в които 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

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

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

Подводните камъни при деплойване на нови версии на приложението с Helm

На това място в разказа играя с залата в "Кой иска да стане милионер?", и разбираем как да накараме Helm да обнови версията на приложението. Гледайте видеото.

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

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

Както се казва официален сайт Helm, "Kubernetes чартовете могат да бъдат големи и сложни, затова Helm се опитва да не прави излишни промени". Следователно, ако актуализирате последната версия на образа на приложението в 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 тази информация се намира в същия неймспейс, където е стартиран Tiller (по подразбиране - kube-system), в ConfigMap, означен с етикет «OWNER=TILLER»:

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

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

Третият Helm използва стратегия за тристранно сливане: в допълнение към информацията, взема предвид и приложението, което работи в момента в 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