🥇Ang Helm device at ang mga pitfalls nito

Konsepto ng typhon freight hauler, Anton Swanepoel

Ang pangalan ko ay Dmitry Sugrobov, isa akong developer sa Leroy Merlin. Sa artikulong ito, sasabihin ko sa iyo kung bakit kailangan ang Helm, kung paano nito pinapasimple ang pagtatrabaho sa Kubernetes, kung ano ang nagbago sa ikatlong bersyon, at kung paano ito gamitin upang i-update ang mga application sa produksyon nang walang downtime.

Ito ay isang buod batay sa isang talumpati sa isang kumperensya @Kubernetes Conference by Mail.ru Cloud Solutions — kung ayaw mong magbasa, panoorin ang video.

Bakit ginagamit namin ang Kubernetes sa produksyon

Si Leroy Merlin ay isang lider sa DIY retail market sa Russia at Europe. Ang aming kumpanya ay may higit sa isang daang mga developer, 33 mga panloob na empleyado at isang malaking bilang ng mga tao na bumibisita sa mga hypermarket at sa website. Upang mapasaya silang lahat, nagpasya kaming sundin ang mga pamantayan sa industriya. Bumuo ng mga bagong application gamit ang microservice architecture; gumamit ng mga lalagyan upang ihiwalay ang mga kapaligiran at matiyak ang wastong paghahatid; at gamitin ang Kubernetes para sa orkestrasyon. Ang presyo ng paggamit ng mga orkestra ay mabilis na nagiging mas mura: ang bilang ng mga inhinyero na bihasa sa teknolohiya ay lumalaki sa merkado, at ang mga provider ay lumalabas na nag-aalok ng Kubernetes bilang isang serbisyo.

Ang lahat ng ginagawa ng Kubernetes, siyempre, ay maaaring gawin sa ibang mga paraan, halimbawa, sa pamamagitan ng pagsakop sa ilang Jenkins at docker-compose gamit ang mga script, ngunit bakit gawing kumplikado ang buhay kung may handa at maaasahang solusyon? Kaya naman pumunta kami sa Kubernetes at isang taon na naming ginagamit ito sa produksyon. Sa kasalukuyan, mayroon kaming dalawampu't apat na kumpol ng Kubernetes, ang pinakamatanda sa mga ito ay higit sa isang taong gulang, na may humigit-kumulang dalawang daang pod.

Ang sumpa ng malalaking YAML file sa Kubernetes

Para maglunsad ng microservice sa Kubernetes, gagawa kami ng hindi bababa sa limang YAML file: para sa Deployment, Service, Ingress, ConfigMap, Secrets - at ipadala ang mga ito sa cluster. Para sa susunod na aplikasyon ay isusulat namin ang parehong pakete ng mga jambs, kasama ang pangatlo magsusulat kami ng isa pa, at iba pa. Kung i-multiply natin ang bilang ng mga dokumento sa bilang ng mga environment, makakakuha na tayo ng daan-daang mga file, at hindi pa nito isinasaalang-alang ang mga dynamic na kapaligiran.

Ipinakilala ni Adam Reese, pangunahing tagapangasiwa ng Helm, ang konsepto ng "Siklo ng Pag-unlad sa Kubernetes", na ganito ang hitsura:

Kopyahin ang YAML - kopyahin ang isang YAML file.
Idikit ang YAML - idikit ito.
Ayusin ang mga indent - ayusin ang mga indent.
Ulitin - ulitin muli.

Gumagana ang opsyon, ngunit kailangan mong kopyahin ang mga YAML file nang maraming beses. Upang baguhin ang cycle na ito, naimbento ang Helm.

Ano ang Helm

Una, Helm - manager ng package, na tumutulong sa iyong mahanap at mai-install ang mga program na kailangan mo. Upang mai-install, halimbawa, MongoDB, hindi mo kailangang pumunta sa opisyal na website at mag-download ng mga binary, patakbuhin lamang ang command helm install stable/mongodb.

Pangalawa, Helm - template engine, tumutulong sa pag-parameter ng mga file. Bumalik tayo sa sitwasyon sa mga YAML file sa Kubernetes. Mas madaling isulat ang parehong YAML file, magdagdag ng ilang mga placeholder dito, kung saan papalitan ng Helm ang mga halaga. Iyon ay, sa halip na isang malaking hanay ng mga scaffold, magkakaroon ng isang hanay ng mga template kung saan ang mga kinakailangang halaga ay papalitan sa tamang oras.

Pangatlo, Helm - deployment master. Gamit ito maaari kang mag-install, mag-rollback at mag-update ng mga application. Alamin natin kung paano ito gagawin.

Paano gamitin ang Helm para i-deploy ang sarili mong mga application

I-install natin ang Helm client sa iyong computer, kasunod ng opisyal tagubilin. Susunod, gagawa kami ng set ng mga YAML file. Sa halip na tukuyin ang mga partikular na halaga, mag-iiwan kami ng mga placeholder, na pupunuin ng Helm ng impormasyon sa hinaharap. Ang isang set ng naturang mga file ay tinatawag na Helm chart. Maaari itong ipadala sa Helm console client sa tatlong paraan:

ipahiwatig ang isang folder na may mga template;
i-pack ang archive sa isang .tar at ituro ito;
ilagay ang template sa isang remote na repository at magdagdag ng link sa repository sa Helm client.

Kailangan mo rin ng file na may mga value - values.yaml. Ang data mula doon ay ipapasok sa template. Gawin din natin ito.

Ang pangalawang bersyon ng Helm ay may karagdagang server application - Tiller. Nag-hang ito sa labas ng Kubernetes at naghihintay ng mga kahilingan mula sa Helm client, at kapag tinawag, pinapalitan ang mga kinakailangang value sa template at ipinapadala ito sa Kubernetes.

Mas simple ang Helm 3: sa halip na magproseso ng mga template sa server, ang impormasyon ay ganap na ngayong pinoproseso sa panig ng Helm client at direktang ipinadala sa Kubernetes API. Pinapabuti ng pagpapasimpleng ito ang seguridad ng cluster at pinapadali ang scheme ng paglulunsad.

Paano gumagana ang lahat

Patakbuhin ang utos helm install. Ipahiwatig natin ang pangalan ng release ng application at ibigay ang path sa values.yaml. Sa dulo ay ipahiwatig namin ang imbakan kung saan matatagpuan ang tsart at ang pangalan ng tsart. Sa halimbawa, ito ay "lmru" at "bestchart", ayon sa pagkakabanggit.

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

Ang utos ay maaaring isakatuparan ng isang beses lamang, kapag naisakatuparan muli sa halip install kailangan gamitin upgrade. Para sa pagiging simple, sa halip na dalawang utos, maaari mong patakbuhin ang utos upgrade na may karagdagang susi --install. Kapag naisakatuparan sa unang pagkakataon, magpapadala ang Helm ng command para i-install ang release, at ia-update ito sa hinaharap.

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

Mga pitfalls ng pag-deploy ng mga bagong bersyon ng isang application gamit ang Helm

Sa puntong ito ng kwento, naglalaro ako ng Who Wants to Be a Millionaire kasama ng audience, at inaalam namin kung paano i-update ni Helm ang bersyon ng app. Panoorin ang video.

Noong nalaman ko kung paano gumagana ang Helm, nagulat ako sa kakaibang gawi kapag sinusubukan kong i-update ang mga bersyon ng tumatakbong mga application. Na-update ko ang application code, nag-upload ng bagong imahe sa Docker registry, nagpadala ng deployment command - at walang nangyari. Nasa ibaba ang ilang hindi ganap na matagumpay na paraan upang i-update ang mga application. Sa pamamagitan ng pag-aaral ng bawat isa sa kanila nang mas detalyado, sinisimulan mong maunawaan ang panloob na istraktura ng instrumento at ang mga dahilan para sa hindi halatang pag-uugali na ito.

Paraan 1. Huwag baguhin ang impormasyon mula noong huling paglulunsad

Gaya ng sinasabi nito opisyal na site Helm, "Maaaring malaki at kumplikado ang mga chart ng Kubernetes, kaya sinusubukan ni Helm na huwag masyadong hawakan ang anuman." Samakatuwid, kung i-update mo ang pinakabagong bersyon ng imahe ng application sa registry ng docker at patakbuhin ang command helm upgrade, tapos walang mangyayari. Iisipin ng Helm na walang nagbago at hindi na kailangang magpadala ng command sa Kubernetes para i-update ang application.

Dito at sa ibaba, ang pinakabagong tag ay ipinapakita lamang bilang isang halimbawa. Kapag tinukoy mo ang tag na ito, ida-download ng Kubernetes ang larawan mula sa registry ng docker sa bawat oras, anuman ang parameter ng imagePullPolicy. Ang paggamit ng pinakabagong sa produksyon ay hindi kanais-nais at nagiging sanhi ng mga side effect.

Paraan 2. I-update ang LABEL sa larawan

Tulad ng nakasulat sa parehong dokumentasyon, "Mag-a-update lang ng application ang Helm kung nagbago ito mula noong huling release." Ang isang lohikal na opsyon para dito ay tila ina-update ang LABEL sa docker image mismo. Gayunpaman, hindi tinitingnan ng Helm ang mga larawan ng application at walang ideya tungkol sa anumang mga pagbabago sa mga ito. Alinsunod dito, kapag nag-a-update ng mga label sa larawan, hindi malalaman ng Helm ang tungkol sa mga ito, at ang utos sa pag-update ng application ay hindi ipapadala sa Kubernetes.

Paraan 3: Gumamit ng susi --force

Bumaling tayo sa mga manual at hanapin ang kinakailangang susi. Ang susi ang pinakamahalaga --force. Sa kabila ng malinaw na pangalan, ang pag-uugali ay naiiba sa inaasahan. Sa halip na pilitin ang pag-update ng application, ang tunay na layunin nito ay ibalik ang isang release na nasa FAILED status. Kung hindi mo gagamitin ang key na ito, kailangan mong isagawa ang mga command nang sunud-sunod helm delete && helm install --replace. Iminumungkahi na gamitin ang susi sa halip --force, na nag-automate sa sunud-sunod na pagpapatupad ng mga utos na ito. Higit pang impormasyon dito hiling ng hilahin. Upang sabihin sa Helm na i-update ang bersyon ng application, sa kasamaang-palad, ang key na ito ay hindi gagana.

Paraan 4. Direktang baguhin ang mga label sa Kubernetes

Direktang pag-update ng label sa cluster gamit ang command kubectl edit - masamang ideya. Ang pagkilos na ito ay hahantong sa hindi pagkakapare-pareho ng impormasyon sa pagitan ng tumatakbong application at ang orihinal na ipinadala para sa pag-deploy. Ang pag-uugali ng Helm sa panahon ng pag-deploy sa kasong ito ay naiiba sa bersyon nito: Walang gagawin ang Helm 2, at ide-deploy ng Helm 3 ang bagong bersyon ng application. Upang maunawaan kung bakit, kailangan mong maunawaan kung paano gumagana ang Helm.

Paano gumagana ang Helm?

Upang matukoy kung nagbago ang isang application mula noong huling paglabas nito, maaaring gamitin ng Helm ang:

pagpapatakbo ng application sa Kubernetes;
bagong mga halaga.yaml at kasalukuyang tsart;
Impormasyon sa panloob na paglabas ng Helm.

Para sa mas mausisa: saan iniimbak ng Helm ang panloob na impormasyon tungkol sa mga release?Sa pamamagitan ng pagpapatupad ng utos helm history, makukuha namin ang lahat ng impormasyon tungkol sa mga bersyon na naka-install gamit ang Helm.

Mayroon ding detalyadong impormasyon tungkol sa mga ipinadalang template at halaga. Maaari naming hilingin ito:

Sa pangalawang bersyon ng Helm, ang impormasyong ito ay matatagpuan sa parehong namespace kung saan tumatakbo ang Tiller (kube-system bilang default), sa ConfigMap, na minarkahan ng label na "OWNER=TILLER":

Nang lumitaw ang ikatlong bersyon ng Helm, inilipat ang impormasyon sa mga lihim, at sa parehong namespace kung saan tumatakbo ang application. Dahil dito, naging posible na magpatakbo ng ilang application nang sabay-sabay sa iba't ibang namespace na may parehong pangalan ng release. Sa pangalawang bersyon, isang malubhang sakit ng ulo kapag ang mga namespace ay nakahiwalay ngunit maaaring makaimpluwensya sa isa't isa.

Ang pangalawang Helm, kapag sinusubukang unawain kung kailangan ang isang update, ay gumagamit lamang ng dalawang mapagkukunan ng impormasyon: kung ano ang ibinibigay dito ngayon, at panloob na impormasyon tungkol sa mga release, na nasa ConfigMap.

Gumagamit ang ikatlong Helm ng three-way na diskarte sa pagsasanib: bilang karagdagan sa impormasyong iyon, isinasaalang-alang din nito ang application na tumatakbo ngayon sa Kubernetes.

Para sa kadahilanang ito, ang lumang bersyon ng Helm ay walang gagawin, dahil hindi nito isinasaalang-alang ang impormasyon ng aplikasyon sa cluster, ngunit matatanggap ng Helm 3 ang mga pagbabago at ipapadala ang bagong aplikasyon para sa pag-deploy.

Paraan 5. Gamitin ang --recreate-pods switch

May susi --recreate-pods makakamit mo ang orihinal mong pinlano na makamit gamit ang susi --force. Magre-restart ang mga container at, ayon sa imagePullPolicy: Palaging patakaran para sa pinakabagong tag (higit pa dito sa footnote sa itaas), magda-download at maglulunsad ang Kubernetes ng bagong bersyon ng larawan. Hindi ito gagawin sa pinakamahusay na paraan: nang hindi isinasaalang-alang ang StrategyType ng deployment, bigla nitong isasara ang lahat ng lumang application instance at magsisimulang maglunsad ng mga bago. Sa panahon ng pag-restart, ang system ay hindi gagana, ang mga gumagamit ay magdurusa.

Sa Kubernetes mismo, ang isang katulad na problema ay umiral din sa mahabang panahon. At ngayon, 4 na taon pagkatapos ng pagbubukas Problema, naayos na ang problema, at simula sa bersyon 1.15 ng Kubernetes, lalabas ang kakayahang mag-roll-restart ng mga pod.

Ino-off lang ng Helm ang lahat ng application at naglulunsad ng mga bagong container sa malapit. Hindi mo ito magagawa sa produksyon, upang hindi maging sanhi ng downtime ng aplikasyon. Ito ay kailangan lamang para sa mga pangangailangan sa pag-unlad at maaari lamang isagawa sa mga kapaligiran ng entablado.

Paano i-update ang bersyon ng application gamit ang Helm?

Babaguhin namin ang mga halaga na ipinadala sa Helm. Karaniwan, ang mga ito ay mga halaga na pinapalitan sa lugar ng tag ng larawan. Sa kaso ng pinakabago, na kadalasang ginagamit para sa mga hindi produktibong kapaligiran, ang nababagong impormasyon ay isang anotasyon, na walang silbi para sa Kubernetes mismo, at para sa Helm ito ay magsisilbing senyales para sa pangangailangang i-update ang application. Mga opsyon para sa pagpuno sa halaga ng anotasyon:

Random na halaga gamit ang karaniwang function - {{ randAlphaNum 6 }}.
May caveat: pagkatapos ng bawat deployment gamit ang isang chart na may ganoong variable, magiging kakaiba ang annotation value, at ipapalagay ni Helm na may mga pagbabago. Lumalabas na palagi naming i-restart ang application, kahit na hindi namin binago ang bersyon nito. Hindi ito kritikal, dahil walang downtime, ngunit hindi pa rin ito kasiya-siya.
Idikit ang kasalukuyang petsa at oras - {{ .Release.Date }}.
Ang isang variant ay katulad ng isang random na halaga na may permanenteng natatanging variable.
Ang isang mas tamang paraan ay ang paggamit mga checksum. Ito ang SHA ng imahe o ang SHA ng huling commit sa git - {{ .Values.sha }}.
Kakailanganin silang bilangin at ipadala sa kliyente ng Helm sa gilid ng pagtawag, halimbawa sa Jenkins. Kung nagbago ang aplikasyon, magbabago ang checksum. Samakatuwid, ia-update lang ng Helm ang application kapag kinakailangan.

Ibuod natin ang ating mga pagtatangka

Gumagawa ang Helm ng mga pagbabago sa hindi bababa sa invasive na paraan, kaya ang anumang pagbabago sa antas ng imahe ng application sa Docker Registry ay hindi magreresulta sa isang update: walang mangyayari pagkatapos maisagawa ang command.
Key --force ginagamit upang ibalik ang mga may problemang release at hindi nauugnay sa sapilitang pag-update.
Key --recreate-pods puwersahang mag-a-update ng mga application, ngunit gagawin ito sa paraang vandal: bigla nitong isasara ang lahat ng container. Ang mga gumagamit ay magdurusa mula dito; hindi mo dapat gawin ito sa produksyon.
Direktang gumawa ng mga pagbabago sa Kubernetes cluster gamit ang command kubectl edit huwag: sisirain natin ang consistency, at mag-iiba ang gawi depende sa bersyon ng Helm.
Sa paglabas ng bagong bersyon ng Helm, maraming mga nuances ang lumitaw. Ang mga isyu sa repositoryo ng Helm ay inilarawan sa malinaw na wika, tutulungan ka nitong maunawaan ang mga detalye.
Ang pagdaragdag ng nae-edit na anotasyon sa isang chart ay gagawin itong mas nababaluktot. Papayagan ka nitong ilunsad nang tama ang application, nang walang downtime.

Isang kaisipang "kapayapaan sa daigdig" na gumagana sa lahat ng bahagi ng buhay: basahin ang mga tagubilin bago gamitin, hindi pagkatapos. Tanging sa kumpletong impormasyon magiging posible na bumuo ng mga maaasahang system at mapasaya ang mga gumagamit.

Iba pang mga kaugnay na link:

Ang ulat na ito ay unang ipinakita sa @Kubernetes Conference sa pamamagitan ng Mail.ru Cloud Solutions. Tingnan mo video iba pang mga pagtatanghal at mag-subscribe sa mga anunsyo ng kaganapan sa Telegram Sa paligid ng Kubernetes sa Mail.ru Group.

Pinagmulan: www.habr.com

Ang Helm device at ang mga pitfalls nito