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

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

Казвам се Дмитрий Сугробов, разработчик съм в Leroy Merlin. В статията ще ви разкажа защо е необходим Helm, как опростява работата с Kubernetes, какво се е променило в третата версия и как да го използвате за актуализиране на приложения в производство без престой.

Това е резюме, базирано на реч на конференция Конференция @Kubernetes by Облачни решения на Mail.ru Ако не искате да четете, гледайте видеото.

Защо използваме Kubernetes в производството

Leroy Merlin е лидер на пазара на дребно за DIY в Русия и Европа. Нашата компания има повече от сто разработчици, 33 000 вътрешни служители и огромен брой хора, посещаващи хипермаркетите и сайта. За да ги направим щастливи, решихме да се придържаме към индустриалния стандарт. Разработвайте нови приложения, използвайки архитектура на микросервизи; използвайте контейнери за изолиране на среди и правилно доставяне; и за оркестрация използвайте Kubernetes. Цената на използването на оркестратори бързо става по-евтина: броят на инженерите, които притежават технологията, расте на пазара и се появяват доставчици, предлагащи Kubernetes като услуга.

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

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

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

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

Копиране на YAML - копиране на YAML файл.
Поставете YAML - поставете го.
Fix Indents - коригиране на отстъпи.
Повторете - повторете отново.

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

Какво е кормило

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

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

Трето, Хелм - съветник за внедряване. С него можете да инсталирате, връщате назад и актуализирате приложения. Нека да видим как да го направим.

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

Инсталирайте клиента Helm на компютъра, следвайки официалния Directions. След това ще създадем набор от 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

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

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

Метод 1. Не променяйте информацията от последното изпълнение

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

По-нататък последният етикет е показан само като пример. Когато този етикет е посочен, Kubernetes ще изтегля изображението от регистъра на докерите всеки път, независимо от параметъра imagePullPolicy. Използването на най-новите в производството е нежелателно и причинява странични ефекти.

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

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

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

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

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

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

Как работи Helm

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

работещо приложение в Kubernetes;
нови стойности.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: Винаги за най-новия етикет (повече за това в бележката под линия по-горе), Kubernetes ще изтегли и стартира новата версия на изображението. Това няма да бъде направено по най-добрия начин: без да се вземе предвид StrategyType на внедряването, то внезапно ще изключи всички стари екземпляри на приложения и ще стартира нови. По време на рестартирането системата няма да работи, потребителите ще страдат.

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

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

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

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

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

Нека обобщим нашите усилия

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

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

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

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

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

Устройството Helm и неговите капани