🥇Pajisja Helm dhe kurthet e saj

Koncepti i transportuesit të mallrave Typhon, Anton Swanepoel

Emri im është Dmitry Sugrobov, unë jam një zhvillues në Leroy Merlin. Në këtë artikull do t'ju tregoj pse nevojitet Helm, si e thjeshton punën me Kubernetes, çfarë ka ndryshuar në versionin e tretë dhe si ta përdorni për të përditësuar aplikacionet në prodhim pa ndërprerje.

Kjo është një përmbledhje e bazuar në një fjalim në një konferencë Konferenca @Kubernetes by Mail.ru Cloud Solutions — nëse nuk doni të lexoni, shikoni videon.

Pse përdorim Kubernetes në prodhim

Leroy Merlin është një lider në tregun e shitjes me pakicë DIY në Rusi dhe Evropë. Kompania jonë ka më shumë se njëqind zhvillues, 33 punonjës të brendshëm dhe një numër të madh njerëzish që vizitojnë hipermarketet dhe faqen e internetit. Për t'i bërë të gjithë të lumtur, vendosëm të ndjekim qasjet standarde të industrisë. Zhvilloni aplikacione të reja duke përdorur arkitekturën e mikroservisit; përdorni kontejnerë për të izoluar mjediset dhe për të siguruar shpërndarjen e duhur; dhe përdorni Kubernetes për orkestrim. Çmimi i përdorimit të orkestruesve po bëhet me shpejtësi më i lirë: numri i inxhinierëve të aftë në teknologji po rritet në treg dhe ofruesit po shfaqen duke ofruar Kubernetes si shërbim.

Gjithçka që bën Kubernetes, natyrisht, mund të bëhet në mënyra të tjera, për shembull, duke mbuluar disa Jenkins dhe docker-compose me skenarë, por pse ta komplikojmë jetën nëse ka një zgjidhje të gatshme dhe të besueshme? Kjo është arsyeja pse ne erdhëm në Kubernetes dhe e përdorim atë në prodhim për një vit tani. Aktualisht kemi njëzet e katër grupime Kubernetes, më e vjetra prej të cilave është më shumë se një vjeç, me rreth dyqind bishtaja.

Mallkimi i skedarëve të mëdhenj YAML në Kubernetes

Për të nisur një mikroshërbim në Kubernetes, ne do të krijojmë të paktën pesë skedarë YAML: për Deployment, Service, Ingress, ConfigMap, Secrets - dhe do t'i dërgojmë ato në grup. Për aplikacionin tjetër do të shkruajmë të njëjtën paketë bllokimesh, me të tretën do të shkruajmë një tjetër, e kështu me radhë. Nëse e shumëzojmë numrin e dokumenteve me numrin e mjediseve, tashmë do të marrim qindra skedarë, dhe kjo ende nuk po merr parasysh mjediset dinamike.

Adam Reese, mirëmbajtësi kryesor i Helm, prezantoi konceptin e "Cikli i zhvillimit në Kubernetes", e cila duket si kjo:

Kopjo YAML - kopjoni një skedar YAML.
Paste YAML - ngjiteni atë.
Fix Indents - fix indents.
Përsëriteni - përsërisni përsëri.

Opsioni funksionon, por ju duhet të kopjoni skedarët YAML shumë herë. Për të ndryshuar këtë cikël, u shpik Helm.

Çfarë është Helm

Së pari, Helm - menaxher i paketave, i cili ju ndihmon të gjeni dhe instaloni programet që ju nevojiten. Për të instaluar, për shembull, MongoDB, nuk keni nevojë të shkoni në faqen zyrtare të internetit dhe të shkarkoni binare, thjesht ekzekutoni komandën helm install stable/mongodb.

Së dyti, Helm - motori i shabllonit, ndihmon në parametrizimin e skedarëve. Le të kthehemi te situata me skedarët YAML në Kubernetes. Është më e lehtë të shkruash të njëjtin skedar YAML, të shtosh disa mbajtës të vendeve në të, në të cilat Helm do të zëvendësojë vlerat. Kjo do të thotë, në vend të një grupi të madh skelash, do të ketë një grup shabllonesh në të cilat do të zëvendësohen vlerat e kërkuara në kohën e duhur.

Së treti, Helm - mjeshtër i vendosjes. Me të mund të instaloni, riktheni dhe përditësoni aplikacionet. Le të kuptojmë se si ta bëjmë këtë.

Si të përdorni Helm për të vendosur aplikacionet tuaja

Le të instalojmë klientin Helm në kompjuterin tuaj, duke ndjekur zyrtarin udhëzime. Më pas, ne do të krijojmë një grup skedarësh YAML. Në vend që të specifikojmë vlera specifike, ne do të lëmë mbajtëset e vendeve, të cilat Helm do t'i plotësojë me informacion në të ardhmen. Një grup skedarësh të tillë quhet një tabelë Helm. Mund t'i dërgohet klientit të konsolës Helm në tre mënyra:

tregoni një dosje me shabllone;
paketoni arkivin në një .tar dhe drejtojeni atë;
vendosni shabllonin në një depo të largët dhe shtoni një lidhje në depo në klientin Helm.

Ju gjithashtu duhet një skedar me vlera - values.yaml. Të dhënat nga atje do të futen në shabllon. Le ta krijojmë edhe atë.

Versioni i dytë i Helm ka një aplikacion shtesë të serverit - Tiller. Ai varet jashtë Kubernetes dhe pret kërkesa nga klienti Helm, dhe kur thirret, zëvendëson vlerat e kërkuara në shabllon dhe e dërgon atë në Kubernetes.

Helm 3 është më i thjeshtë: në vend të përpunimit të shablloneve në server, informacioni tani përpunohet tërësisht në anën e klientit Helm dhe dërgohet direkt në Kubernetes API. Ky thjeshtësim përmirëson sigurinë e grupimeve dhe lehtëson skemën e prezantimit.

Si funksionon e gjitha

Ekzekutoni komandën helm install. Le të tregojmë emrin e lëshimit të aplikacionit dhe t'i japim shtegun vlerave.yaml. Në fund do të tregojmë depon në të cilën ndodhet grafiku dhe emrin e grafikut. Në shembull, këto janë përkatësisht "lmru" dhe "bestchart".

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

Komanda mund të ekzekutohet vetëm një herë, kur në vend të kësaj të ekzekutohet përsëri install nevoja për të përdorur upgrade. Për thjeshtësi, në vend të dy komandave, mund të ekzekutoni komandën upgrade me çelës shtesë --install. Kur të ekzekutohet për herë të parë, Helm do të dërgojë një komandë për të instaluar lëshimin dhe do ta përditësojë atë në të ardhmen.

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

Grackat e vendosjes së versioneve të reja të një aplikacioni me Helm

Në këtë pikë të historisë, unë jam duke luajtur Who Wants to Be a Millionaire me audiencën dhe po gjejmë se si ta bëjmë Helm të përditësojë versionin e aplikacionit. Shikoni videon.

Kur po mësoja se si funksionon Helm, u befasova nga sjellja e çuditshme kur përpiqesha të përditësoja versionet e aplikacioneve që ekzekutohen. Përditësova kodin e aplikacionit, ngarkova një imazh të ri në regjistrin Docker, dërgova komandën e vendosjes - dhe asgjë nuk ndodhi. Më poshtë janë disa mënyra jo plotësisht të suksesshme për të përditësuar aplikacionet. Duke studiuar secilën prej tyre në më shumë detaje, ju filloni të kuptoni strukturën e brendshme të instrumentit dhe arsyet e kësaj sjelljeje jo të dukshme.

Metoda 1. Mos e ndryshoni informacionin që nga lëshimi i fundit

Siç thotë fjala website zyrtar Helm, "Tabelat e Kubernetes mund të jenë të mëdha dhe komplekse, kështu që Helm përpiqet të mos prekë asgjë shumë." Prandaj, nëse përditësoni versionin më të fundit të imazhit të aplikacionit në regjistrin e dokerit dhe ekzekutoni komandën helm upgrade, atëherë asgjë nuk do të ndodhë. Helm do të mendojë se asgjë nuk ka ndryshuar dhe nuk ka nevojë të dërgoni një komandë në Kubernetes për të përditësuar aplikacionin.

Këtu dhe më poshtë, etiketa e fundit tregohet vetëm si shembull. Kur specifikoni këtë etiketë, Kubernetes do ta shkarkojë imazhin nga regjistri i dokerit çdo herë, pavarësisht nga parametri imagePullPolicy. Përdorimi i fundit në prodhim është i padëshirueshëm dhe shkakton efekte anësore.

Metoda 2. Përditëso LABEL në imazh

Siç shkruhet në të njëjtën dokumentacionin, "Helm do të përditësojë një aplikacion vetëm nëse ka ndryshuar që nga publikimi i fundit." Një opsion logjik për këtë duket të jetë përditësimi i LABEL në vetë imazhin e dokerit. Sidoqoftë, Helm nuk i shikon imazhet e aplikacionit dhe nuk ka asnjë ide për ndonjë ndryshim në to. Prandaj, kur përditëson etiketat në imazh, Helm nuk do të dijë për to dhe komanda e përditësimit të aplikacionit nuk do t'i dërgohet Kubernetes.

Metoda 3: Përdorni një çelës --force

Le të kthehemi te manualet dhe të kërkojmë çelësin e kërkuar. Çelësi ka më shumë kuptim --force. Pavarësisht emrit të dukshëm, sjellja është e ndryshme nga ajo që pritej. Në vend që të detyrojë një përditësim aplikacioni, qëllimi i tij i vërtetë është të rivendosë një version që është në statusin DËSHTUAR. Nëse nuk e përdorni këtë çelës, duhet të ekzekutoni komandat në mënyrë sekuenciale helm delete && helm install --replace. Në vend të kësaj, sugjerohet përdorimi i çelësit --force, i cili automatizon ekzekutimin sekuencial të këtyre komandave. Më shumë informacion në këtë kërkesë për tërheqje. Për t'i thënë Helm-it të përditësojë versionin e aplikacionit, për fat të keq, ky çelës nuk do të funksionojë.

Metoda 4. Ndryshoni etiketat direkt në Kubernetes

Përditësimi i etiketës direkt në grup duke përdorur komandën kubectl edit - ide e keqe. Ky veprim do të çojë në mospërputhje të informacionit midis aplikacionit në punë dhe atij që fillimisht u dërgua për vendosje. Sjellja e Helm gjatë vendosjes në këtë rast ndryshon nga versioni i tij: Helm 2 nuk do të bëjë asgjë, dhe Helm 3 do të vendosë versionin e ri të aplikacionit. Për të kuptuar pse, ju duhet të kuptoni se si funksionon Helm.

Si funksionon Helm?

Për të përcaktuar nëse një aplikacion ka ndryshuar që nga lëshimi i tij i fundit, Helm mund të përdorë:

ekzekutimi i aplikacionit në Kubernetes;
vlerat e reja.yaml dhe grafiku aktual;
Informacioni i lëshimit të brendshëm të Helm.

Për më kuriozët: ku i ruan Helm informacionet e brendshme rreth publikimeve?Me ekzekutimin e komandës helm history, do të marrim të gjitha informacionet rreth versioneve të instaluara duke përdorur Helm.

Ka gjithashtu informacion të detajuar në lidhje me shabllonet dhe vlerat e dërguara. Mund ta kërkojmë:

Në versionin e dytë të Helm, ky informacion ndodhet në të njëjtën hapësirë emrash ku funksionon Tiller (sistem kube si parazgjedhje), në ConfigMap, i shënuar me etiketën "OWNER=TILLER":

Kur u shfaq versioni i tretë i Helm, informacioni u zhvendos në sekretet dhe në të njëjtën hapësirë emri ku po ekzekutohej aplikacioni. Falë kësaj, u bë e mundur ekzekutimi i disa aplikacioneve njëkohësisht në hapësira të ndryshme emrash me të njëjtin emër lëshimi. Në versionin e dytë ishte një dhimbje koke serioze kur hapësirat e emrave janë të izoluara, por mund të ndikojnë njëra-tjetrën.

Helm-i i dytë, kur përpiqet të kuptojë nëse nevojitet një përditësim, përdor vetëm dy burime informacioni: atë që i ofrohet tani dhe informacionin e brendshëm rreth lëshimeve, të cilat gjenden në ConfigMap.

Helm i tretë përdor një strategji bashkimi tre-kahëshe: përveç atij informacioni, ai gjithashtu merr parasysh aplikacionin që po funksionon tani në Kubernetes.

Për këtë arsye, versioni i vjetër i Helm nuk do të bëjë asgjë, pasi nuk merr parasysh informacionin e aplikacionit në grup, por Helm 3 do të marrë ndryshimet dhe do të dërgojë aplikacionin e ri për vendosje.

Metoda 5. Përdorni çelësin --recreate-pods

Me një çelës --recreate-pods ju mund të arrini atë që keni planifikuar fillimisht të arrini me çelësin --force. Kontejnerët do të rifillojnë dhe, sipas politikës imagePullPolicy: Gjithmonë për etiketën më të fundit (më shumë për këtë në fusnotën e mësipërme), Kubernetes do të shkarkojë dhe lëshojë një version të ri të imazhit. Kjo nuk do të bëhet në mënyrën më të mirë: pa marrë parasysh llojin e strategjisë së vendosjes, ai do të çaktivizojë papritmas të gjitha rastet e vjetra të aplikacioneve dhe do të fillojë të lëshojë të reja. Gjatë rifillimit, sistemi nuk do të funksionojë, përdoruesit do të vuajnë.

Në vetë Kubernetes, një problem i ngjashëm ekzistonte gjithashtu për një kohë të gjatë. Dhe tani, 4 vjet pas hapjes Çështje, problemi është rregulluar dhe duke filluar me versionin 1.15 të Kubernetes, shfaqet aftësia për të rifilluar podet.

Helm thjesht çaktivizon të gjitha aplikacionet dhe lëshon kontejnerë të rinj aty pranë. Ju nuk mund ta bëni këtë në prodhim, në mënyrë që të mos shkaktoni ndërprerje të aplikacionit. Kjo nevojitet vetëm për nevojat e zhvillimit dhe mund të kryhet vetëm në mjedise skenike.

Si të përditësoni versionin e aplikacionit duke përdorur Helm?

Ne do të ndryshojmë vlerat e dërguara në Helm. Në mënyrë tipike, këto janë vlera që zëvendësohen në vend të etiketës së imazhit. Në rastin e fundit, i cili përdoret shpesh për mjedise joproduktive, informacioni i ndryshueshëm është një shënim, i cili është i padobishëm për vetë Kubernetes dhe për Helm do të veprojë si një sinjal për nevojën për të përditësuar aplikacionin. Opsionet për plotësimin e vlerës së shënimit:

Vlera e rastësishme duke përdorur funksionin standard - {{ randAlphaNum 6 }}.
Ekziston një paralajmërim: pas çdo vendosjeje duke përdorur një grafik me një variabël të tillë, vlera e shënimit do të jetë unike dhe Helm do të supozojë se ka ndryshime. Rezulton se ne do ta rifillojmë gjithmonë aplikacionin, edhe nëse nuk e kemi ndryshuar versionin e tij. Kjo nuk është kritike, pasi nuk do të ketë kohë joproduktive, por është ende e pakëndshme.
Ngjit rrymën Data dhe ora - {{ .Release.Date }}.
Një variant është i ngjashëm me një vlerë të rastësishme me një ndryshore të përhershme unike.
Një mënyrë më e saktë është përdorimi shumat e kontrollit. Ky është SHA i imazhit ose SHA i kryerjes së fundit në git - {{ .Values.sha }}.
Ata do të duhet të numërohen dhe të dërgohen te klienti Helm në anën e thirrjes, për shembull në Jenkins. Nëse aplikacioni ka ndryshuar, atëherë shuma e kontrollit do të ndryshojë. Prandaj, Helm do të përditësojë aplikacionin vetëm kur të jetë e nevojshme.

Le të përmbledhim përpjekjet tona

Helm bën ndryshime në mënyrën më pak invazive, kështu që çdo ndryshim në nivelin e imazhit të aplikacionit në Regjistrin Docker nuk do të rezultojë në një përditësim: asgjë nuk do të ndodhë pasi komanda të ekzekutohet.
Ключ --force përdoret për të rivendosur lëshimet problematike dhe nuk shoqërohet me përditësime të detyruara.
Ключ --recreate-pods do të përditësojë me forcë aplikacionet, por do ta bëjë këtë në mënyrë vandale: do të fikë papritur të gjithë kontejnerët. Përdoruesit do të vuajnë nga kjo; ju nuk duhet ta bëni këtë në prodhim.
Bëni drejtpërdrejt ndryshime në grupin Kubernetes duke përdorur komandën kubectl edit mos: ne do të thyejmë konsistencën dhe sjellja do të ndryshojë në varësi të versionit të Helm.
Me daljen në treg të versionit të ri të Helm, janë shfaqur shumë nuanca. Çështjet në depon e Helm përshkruhen me gjuhë të qartë, ato do t'ju ndihmojnë të kuptoni detajet.
Shtimi i një shënimi të modifikueshëm në një grafik do ta bëjë atë më fleksibël. Kjo do t'ju lejojë të hapni aplikacionin në mënyrë korrekte, pa ndërprerje.

Një mendim i "paqes botërore" që funksionon në të gjitha fushat e jetës: lexoni udhëzimet para përdorimit, jo pas. Vetëm me informacion të plotë do të jetë e mundur të ndërtohen sisteme të besueshme dhe t'i bëjnë përdoruesit të lumtur.

Lidhje të tjera të lidhura:

Ky raport u prezantua për herë të parë në Konferenca @Kubernetes nga Mail.ru Cloud Solutions. Shikoni video shfaqje të tjera dhe abonohuni në njoftimet e ngjarjeve në Telegram Rreth Kubernetes në Mail.ru Group.

Burimi: www.habr.com

Pajisja Helm dhe kurthet e saj