Moje ime je Dmitry Sugrobov, sem razvijalec pri Leroy Merlin. V tem članku vam bom povedal, zakaj je Helm potreben, kako poenostavlja delo s Kubernetesom, kaj se je spremenilo v tretji različici in kako ga uporabiti za posodabljanje aplikacij v proizvodnji brez izpadov.
To je povzetek, ki temelji na govoru na konferenci by — če ne želite brati, si oglejte video.
Zakaj uporabljamo Kubernetes v proizvodnji
Leroy Merlin je vodilni na maloprodajnem trgu DIY v Rusiji in Evropi. Naše podjetje ima več kot sto razvijalcev, 33 interno zaposlenih in ogromno ljudi, ki obiskujejo hipermarkete in spletno stran. Da bi bili vsi zadovoljni, smo se odločili slediti industrijskim standardnim pristopom. Razvijte nove aplikacije z uporabo arhitekture mikrostoritev; uporabite zabojnike za izolacijo okolij in zagotovite pravilno dostavo; in uporabite Kubernetes za orkestracijo. Cena uporabe orkestratorjev se hitro znižuje: na trgu raste število inženirjev, ki poznajo tehnologijo, pojavljajo se ponudniki, ki ponujajo Kubernetes kot storitev.
Vse, kar počne Kubernetes, je seveda mogoče narediti tudi na druge načine, na primer tako, da prekrijete nekaj Jenkinsov in docker-compose s skripti, a zakaj bi komplicirali življenje, če obstaja že pripravljena in zanesljiva rešitev? Zato smo prišli v Kubernetes in ga že eno leto uporabljamo v proizvodnji. Trenutno imamo štiriindvajset grozdov Kubernetes, od katerih je najstarejši star več kot leto dni, s približno dvesto stroki.
Prekletstvo velikih datotek YAML v Kubernetesu
Za zagon mikrostoritve v Kubernetesu bomo ustvarili vsaj pet datotek YAML: za uvedbo, storitev, vstop, ConfigMap, skrivnosti – in jih poslali v gručo. Za naslednjo prijavo bomo napisali isti paket jammov, s tretjo pa še enega itd. Če število dokumentov pomnožimo s številom okolij, bomo že dobili na stotine datotek, pa še to brez upoštevanja dinamičnih okolij.
Adam Reese, glavni vzdrževalec Helma, je predstavil koncept "«, ki izgleda takole:
- Kopiraj YAML - kopirajte datoteko YAML.
- Prilepite YAML - prilepite.
- Popravi zamike - popravi zamike.
- Ponovi - ponovi še enkrat.
Možnost deluje, vendar morate datoteke YAML večkrat kopirati. Za spremembo tega cikla je bil izumljen Helm.
Kaj je Helm
Prvič, Helm - upravitelj paketov, ki vam pomaga najti in namestiti programe, ki jih potrebujete. Če želite namestiti na primer MongoDB, vam ni treba iti na uradno spletno mesto in prenesti binarnih datotek, samo zaženite ukaz helm install stable/mongodb.
Drugič, Helm - mehanizem predloge, pomaga parametrirati datoteke. Vrnimo se k situaciji z datotekami YAML v Kubernetesu. Lažje je napisati isto datoteko YAML, vanjo dodati nekaj ograde, v katere bo Helm nadomestil vrednosti. To pomeni, da bo namesto velikega nabora odrov na voljo nabor predlog, v katere bodo zahtevane vrednosti zamenjane ob pravem času.
Tretjič, Helm - poveljnik uvajanja. Z njim lahko namestite, povrnete in posodobite aplikacije. Ugotovimo, kako to storiti.
Kako uporabljati Helm za uvajanje lastnih aplikacij
Namestimo odjemalca Helm na vaš računalnik po uradnem . Nato bomo ustvarili niz datotek YAML. Namesto podajanja specifičnih vrednosti bomo pustili ograde, ki jih bo Helm v prihodnosti zapolnil z informacijami. Niz takih datotek se imenuje Helmov grafikon. Odjemalcu konzole Helm ga je mogoče poslati na tri načine:
- označite mapo s predlogami;
- zapakirajte arhiv v .tar in pokažite nanj;
- postavite predlogo v oddaljeni repozitorij in dodajte povezavo do repozitorija v odjemalcu Helm.
Potrebujete tudi datoteko z vrednostmi - values.yaml. Podatki od tam bodo vstavljeni v predlogo. Ustvarimo ga tudi mi.
Druga različica Helma ima dodatno strežniško aplikacijo - Tiller. Visi zunaj Kubernetesa in čaka na zahteve odjemalca Helm in ob klicu zamenja zahtevane vrednosti v predlogo in jo pošlje Kubernetesu.
Helm 3 je preprostejši: namesto obdelave predlog na strežniku se informacije zdaj v celoti obdelajo na strani odjemalca Helm in pošljejo neposredno v Kubernetes API. Ta poenostavitev izboljša varnost gruče in olajša shemo uvajanja.
Kako vse skupaj deluje
Izvedite ukaz helm install. Označimo ime izdaje aplikacije in podamo pot do values.yaml. Na koncu bomo navedli repozitorij, v katerem se grafikon nahaja, in ime grafikona. V primeru sta to »lmru« oziroma »bestchart«.
helm install --name bestapp --values values.yaml lmru/bestchart
Ukaz se lahko izvede samo enkrat, ko se izvede znova install potrebo po uporabi upgrade. Zaradi enostavnosti lahko namesto dveh ukazov zaženete ukaz upgrade z dodatnim ključem --install. Ko se izvede prvič, bo Helm poslal ukaz za namestitev izdaje in jo bo v prihodnosti posodobil.
helm upgrade --install bestapp --values values.yaml lmru/bestchart
Pasti pri uvajanju novih različic aplikacije s Helmom
Na tej točki zgodbe igram igro Who Wants to Be a Millionaire z občinstvom in ugotavljamo, kako bi Helma pripravili do posodobitve različice aplikacije. .
Ko sem se učil, kako Helm deluje, me je presenetilo čudno vedenje pri poskusu posodobitve različic zagnanih aplikacij. Posodobil sem kodo aplikacije, naložil novo sliko v register Docker, poslal ukaz za uvajanje - in nič se ni zgodilo. Spodaj je nekaj ne povsem uspešnih načinov posodabljanja aplikacij. S podrobnejšim preučevanjem vsakega od njih začnete razumeti notranjo strukturo instrumenta in razloge za to ne očitno vedenje.
Metoda 1. Ne spreminjajte informacij od zadnjega zagona
Kot piše Helm, "Grafikoni Kubernetes so lahko veliki in zapleteni, zato se Helm ne trudi ničesar preveč dotikati." Če torej posodobite najnovejšo različico slike aplikacije v registru dockerjev in zaženete ukaz helm upgrade, potem se ne bo zgodilo nič. Helm bo mislil, da se ni nič spremenilo in da ni treba poslati ukaza Kubernetesu za posodobitev aplikacije.
Tukaj in spodaj je zadnja oznaka prikazana zgolj kot primer. Ko določite to oznako, bo Kubernetes vsakič prenesel sliko iz registra dockerjev, ne glede na parameter imagePullPolicy. Uporaba najnovejših v proizvodnji je nezaželena in povzroča stranske učinke.
2. način. Posodobite LABEL na sliki
Kot je zapisano v istem , "Helm bo posodobil samo aplikacijo, če se je spremenila od zadnje izdaje." Zdi se, da bi bila logična možnost za to posodobitev LABEL v sami sliki dockerja. Vendar pa Helm ne pogleda v slike aplikacij in nima pojma o kakršnih koli spremembah na njih. Zato pri posodabljanju oznak na sliki Helm ne bo vedel zanje in ukaz za posodobitev aplikacije ne bo poslan Kubernetesu.
3. način: Uporabite ključ --force
Obrnemo se na priročnike in poiščemo zahtevani ključ. Ključ je najbolj smiseln --force. Kljub očitnemu imenu je vedenje drugačno od pričakovanega. Namesto vsiljevanja posodobitve aplikacije je njen pravi namen obnoviti izdajo, ki je v statusu NEUSPEŠNO. Če te tipke ne uporabljate, morate ukaze izvajati zaporedno helm delete && helm install --replace. Namesto tega je priporočljivo uporabiti ključ --force, ki avtomatizira zaporedno izvajanje teh ukazov. Več informacij v tem . Da bi ukazali Helmu, naj posodobi različico aplikacije, ta ključ žal ne bo deloval.
4. način. Spremenite oznake neposredno v Kubernetesu
Posodabljanje oznake neposredno v gruči z uporabo ukaza kubectl edit - slaba ideja. To dejanje bo povzročilo nedoslednost informacij med aplikacijo, ki se izvaja, in tisto, ki je bila prvotno poslana za uvajanje. Obnašanje Helma med uvajanjem se v tem primeru razlikuje od njegove različice: Helm 2 ne bo naredil ničesar, Helm 3 pa bo uvedel novo različico aplikacije. Če želite razumeti, zakaj, morate razumeti, kako Helm deluje.
Kako Helm deluje?
Če želite ugotoviti, ali se je aplikacija spremenila od zadnje izdaje, lahko Helm uporabi:
- izvajanje aplikacije v Kubernetesu;
- nove vrednosti.yaml in trenutni grafikon;
- Helmove interne informacije o izdaji.
Za bolj radovedne: kje Helm shranjuje notranje informacije o izdajah?Z izvedbo ukaza helm history, bomo dobili vse informacije o različicah, nameščenih s Helmom.
Na voljo so tudi podrobne informacije o poslanih predlogah in vrednostih. Zahtevamo ga lahko:
V drugi različici Helma se te informacije nahajajo v istem imenskem prostoru, kjer se izvaja Tiller (sistem kube privzeto), v ConfigMap, označeno z oznako »OWNER=TILLER«:
Ko se je pojavila tretja različica Helma, so se informacije premaknile med skrivnosti in v isti imenski prostor, kjer se izvaja aplikacija. Zahvaljujoč temu je postalo mogoče zagnati več aplikacij hkrati v različnih imenskih prostorih z istim imenom izdaje. V drugi različici je bil resen glavobol, ko so imenski prostori izolirani, vendar lahko vplivajo drug na drugega.
Drugi Helm, ko poskuša razumeti, ali je potrebna posodobitev, uporablja samo dva vira informacij: tisto, kar mu je trenutno na voljo, in notranje informacije o izdajah, ki so v ConfigMap.
Tretji Helm uporablja tristransko strategijo združevanja: poleg teh informacij upošteva tudi aplikacijo, ki se trenutno izvaja v Kubernetesu.
Zaradi tega stara različica Helma ne bo naredila ničesar, saj ne upošteva informacij o aplikaciji v gruči, vendar bo Helm 3 prejel spremembe in poslal novo aplikacijo v uvedbo.
Metoda 5. Uporabite stikalo --recreate-pods
S ključem --recreate-pods s ključem lahko dosežete tisto, kar ste prvotno načrtovali --force. Vsebniki se bodo znova zagnali in v skladu s pravilnikom imagePullPolicy: Vedno za najnovejšo oznako (več o tem v zgornji opombi) bo Kubernetes prenesel in zagnal novo različico slike. To ne bo storjeno na najboljši način: ne da bi upošteval StrategyType uvajanja, bo nenadoma izklopil vse stare primerke aplikacije in začel zagnati nove. Med ponovnim zagonom sistem ne bo deloval, uporabniki bodo trpeli.
Tudi v samem Kubernetesu je že dolgo obstajal podoben problem. In zdaj, 4 leta po odprtju , je bila težava odpravljena in od različice 1.15 Kubernetesa se pojavi možnost ponovnega zagona podov.
Helm preprosto izklopi vse aplikacije in zažene nove vsebnike v bližini. Tega ne morete storiti v produkciji, da ne povzročite izpada aplikacije. To je potrebno samo za razvojne potrebe in se lahko izvaja le v odrskih okoljih.
Kako posodobiti različico aplikacije s Helmom?
Spremenili bomo vrednosti, poslane Helmu. Običajno so to vrednosti, ki se nadomestijo namesto oznake slike. V primeru najnovejšega, ki se pogosto uporablja za neproduktivna okolja, je spremenljiva informacija pripis, ki je za sam Kubernetes neuporaben, za Helm pa bo deloval kot signal, da je treba posodobiti aplikacijo. Možnosti izpolnjevanja vrednosti opombe:
- Naključna vrednost z uporabo standardne funkcije -
{{ randAlphaNum 6 }}.
Obstaja opozorilo: po vsaki uvedbi z uporabo grafikona s takšno spremenljivko bo vrednost opombe edinstvena in Helm bo domneval, da so spremembe. Izkazalo se je, da bomo aplikacijo vedno znova zagnali, tudi če nismo spremenili njene različice. To ni kritično, saj ne bo izpadov, vendar je še vedno neprijetno. - Prilepite trenutno datum in čas -
{{ .Release.Date }}.
Različica je podobna naključni vrednosti s trajno edinstveno spremenljivko. - Bolj pravilen način je uporaba kontrolne vsote. To je SHA slike ali SHA zadnje objave v git -
{{ .Values.sha }}.
Treba jih bo prešteti in poslati odjemalcu Helm na klicni strani, na primer v Jenkins. Če se je aplikacija spremenila, se bo spremenila tudi kontrolna vsota. Zato bo Helm posodobil aplikacijo le, ko bo to potrebno.
Povzemimo naše poskuse
- Helm izvaja spremembe na najmanj invaziven način, zato nobena sprememba na ravni slike aplikacije v registru Docker ne bo povzročila posodobitve: po izvedbi ukaza se ne bo zgodilo nič.
- Ključ
--forceuporablja se za obnovitev problematičnih izdaj in ni povezan z vsiljenimi posodobitvami. - Ključ
--recreate-podsbo prisilno posodobil aplikacije, vendar bo to storil na vandalen način: nenadoma bo izklopil vse vsebnike. Uporabniki bodo zaradi tega trpeli; tega ne bi smeli početi v produkciji. - Neposredno spremenite gručo Kubernetes z ukazom
kubectl editne: porušili bomo doslednost in vedenje se bo razlikovalo glede na različico Helma. - Z izdajo nove različice Helma se je pojavilo veliko odtenkov. Težave v repozitoriju Helm so opisane v jasnem jeziku in vam bodo pomagale razumeti podrobnosti.
- Če grafikonu dodate opombo, ki jo je mogoče urejati, bo ta bolj prilagodljiv. To vam bo omogočilo pravilno uvajanje aplikacije brez izpadov.
Misel o "svetovnem miru", ki deluje na vseh področjih življenja: preberite navodila pred uporabo, ne po njej. Le s popolnimi informacijami bo mogoče zgraditi zanesljive sisteme in osrečiti uporabnike.
Druge povezane povezave:
To poročilo je bilo prvič predstavljeno na avtor Mail.ru Cloud Solutions. Poglej druge predstave in se naročite na obvestila o dogodkih na Telegramu .
Vir: www.habr.com