Më quajnë Dmitrij Sugrobo, jam zhvillues në «Lerua Merlin». Në këtë artikull do të flas se përse është e nevojshme Helm, si e lehtëson punën me Kubernetes, çfarë ka ndryshuar në versionin e tretë dhe si me ndihmën e tij mund të përditësojmë aplikacionet në prodhim pa ndalesë.
Ky Ă«shtĂ« njĂ« pĂ«rmbledhje e fjalĂ«s nĂ« konferencĂ« duke â nĂ«se nuk dĂ«shironi tĂ« lexoni, shikoni videon.
Pse përdorim Kubernetes në prodhim
«Lerua Merlin» Ă«shtĂ« lider nĂ« tregun e DIY-retaile nĂ« Rusi dhe EvropĂ«. NĂ« kompaninĂ« tonĂ« ka mĂ« shumĂ« se njĂ«qind zhvillues, 33,000 punonjĂ«s tĂ« brendshĂ«m dhe njĂ« numĂ«r tĂ« madh njerĂ«zish qĂ« vizitojnĂ« hipermarketet dhe faqen tonĂ«. PĂ«r tĂ« bĂ«rĂ« tĂ« gjithĂ« ata tĂ« lumtur, ne vendosĂ«m tĂ« ndjekim qasjet standarde nĂ« industri. TĂ« zhvillojmĂ« aplikacione tĂ« reja duke pĂ«rdorur arkitekturĂ«n mikroshĂ«rbimor; pĂ«r tâi izoluar mjediset dhe pĂ«r tĂ« bĂ«rĂ« shpĂ«rndarjen e duhur, tĂ« pĂ«rdorim kontejnerĂ«; dhe pĂ«r orkestrimin tĂ« pĂ«rdorim Kubernetes. Ămimi pĂ«r pĂ«rdorimin e orkestratorĂ«ve po bĂ«het gjithnjĂ« e mĂ« i lirĂ«: nĂ« treg po rritet numri i inxhinierĂ«ve qĂ« zotĂ«rojnĂ« teknologjinĂ«, shfaqen ofrues tĂ« cilĂ«t ofrojnĂ« Kubernetes si njĂ« shĂ«rbim.
Gjithçka që bën Kubernetes, sigurisht, mund të bëhet edhe me mënyra të tjera, për shembull, duke krijuar skripte me ndihmën e ndonjë Jenkins dhe docker-compose, por përse duhet ta komplikoni jetën, nëse ka një zgjidhje të gatshme dhe të besueshme? Prandaj arritëm te Kubernetes dhe tani e përdorim atë në prodhim për një vit. Aktualisht kemi njëzet e katër klastera Kubernetes, më e vjetër se një vit, me rreth dyqind podë.
Shkaku i numrit të madh të skedarëve YAML në Kubernetes
PĂ«r tĂ« nisur njĂ« mikroshĂ«rbim nĂ« Kubernetes, do tĂ« krijojmĂ« tĂ« paktĂ«n pesĂ« skedarĂ« YAML: pĂ«r Deployment, ShĂ«rbim, Ingress, ConfigMap, Sekrete â dhe do t'i dĂ«rgojmĂ« nĂ« klaster. PĂ«r aplikacionin tjetĂ«r do tĂ« shkruajmĂ« tĂ« njĂ«jtin paketĂ« skedarĂ«sh YAML, pĂ«r atĂ« tĂ« tretĂ« â njĂ« tjetĂ«r dhe kĂ«shtu me radhĂ«. TĂ« shumojmĂ« numrin e dokumenteve me numrin e mjediseve, tashmĂ« do tĂ« kemi qindra skedarĂ«, dhe kjo ende nuk pĂ«rfshin mjediset dinamike.
Adam Reese, mbajtĂ«s kryesor i Helm, futi konceptin ââ, i cili duket kĂ«shtu:
- Copy YAML â kopjoni skedarin YAML.
- Paste YAML â ngjitni atĂ«.
- Fix Indents â rregulloni indentimet.
- Repeat â pĂ«rsĂ«riteni.
Një variant funksional, por duhet të kopjoni shumë herë skedarët YAML. Për të ndryshuar këtë cikël, u krijua Helm.
ĂfarĂ« Ă«shtĂ« Helm
SĂ« pari, Helm â , njĂ« grup utilitarĂ«sh standard (binutils, coreutils, netutils, extrautils), shell-in e komandave, ndihmon nĂ« gjetjen dhe instalimin e programeve tĂ« nevojshme. PĂ«r tĂ« instaluar, pĂ«r shembull, MongoDB nuk Ă«shtĂ« e nevojshme tĂ« shkosh nĂ« faqen zyrtare dhe tĂ« shkarkosh binarĂ«t, mjafton tĂ« ekzekutosh komandĂ«n helm install stable/mongodb.
SĂ« dyti, Helm â shabllonizues, ndihmon nĂ« parametrizimin e skedave. Le tĂ« kthehemi nĂ« situatĂ«n me skedat YAML nĂ« Kubernetes. ĂshtĂ« mĂ« e lehtĂ« tĂ« shkruash tĂ« njĂ«jtĂ«n skedĂ« YAML, tĂ« shtosh disa placeholder, nĂ« tĂ« cilat Helm do tĂ« vendosĂ« vlerat. Pra, nĂ« vend tĂ« njĂ« grumbulli tĂ« madh skedash YAML, do tĂ« ketĂ« njĂ« set shabllonash, nĂ« tĂ« cilat nĂ« momentin e duhur do tĂ« zĂ«vendĂ«sohen vlerat e nevojshme.
SĂ« tretĂ«, Helm â master pĂ«r desplejtimin. Me ndihmĂ«n e tij, mund tĂ« instalosh, rikthesh dhe pĂ«rmirĂ«sosh aplikacione. Le tĂ« shqyrtojmĂ« se si ta bĂ«jmĂ« kĂ«tĂ«.
Si të përdorim Helm për deploy-in e aplikacioneve tona
Do të instalojmë klientin Helm në kompjuter, duke ndjekur zyrtarë . Më pas do të krijojmë një set skedash YAML. Në vend të caktimit të vlerave specifike, do të lëmë placeholder të cilat në të ardhmen Helm do t'i mbushë me informacion. Ky set skedash quhet Helm chart. Mund ta dërgojmë në klientin e komandës Helm në tri mënyra:
- të caktosh dosjen me shabllona;
- ta paketosh në një arkiv .tar dhe të tregosh për të;
- të vendosësh shabllonin në një repository të largët dhe të shtosh lidhjen e repository-t në klientin Helm.
Nevojitet gjithashtu njĂ« skedĂ« me vlera â values.yaml. TĂ« dhĂ«nat nga aty do tĂ« vendosen nĂ« shabllon. Le tĂ« krijojmĂ« edhe atĂ«.
NĂ« versionin e dytĂ« tĂ« Helm ka njĂ« aplikacion tĂ« shtuar serveri â Tiller. Ai Ă«shtĂ« jashtĂ« Kubernetes dhe pret kĂ«rkesa nga klienti Helm, dhe kur thirret, vendos vlerat e nevojshme nĂ« shabllon dhe e dĂ«rgon nĂ« Kubernetes.
Helm 3 është më i thjeshtë: në vend të përpunimit të shablloneve në server, informacioni tani përpunojë plotësisht në anën e klientit Helm dhe dërgohet drejtpërdrejt në Kubernetes API. Ky thjeshtim rrit sigurinë e grupit dhe lehtëson procesin e shpërndarjes.
Si funksionon gjithçka
Ekzekutojmë komandën helm install. Tregojmë emrin e lëshimit të aplikacionit, japim rrugën deri te values.yaml. Në fund, tregojmë repository-n ku ndodhet chart dhe emrin e chart-it. Në këtë rast, ato janë «lmru» dhe «bestchart» përkatësisht.
helm install --name bestapp --values values.yaml lmru/bestchart
Ekzekutimi i komandës është i mundshëm vetëm një herë, gjatë ekzekutimit të përsëritur në vend të instalo duhet të përdoret upgrade. Për thjeshtësinë, në vend të dy komandave, mund të ekzekutoni komandën upgrade me një çelës shtesë --installNë ekzekutimin e parë, Helm do të dërgojë një komandë për të instaluar një rrelease, dhe më pas do ta përmirësojë atë.
helm upgrade --install bestapp --values values.yaml lmru/bestchart
Pikat e vështira të shpërndarjes së versioneve të reja të aplikacioneve me Helm
Në këtë pikë të tregimit, unë luaj me sallën në "Kush do të bëhet milioner", dhe ne zbulojmë se si ta bëjmë Helm të përmirësojë versionin e aplikacionit. .
Kur studioja funksionimin e Helm, mĂ« befasoi sjellja e çuditshme gjatĂ« pĂ«rpjekjes pĂ«r tĂ« pĂ«rmirĂ«suar versionet e aplikacioneve qĂ« ishin aktivizuar. Kodi i aplikacionit u pĂ«rmirĂ«sua, ngarkohet njĂ« imazh i ri nĂ« docker registry, dĂ«rgoj komandĂ«n pĂ«r shpĂ«rndarje â dhe asgjĂ« nuk ndodhi. MĂ« poshtĂ« janĂ« disa metoda jo shumĂ« tĂ« suksesshme pĂ«r pĂ«rmirĂ«simin e aplikacioneve. Studimi i secilĂ«s nga kĂ«to nĂ« mĂ«nyrĂ« mĂ« tĂ« detajuar fillon tĂ« kuptojĂ« strukturĂ«n e brendshme tĂ« mjetit dhe arsyet e kĂ«tij sjelljeje qĂ« nuk Ă«shtĂ« aq e qartĂ«.
Metoda 1. Mos ndryshoni informacionin që nga aktivizimi i fundit
Siç thotë Helm, "Kubernetes chart janë të mëdha dhe të komplikuara, prandaj Helm përpiqet të mos prekë asgjë pa nevojë". Prandaj, nëse përmirëson versionin e fundit të imazhit të aplikacionit në registry docker dhe ekzekuton komandën helm upgrade, atëherë nuk do të ndodhë asgjë. Helm do të mendojë që nuk ka ndryshime dhe nuk do të jetë e nevojshme të dërgohet një komandë për përmirësimin e aplikacionit në Kubernetes.
Këtu dhe më tej, etiketimi latest është treguar vetëm si shembull. Kur përdoret ky etiketim, Kubernetes do të shkarkojë gjithmonë imazhin nga registry docker, pavarësisht nga parametri imagePullPolicy. Përdorimi i latest në prodhim është i papreferuar dhe shkakton efekte anësore.
Metoda 2. Përtëritni LABEL në imazh
Siç shkruhet në të njëjtin , "Helm do të përmirësojë aplikacionin vetëm nëse ai ka ndryshuar që nga kyçja e fundit". Një opsion logjik për këtë do të ishte përmirësimi i etiketës LABEL në imazhin e dockerit. Megjithatë, Helm nuk shikon brenda imazheve të aplikacioneve dhe nuk ka njohuri për ndonjë ndryshim në to. Për rrjedhojë, gjatë përmirësimit të etiketave në imazh, Helm nuk do të dijë për to, dhe komanda për përmirësimin e aplikacionit në Kubernetes nuk do të dërgohet.
Metoda 3. Përdorni çelësin --force
TĂ« kthehemi te manualet dhe tĂ« gjejmĂ« çelĂ«sin e nevojshĂ«m. ĂelĂ«si qĂ« pĂ«rputhet mĂ« mirĂ« me kuptimin Ă«shtĂ« --force. MegjithĂ«se emri flet vetĂ«, sjellja ndryshe nga ajo qĂ« pritet. NĂ« vend tĂ« forcimit tĂ« azhurnimit tĂ« aplikacionit, qĂ«llimi i tij real Ă«shtĂ« rikuperimi i njĂ« versioni qĂ« ndodhet nĂ« statusin FAILED. NĂ«se nuk e pĂ«rdorni kĂ«tĂ« çelĂ«s, duhet tĂ« ekzekutoni komandat njĂ« pas njĂ«. helm delete && helm install --replace. NĂ« vend tĂ« kĂ«saj, propozohet pĂ«rdorimi i çelĂ«sit --force, i cili automatizon ekzekutimin e rrjedhshĂ«m tĂ« kĂ«tyre komandave. MĂ« shumĂ« informacion nĂ« kĂ«tĂ« . PĂ«r ta thĂ«nĂ« Helm tĂ« azhurnojĂ« versionin e aplikacionit, fatkeqĂ«sisht, ky çelĂ«s nuk do tĂ« funksionojĂ«.
Mënyra 4. Të ndryshoni etiketat përmes Kubernetesit.
Azhurnimi i etiketave drejtpërdrejt në klaster me anë të komandës kubectl edit është një ide e keqe. Ky veprim do të çojë në inconsistency midis aplikacionit në funksionim dhe asaj që ishte dërguar në fillim për shpërndarje. Sjellja e Helm gjatë shpërndarjes në këtë rast ndryshon nga versioni i tij: Helm 2 nuk do të bëjë asgjë, ndërsa Helm 3 do të shpërndajë një version të ri të aplikacionit. Për të kuptuar shkakun, duhet të kuptohet se si funksionon Helm.
Si është e strukturuar Helm.
Për të përcaktuar nëse aplikacioni ka ndryshuar që nga lëshimi i fundit, Helm mund të shfrytëzojë:
- aplikacionin në funksionim në Kubernetes;
- fajllin e ri values.yaml dhe chart-in aktual;
- informacionin e brendshëm të Helm mbi lëshimet.
Për ata më kuriozë: ku e ruan Helm informacionin e brendshëm mbi lëshimet?Duke ekzekutuar komandën helm history, ne do të marrim të gjithë informacionin mbi versionet e instaluara me anë të Helm.
Ka gjithashtu informacion të detajuar mbi shabllonet dhe vlerat e dërguara. Mund ta kërkojmë atë:
NĂ« versionin e dytĂ« tĂ« Helm, ky informacion ndodhet nĂ« tĂ« njĂ«jtin emĂ«rhapĂ«sirĂ« ku Ă«shtĂ« aktivizuar Tiller (nĂ« mĂ«nyrĂ« tĂ« paracaktuar â kube-system), nĂ« ConfigMap, tĂ« cilin e shĂ«non etiketĂ« "OWNER=TILLER":
Me paraqitjen e versionit të tretë të Helm, informacioni u transferua në sekrete, për më shumë në të njëjtin emërhapësirë ku është aktivizuar aplikacioni. Falë kësaj, është bërë e mundur të funksionojnë njëkohësisht shumë aplikacione në emërhapësira të ndryshme me të njëjtin emër lëshimi. Në versionin e dytë kjo ishte një dhimbje e madhe koke, kur emërhapësirat janë të izoluar, por mund të ndikojnë në njëra-tjetrën.
Helm i dytë, kur përpiqet të kuptojë nëse ka nevojë për azhurnim, përdor vetëm dy burime informacioni: atë që i është dhënë tani, dhe informacionin e brendshëm mbi lëshimet, i cili ndodhet në ConfigMap.
Helm-i tretë përdor strategjinë three-way merge: përveç informacionit që merr parasysh, ai merr gjithashtu në konsideratë aplikacionin, i cili po punon aktualisht në Kubernetes.
Për këtë arsye, versioni i vjetër i Helm nuk do të bëjë asgjë, pasi nuk merr në konsideratë informacionin e aplikacionit në klaster, ndërsa Helm 3 do të marrë ndryshimet dhe do të dërgojë një aplikacion të ri për të u implementuar.
MĂ«nyra 5. PĂ«rdorni çelĂ«sin ârecreate-pods
Me çelësin --recreate-pods mund të arrihet ajo që fillimisht ishte planifikuar të arrihej me çelësin --force. Kontejnerët do të rinisën dhe, sipas politikës imagePullPolicy: Always për etiketën latest (për këtë në shënimin më sipër), Kubernetes do të shkarkojë dhe nisë versionin e ri të imazhit. Kjo do të bëhet në një mënyrë jo ideale: pa marrë parasysh StrategyType të implementimit, do të fikë papritmas të gjitha instancat e vjetra të aplikacionit dhe do të nisë të rejat. Gjatë rinisjes, sistemi nuk do të funksionojë, përdoruesit do të vuajnë.
Edhe në vetë Kubernetes, një problem i ngjashëm ka ekzistuar për një kohë të gjatë. Dhe ja, pas 4 vjetësh që nga hapja , problemi është zgjidhur, dhe duke filluar nga versioni 1.15 i Kubernetes, është e mundur të bëhet rolling-restart i podëve.
Helm thjesht fik të gjitha aplikacionet dhe nis afër kontejnerë të rinj. Në prodhim nuk duhet bërë kështu, për të shmangur ndalimin e aplikacionit. Kjo është e nevojshme vetëm për nevojat e zhvillimit, mund të bëhet vetëm në ambientet stage.
Si të përditësoni versionin e aplikacionit me ndihmën e Helm?
Do të ndryshojmë vlerat që dërgohen te Helm. Në përgjithësi, këto janë vlera që vendosen në vend të etiketës së imazhit. Në rastin e latest, e cila përdoret shpesh për ambientet jo-prodhuese, informacioni i ndryshueshëm është një anotim, i cili për Kubernetes është i padobishëm, por për Helm do të shërbejë si një sinjal për nevojën për të përditësuar aplikacionin. Mundësitë për të mbushur vlerën e anotimit janë:
- VlerĂ« tĂ« rastĂ«sishme me funksionin standard â
{{ randAlphaNum 6 }}.
Ka njĂ« detaj: pas çdo implementimi me pĂ«rdorimin e chartit me njĂ« variabĂ«l tĂ« tillĂ«, vlera e anotimit do tĂ« jetĂ« unike, dhe Helm do tĂ« mendojĂ« se ka ndryshime. Ndryshe, gjithmonĂ« do tĂ« ri-nisim aplikacionin, edhe nĂ«se nuk e kemi ndĂ«rruar versionin e tij. Kjo nuk Ă«shtĂ« kritike, sepse nuk do tĂ« ketĂ« ndalime, por megjithatĂ« Ă«shtĂ« e pakĂ«ndshme. - TĂ« vendosim datĂ«n dhe kohĂ«n aktuale â
{{ .Release.Date }}.
Varianti Ă«shtĂ« i ngjashĂ«m me vlerĂ«n e rastĂ«sishme me njĂ« variabĂ«l gjithmonĂ« unike. - NjĂ« mĂ«nyrĂ« mĂ« e saktĂ« Ă«shtĂ« tĂ« pĂ«rdorni shuma kontrolluese. Ky Ă«shtĂ« SHA i imazhit ose SHA i angazhimit tĂ« fundit nĂ« git â
{{ .Values.sha }}.
Duhet të llogariten dhe të dërgohen në klientin Helm në anën e thirrjes, për shembull në Jenkins. Nëse aplikacioni ndryshon, atëherë dhe shuma kontrolluese do të ndryshojë. Pra, Helm do të azhurnojë aplikacionin vetëm kur është e nevojshme.
Të përmbledhim përpjekjet tona
- Helm bën ndryshime në një mënyrë të vogël invazive, prandaj çdo ndryshim në nivelin e imazhit të aplikacionit në Docker Registry nuk do të rezultojë në një azhurnim: pas ekzekutimit të komandës, nuk do të ndodhë asgjë.
- ĂelĂ«si
--forcepĂ«rdoret pĂ«r rikthimin e lĂ«shimeve problematike dhe nuk Ă«shtĂ« i lidhur me azhurnimin e detyrueshĂ«m. - ĂelĂ«si
--recreate-podsdo të azhurnojë aplikacionet me forcë, por do ta bëjë këtë në një mënyrë vandaliste: do të ndalë menjëherë të gjitha kontejnerët. Kjo do të dëmtojë përdoruesit, në prodhim nuk është e nevojshme të veprohet kështu. - Të bëjmë ndryshime drejtpërdrejt në klasterin Kubernetes me komandën
kubectl editnuk duhet: do të shkelim njëtrajtshmërinë, dhe sjellja do të ndryshojë në varësi të versionit të Helm. - Me daljen e versionit të ri të Helm ka lindur shumë nuanca. Cështjet në depohelm janë përshkruar në një mënyrë të qartë, ato do t'ju ndihmojnë të kuptoni detajet.
- Shtimi i një annotimi të ndryshueshëm në chart do ta bëjë atë më fleksibël. Kjo do të lejojë që aplikacioni të avanconet në mënyrë të duhur, pa ndalesa.
Një mendim nga kategoria "paqe në të gjithë botën", që funksionon në të gjitha fushat e jetës: lexoni udhëzimin para përdorimit, jo pas. Vetëm duke pasur informacion të plotë, do të jetë e mundur të ndërtohen sisteme të besueshme dhe të bëhen përdoruesit të lumtur.
Lidhje të tjera rreth temës:
Ky raport u paraqit për herë të parë në nga Mail.ru Cloud Solutions. Shikoni prezentime të tjera dhe abonohuni në njoftimet e ngjarjeve në Telegram .
Burimi: habr.com
