Моето име е Дмитриј Сугробов, јас сум програмер во Лерој Мерлин. Во оваа статија ќе ви кажам зошто е потребен Helm, како ја поедноставува работата со Kubernetes, што се смени во третата верзија и како да го користите за ажурирање на апликациите во производството без прекини.
Ова е резиме засновано на говор на конференција by - ако не сакате да читате, погледнете го видеото.
Зошто користиме Kubernetes во производството
Лерој Мерлин е лидер на малопродажниот пазар DIY во Русија и Европа. Нашата компанија има повеќе од сто програмери, 33 внатрешни вработени и огромен број луѓе кои ги посетуваат хипермаркетите и веб-страницата. Со цел да ги направиме сите среќни, решивме да ги следиме индустриските стандардни пристапи. Развивање на нови апликации користејќи микросервис архитектура; користете контејнери за да ги изолирате околините и да обезбедите правилна испорака; и користете Kubernetes за оркестрација. Цената за користење на оркестратори брзо станува поевтина: бројот на инженери умешни во технологијата расте на пазарот, а се појавуваат провајдери кои нудат Kubernetes како услуга.
Сè што прави Кубернетес, се разбира, може да се направи на други начини, на пример, со покривање на некои Џенкинс и докер-композирање со скрипти, но зошто да се комплицира животот ако постои готово и сигурно решение? Затоа дојдовме во Кубернетес и го користиме во производство веќе една година. Во моментов имаме дваесет и четири кластери Кубернетес, од кои најстариот е стар повеќе од една година, со околу двесте мешунки.
Проклетството на големите YAML датотеки во Кубернетес
За да започнеме микросервис во Kubernetes, ќе создадеме најмалку пет YAML-датотеки: за Deployment, Service, Ingress, ConfigMap, Secrets - и ќе ги испратиме во кластерот. За следната апликација ќе го напишеме истиот пакет џамови, со третата ќе напишеме уште еден итн. Ако го помножиме бројот на документи со бројот на околини, веќе ќе добиеме стотици датотеки, а тоа сè уште не ги зема предвид динамичните средини.
Адам Рис, главен одржувач на Helm, го претстави концептот на "“, што изгледа вака:
- Копирајте YAML - копирајте датотека YAML.
- Вметнете YAML - ставете го.
- Поправете вовлекувања - поправете ги вовлекувањата.
- Повторете - повторете повторно.
Опцијата работи, но мора да ги копирате датотеките YAML многу пати. За да се промени овој циклус, беше измислен Helm.
Што е Хелм
Прво, Хелм - менаџер на пакети, што ви помага да ги најдете и инсталирате програмите што ви се потребни. За да инсталирате, на пример, MongoDB, не треба да одите на официјалната веб-страница и да преземате бинарни датотеки, само извршете ја командата helm install stable/mongodb.
Второ, Хелм - мотор на шаблон, помага да се параметризираат датотеките. Да се вратиме на ситуацијата со YAML-датотеките во Kubernetes. Полесно е да се напише истата YAML-датотека, да се додадат некои местенки во неа, во кои Helm ќе ги замени вредностите. Односно, наместо голем сет на скелиња, ќе има збир на шаблони во кои ќе се заменат бараните вредности во вистинско време.
Трето, Хелм - господар на распоредување. Со него можете да инсталирате, вратите и ажурирате апликации. Ајде да разбереме како да го направиме ова.
Како да го користите Helm за распоредување на вашите сопствени апликации
Ајде да го инсталираме клиентот Helm на вашиот компјутер, следејќи го официјалното . Следно, ќе создадеме сет од датотеки YAML. Наместо да специфицираме специфични вредности, ќе оставиме поставки, кои Helm ќе ги пополни со информации во иднина. Збир од такви датотеки се нарекува дијаграм на Helm. Може да се испрати до клиентот на конзолата на Helm на три начини:
- означете папка со шаблони;
- спакувај ја архивата во катран и посочи кон неа;
- ставете го шаблонот во оддалечено складиште и додајте врска до складиштето во клиентот Helm.
Потребна ви е и датотека со вредности - values.yaml. Податоците од таму ќе бидат вметнати во шаблонот. Ајде да го создадеме и тоа.
Втората верзија на Helm има дополнителна серверска апликација - Tiller. Виси надвор од Kubernetes и чека барања од клиентот Helm и кога ќе се повика, ги заменува бараните вредности во шаблонот и го испраќа до Kubernetes.
Helm 3 е поедноставен: наместо да се обработуваат шаблони на серверот, информациите сега се обработуваат целосно на страната на клиентот на Helm и се испраќаат директно до Kubernetes API. Ова поедноставување ја подобрува безбедноста на кластерот и ја олеснува шемата за воведување.
Како функционира сето тоа
Извршете ја командата helm install. Да го наведеме името на изданието на апликацијата и да ја дадеме патеката до вредностите.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, бев изненаден од чудно однесување кога се обидував да ги ажурирам верзиите на апликациите што работат. Го ажурирав кодот на апликацијата, поставив нова слика во регистарот на Docker, ја испратив командата за распоредување - и ништо не се случи. Подолу се дадени неколку не сосема успешни начини за ажурирање на апликациите. Проучувајќи го секој од нив подетално, почнувате да ја разбирате внатрешната структура на инструментот и причините за ова не очигледно однесување.
Метод 1. Не менувајте информации од последното лансирање
Како што пишува Хелм, „Табелите на Кубернетс можат да бидат големи и сложени, па Хелм се обидува да не допира ништо премногу“. Затоа, ако ја ажурирате најновата верзија на сликата на апликацијата во регистарот на докер и ја извршите командата helm upgrade, тогаш ништо нема да се случи. Хелм ќе помисли дека ништо не е променето и нема потреба да испраќа команда до Кубернетес за ажурирање на апликацијата.
Овде и подолу, најновата ознака е прикажана само како пример. Кога ќе ја наведете оваа ознака, Kubernetes ќе ја презема сликата од докерскиот регистар секој пат, без оглед на параметарот imagePullPolicy. Користењето на најновото производство е непожелно и предизвикува несакани ефекти.
Метод 2. Ажурирајте го LABEL на сликата
Како што е напишано во истото , „Хелм ќе ја ажурира апликацијата само ако е променета од последното издание“. Се чини дека логична опција за ова е ажурирањето на LABEL во самата слика на докерот. Сепак, Хелм не ги разгледува сликите на апликациите и нема идеја за какви било промени на нив. Соодветно на тоа, при ажурирање на етикетите на сликата, Helm нема да знае за нив, а командата за ажурирање на апликацијата нема да биде испратена до Kubernetes.
Метод 3: Користете клуч --force
Ајде да се свртиме кон прирачниците и да го побараме потребниот клуч. Клучот има најмногу смисла --force. И покрај очигледното име, однесувањето е различно од очекуваното. Наместо принудно ажурирање на апликацијата, нејзината вистинска цел е да го врати изданието што е во статус НЕСПЕШЕН. Ако не го користите овој клуч, треба да ги извршувате командите последователно helm delete && helm install --replace. Наместо тоа, се предлага да се користи клучот --force, што го автоматизира секвенцијалното извршување на овие команди. Повеќе информации во ова . За да му кажете на Хелм да ја ажурира верзијата на апликацијата, за жал, овој клуч нема да работи.
Метод 4. Променете ги етикетите директно во Kubernetes
Ажурирање на етикетата директно во кластерот со помош на командата kubectl edit - лоша идеја. Оваа акција ќе доведе до неусогласеност на информациите помеѓу апликацијата која работи и онаа што првично беше испратена за распоредување. Однесувањето на Helm за време на распоредувањето во овој случај се разликува од неговата верзија: Helm 2 нема да направи ништо, а Helm 3 ќе ја распореди новата верзија на апликацијата. За да разберете зошто, треба да разберете како функционира Хелм.
Како работи Helm?
За да утврди дали некоја апликација се променила од нејзиното последно издание, Helm може да користи:
- работи на апликација во Kubernetes;
- нови вредности.yaml и тековен графикон;
- Информации за внатрешното ослободување на Хелм.
За пољубопитни: каде Helm складира внатрешни информации за изданија?Со извршување на командата helm history, ќе ги добиеме сите информации за верзиите инсталирани со помош на Helm.
Има и детални информации за испратените шаблони и вредности. Можеме да го побараме:
Во втората верзија на Helm, оваа информација се наоѓа во истиот именски простор каде што работи Tiller (систем кубе по дифолт), во ConfigMap, означен со ознаката „OWNER=TILLER“:
Кога се појави третата верзија на Helm, информациите се префрлија во тајните и во истиот именски простор каде што работеше апликацијата. Благодарение на ова, стана возможно да се извршуваат неколку апликации истовремено во различни именски простори со исто име на изданието. Во втората верзија, тоа беше сериозна главоболка кога именските простори се изолирани, но можат да влијаат еден на друг.
Вториот Helm, кога се обидува да разбере дали е потребно ажурирање, користи само два извори на информации: она што му е обезбедено сега и внатрешните информации за изданијата, кои се наоѓаат во ConfigMap.
Третиот Helm користи тринасочна стратегија за спојување: покрај тие информации, ја зема предвид и апликацијата што работи во моментов во Kubernetes.
Поради оваа причина, старата верзија на Helm нема да направи ништо, бидејќи не ги зема предвид информациите за апликацијата во кластерот, но Helm 3 ќе ги прими промените и ќе ја испрати новата апликација на распоредување.
Метод 5. Користете го прекинувачот --recreate-pods
Со клуч --recreate-pods можете да го постигнете она што првично планиравте да го постигнете со клучот --force. Контејнерите ќе се рестартираат и, според политиката imagePullPolicy: Секогаш за најновата ознака (повеќе за ова во фуснотата погоре), Kubernetes ќе преземе и лансира нова верзија на сликата. Ова нема да се направи на најдобар начин: без да се земе предвид StrategyType of deployment, тој нагло ќе ги исклучи сите стари примероци на апликации и ќе започне да стартува нови. За време на рестартирањето, системот нема да работи, корисниците ќе страдаат.
Во самиот Кубернетес, сличен проблем, исто така, постоеше долго време. И сега, 4 години по отворањето , проблемот е поправен и почнувајќи од верзијата 1.15 на Kubernetes, се појавува можноста за превртување на подлоги.
Helm едноставно ги исклучува сите апликации и лансира нови контејнери во близина. Не можете да го направите ова во производството, за да не предизвикате прекин на апликацијата. Ова е потребно само за развојни потреби и може да се изведува само во сценски средини.
Како да ја ажурирате верзијата на апликацијата користејќи Helm?
Ќе ги промениме вредностите испратени до Helm. Вообичаено, ова се вредности што се заменуваат на местото на ознаката на сликата. Во случај на најновиот, кој често се користи за непродуктивни средини, променливата информација е прибелешка, што е бескорисна за самиот Kubernetes, а за Helm ќе делува како сигнал за потребата од ажурирање на апликацијата. Опции за пополнување на вредноста на прибелешката:
- Случајна вредност користејќи ја стандардната функција -
{{ randAlphaNum 6 }}.
Постои предупредување: по секое распоредување користејќи графикон со таква променлива, вредноста на прибелешката ќе биде единствена, а Хелм ќе претпостави дека има промени. Излегува дека секогаш ќе ја рестартираме апликацијата, дури и ако не сме ја смениле нејзината верзија. Ова не е критично, бидејќи нема да има прекини, но сепак е непријатно. - Залепете ја струјата датум и време -
{{ .Release.Date }}.
Варијантата е слична на случајна вредност со трајно единствена променлива. - Поправилен начин е да се користи контролни суми. Ова е SHA на сликата или SHA на последниот commit во git -
{{ .Values.sha }}.
Ќе треба да се избројат и да се испратат до клиентот на Helm на страната што повикува, на пример во Џенкинс. Ако апликацијата е променета, тогаш контролната сума ќе се промени. Затоа, Helm ќе ја ажурира апликацијата само кога е потребно.
Ајде да ги сумираме нашите обиди
- Helm прави промени на најмалку инвазивен начин, така што секоја промена на нивото на сликата на апликацијата во Docker Registry нема да резултира со ажурирање: ништо нема да се случи откако ќе се изврши командата.
- Клучни
--forceсе користи за враќање на проблематичните изданија и не е поврзан со принудни ажурирања. - Клучни
--recreate-podsнасилно ќе ги ажурира апликациите, но ќе го направи тоа на вандалски начин: нагло ќе ги исклучи сите контејнери. Корисниците ќе страдаат од ова; не треба да го правите ова во производството. - Директно направете промени во кластерот Kubernetes користејќи ја командата
kubectl editнемој: ќе ја нарушиме конзистентноста и однесувањето ќе се разликува во зависност од верзијата на Helm. - Со објавувањето на новата верзија на Helm, се појавија многу нијанси. Прашањата во складиштето на Helm се опишани на јасен јазик, тие ќе ви помогнат да ги разберете деталите.
- Додавањето на прибелешка што може да се уредува на графиконот ќе го направи пофлексибилен. Ова ќе ви овозможи правилно да ја отворите апликацијата, без прекини.
Мисла за „светски мир“ која делува во сите области на животот: прочитајте ги упатствата пред употреба, а не после. Само со целосни информации ќе може да се изградат сигурни системи и да се израдуваат корисниците.
Други поврзани врски:
Овој извештај првпат беше претставен на од Mail.ru Cloud Solutions. Погледнете други изведби и претплатете се на најавите за настани на Telegram .
Извор: www.habr.com