🥇Uređaj Helm i njegove zamke

Koncept kamiona Typhon, Anton Swanepoel

Moje ime je Dmitrij Sugrobov, ja sam programer u Leroy Merlinu. U članku ću vam reći zašto je Helm potreban, kako pojednostavljuje rad sa Kubernetesom, šta se promijenilo u trećoj verziji i kako ga koristiti za ažuriranje aplikacija u proizvodnji bez zastoja.

Ovo je sažetak zasnovan na govoru na konferenciji @Kubernetes Conference by Mail.ru Cloud rješenja Ako ne želite da čitate, pogledajte video.

Zašto koristimo Kubernetes u proizvodnji

Leroy Merlin je lider na maloprodajnom tržištu DIY u Rusiji i Evropi. Naša kompanija ima više od stotinu programera, 33 internih zaposlenih i ogroman broj ljudi koji posećuju hipermarkete i sajt. Kako bismo ih sve usrećili, odlučili smo se držati industrijskih standarda. Razviti nove aplikacije koristeći mikroservisnu arhitekturu; koristiti kontejnere za izolaciju okruženja i ispravnu isporuku; a za orkestraciju koristite Kubernetes. Cijena korištenja orkestratora ubrzano postaje jeftinija: broj inženjera koji posjeduju tehnologiju raste na tržištu, a pojavljuju se provajderi koji nude Kubernetes kao uslugu.

Sve što Kubernetes radi, naravno, može da se uradi i na druge načine, na primer, zamazivanje nekog Jenkinsa i docker-composea sa skriptama, ali čemu komplikovati život ako postoji gotovo i pouzdano rešenje? Stoga smo došli do Kubernetesa i koristimo ga u proizvodnji već godinu dana. Sada imamo dvadeset četiri Kubernetes klastera, od kojih je najstariji star više od godinu dana i ima oko dvije stotine mahuna.

Prokletstvo velikog broja YAML datoteka u Kubernetesu

Da bismo pokrenuli mikroservis u Kubernetesu, kreiraćemo najmanje pet YAML fajlova: za Deployment, Service, Ingress, ConfigMap, Secrets - i poslati ih u klaster. Za sljedeću aplikaciju napisaćemo isti paket yamlikija, sa trećim - još jedan, i tako dalje. Množenjem broja dokumenata sa brojem okruženja, već dobijamo stotine fajlova, a to čak ni ne uzimajući u obzir dinamička okruženja.

Adam Reese, Helmov glavni održavatelj, predstavio je koncept "Razvojni ciklus u Kubernetesu", koji izgleda ovako:

Kopiraj YAML - kopiraj YAML fajl.
Zalijepi YAML - zalijepi.
Popravi uvlake - popravi uvlake.
Ponovite - ponovite ponovo.

Opcija radi, ali morate više puta kopirati YAML datoteke. Da bi promijenili ovaj ciklus, smislili su Helm.

Šta je kormilo

Prvo, Helm menadžer paketa, koji vam pomaže da pronađete i instalirate programe koji su vam potrebni. Da biste instalirali, na primjer, MongoDB, ne morate ići na službenu web stranicu i preuzimati binarne datoteke, samo pokrenite naredbu helm install stable/mongodb.

Drugo, Helm - šablonski mehanizam, pomaže pri parametriziranju datoteka. Vratimo se na situaciju sa YAML fajlovima u Kubernetesu. Lakše je napisati istu YAML datoteku, dodati joj neke čuvare mjesta, u kojima će Helm zamijeniti vrijednosti. Odnosno, umjesto velikog skupa yamlikova, postojat će skup šablona (šablona) u koje će potrebne vrijednosti biti zamijenjene u pravo vrijeme.

Treće, Helm - čarobnjak za implementaciju. Pomoću njega možete instalirati, vratiti i ažurirati aplikacije. Hajde da vidimo kako to uraditi.

Kako koristiti Helm za implementaciju vlastitih aplikacija

Instalirajte Helm klijent na računar, prateći zvanični uputstva. Zatim ćemo kreirati set YAML datoteka. Umjesto specificiranja specifičnih vrijednosti, ostavimo čuvare mjesta koje će Helm popunjavati informacijama u budućnosti. Skup takvih datoteka naziva se Helm chart. Može se poslati klijentu Helm konzole na tri načina:

odredite folder sa šablonima;
spakujte u .tar arhivu i pokažite na nju;
stavite šablon u udaljeno spremište i dodajte vezu do spremišta u Helm klijentu.

Također vam je potreban fajl sa vrijednostima - values.yaml. Podaci odatle će biti zamijenjeni u šablonu. Kreirajmo i njega.

Druga verzija Helma ima dodatnu serversku aplikaciju pod nazivom Tiller. Visi izvan Kubernetesa i čeka zahtjeve Helm klijenta, a kada se pozove, zamjenjuje potrebne vrijednosti u šablonu i šalje ga Kubernetesu.

Helm 3 je jednostavniji: umjesto obrade šablona na serveru, informacije se sada u potpunosti obrađuju na strani Helm klijenta i šalju direktno u Kubernetes API. Ovo pojednostavljenje poboljšava sigurnost klastera i olakšava šemu uvođenja.

Kako to sve funkcionira

Pokrenite komandu helm install. Navedite ime izdanja aplikacije, dajte putanju do values.yaml. Na kraju ćemo navesti spremište koje sadrži grafikon i naziv grafikona. U primjeru, to su "lmru" i "bestchart" respektivno.

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

Izvršenje naredbe je moguće samo jednom, pri ponovnom izvršavanju umjesto install potrebno koristiti upgrade. Radi jednostavnosti, umjesto dvije komande, možete pokrenuti naredbu upgrade sa dodatnim ključem --install. Prilikom prvog izvršavanja, Helm će poslati naredbu za instalaciju izdanja, au budućnosti će ga ažurirati.

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

Zamke implementacije novih verzija aplikacije s Helmom

U ovom trenutku u priči, igram se s publikom Tko želi biti milioner i smišljamo kako natjerati Helma da ažurira verziju aplikacije. Pogledajte video.

Kada sam proučavao Helmov rad, bio sam iznenađen čudnim ponašanjem pri pokušaju ažuriranja verzija pokrenutih aplikacija. Ažurirao sam kod aplikacije, uploadovao novu sliku u docker registar, poslao naredbu za implementaciju - i ništa se nije dogodilo. Ispod su neki ne tako dobri načini za ažuriranje aplikacija. Detaljnije proučavajući svaki od njih, počinjete razumjeti unutrašnju strukturu instrumenta i razloge za ovo neočigledno ponašanje.

Metoda 1. Nemojte mijenjati informacije od posljednjeg pokretanja

Kak glasit službena web stranica Helm, "Kubernetes grafikoni mogu biti veliki i složeni, tako da Helm pokušava da stvari budu što jednostavnije." Stoga, ako ažurirate najnoviju verziju slike aplikacije u docker registru i pokrenete naredbu helm upgrade, onda se ništa neće dogoditi. Helm će misliti da se ništa nije promijenilo i da nema potrebe da šalje naredbu Kubernetesu za ažuriranje aplikacije.

U nastavku je najnovija oznaka prikazana samo kao primjer. Kada je ova oznaka navedena, Kubernetes će preuzeti sliku iz docker registra svaki put, bez obzira na parametar imagePullPolicy. Upotreba najnovijeg u proizvodnji je nepoželjna i izaziva nuspojave.

Metoda 2. Ažurirajte LABEL na slici

Kako piše u istom dokumentaciju, "Helm će ažurirati aplikaciju samo ako se promijenila od posljednjeg izdanja." Logična opcija za ovo bi bila ažuriranje LABEL-a u samoj docker slici. Međutim, Helm ne gleda u slike aplikacije i nije svjestan bilo kakvih promjena na njima. Shodno tome, prilikom ažuriranja oznaka na slici, Helm neće znati za njih, a naredba za ažuriranje aplikacije neće biti primljena u Kubernetes.

Metod 3. Koristite ključ --force

Okrenimo se priručnicima i potražimo pravi ključ. Ključ koji ima najviše smisla --force. Uprkos upečatljivom imenu, ponašanje se razlikuje od očekivanog. Umjesto prisilnog ažuriranja aplikacije, njena prava svrha je da vrati izdanje koje je u statusu FAILED. Ako ne koristite ovaj ključ, tada morate uzastopno izvršavati naredbe helm delete && helm install --replace. Umjesto toga, predlaže se korištenje ključa --force, koji automatizuje sekvencijalno izvršavanje ovih naredbi. Više informacija u ovome pull request. Kako bi Helm rekao da ažurira verziju aplikacije, nažalost, ovaj ključ neće raditi.

Metod 4. Promenite oznake direktno u Kubernetesu

Ažuriranje oznake direktno u klasteru pomoću naredbe kubectl edit - loša ideja. Ova radnja će dovesti do nedosljednosti informacija između pokrenute aplikacije i one koja je prvobitno poslana na implementaciju. Ponašanje Helm-a tokom implementacije u ovom slučaju se razlikuje od njegove verzije: Helm 2 neće učiniti ništa, a Helm 3 će implementirati novu verziju aplikacije. Da biste razumjeli razlog, morate razumjeti kako Helm funkcionira.

Kako Helm radi

Da utvrdi da li se aplikacija promijenila od posljednjeg izdanja, Helm može koristiti:

pokrenuta aplikacija u Kubernetesu;
nove vrijednosti.yaml i trenutni grafikon;
Helmove interne informacije o izdanju.

Za one koji su radoznali: gdje Helm pohranjuje interne informacije o izdanju?Izvršavanjem naredbe helm history, dobićemo sve informacije o verzijama instaliranim pomoću Helma.

Tu su i detaljne informacije o poslanim obrascima i vrijednostima. Možemo zatražiti:

U drugoj verziji Helm-a, ove informacije se nalaze u istom imenskom prostoru gdje je pokrenut Tiller (podrazumevano, kube-system), u ConfigMap-u, označenom oznakom “OWNER=TILLER”:

U trenutku pojavljivanja treće verzije Helm-a, informacije su se preselile u tajne, štaviše, u isti imenski prostor u kojem je pokrenuta aplikacija. Zahvaljujući tome, postalo je moguće pokrenuti nekoliko aplikacija istovremeno u različitim imenskim prostorima s istim imenom izdanja. U drugoj verziji, to je bila teška glavobolja kada su prostori imena izolovani, ali mogu uticati jedni na druge.

Drugi Helm, kada pokušava da shvati da li je potrebno ažuriranje, koristi samo dva izvora informacija: ono što mu je sada pruženo i interne informacije o izdanjima, koje se nalaze u ConfigMap-u.

Treći Helm koristi trosmjernu strategiju spajanja: pored tih informacija, uzima u obzir i aplikaciju koja je trenutno pokrenuta u Kubernetesu.

Iz tog razloga, stara verzija Helma neće učiniti ništa, jer ne uzima u obzir informacije aplikacije u klasteru, ali će Helm 3 primiti promjene i poslati novu aplikaciju na implementaciju.

Metod 5: Koristite --recreate-pods ključ

Sa ključem --recreate-pods možete postići ono što je prvobitno planirano da se dobije pomoću ključa --force. Kontejneri će se ponovo pokrenuti i, u skladu sa politikom imagePullPolicy: Uvijek za najnoviju oznaku (više o tome u gornjoj fusnoti), Kubernetes će preuzeti i pokrenuti novu verziju slike. To neće biti učinjeno na najbolji način: bez uzimanja u obzir StrategyType implementacije, naglo će isključiti sve stare instance aplikacije i krenuti na pokretanje novih. Tokom ponovnog pokretanja, sistem neće raditi, korisnici će patiti.

U samom Kubernetesu sličan problem takođe postoji već duže vreme. I sada, 4 godine nakon otvaranja Problem, problem je riješen, a počevši od verzije 1.15 Kubernetesa, pojavljuje se mogućnost rolling-restart podova.

Helm jednostavno isključuje sve aplikacije i pokreće nove kontejnere u blizini. U proizvodnji to ne možete učiniti kako ne biste izazvali jednostavnu aplikaciju. Ovo je potrebno samo za razvojne potrebe, može se raditi samo u scenskim okruženjima.

Kako ažurirati verziju aplikacije koristeći Helm?

Promijenit ćemo vrijednosti koje se šalju Helmu. Obično su to vrijednosti koje se zamjenjuju za oznaku slike. U slučaju najnovijeg, koji se često koristi za neproduktivna okruženja, anotacija djeluje kao promjenjiva informacija, što je beskorisno za sam Kubernetes, a za Helm će djelovati kao signal za ažuriranje aplikacije. Opcije popunjavanja vrijednosti napomene:

slučajna vrijednost koristeći standardnu funkciju {{ randAlphaNum 6 }}.
Postoji upozorenje: nakon svake implementacije pomoću grafikona s takvom varijablom, vrijednost napomene će biti jedinstvena, a Helm će pretpostaviti da postoje promjene. Ispostavilo se da ćemo uvijek ponovo pokrenuti aplikaciju, čak i ako nismo promijenili njenu verziju. Ovo nije kritično, jer neće biti zastoja, ali je ipak neugodno.
Umetnite struju datum i vrijeme - {{ .Release.Date }}.
Varijanta je poput nasumične vrijednosti sa trajno jedinstvenom varijablom.
Bolji način je korištenje kontrolne sume. Ovo je SHA slike ili SHA posljednjeg urezivanja u git-u - {{ .Values.sha }}.
Morat će se prebrojati i poslati Helm klijentu na strani koja poziva, na primjer u Jenkinsu. Ako se aplikacija promijenila, tada će se promijeniti i kontrolni zbroj. Stoga će Helm ažurirati aplikaciju samo kada je to potrebno.

Hajde da sumiramo naše napore

Helm vrši promjene na najmanje invazivan način, tako da bilo kakva promjena na nivou slike aplikacije u Docker Registry neće rezultirati ažuriranjem: ništa se neće dogoditi nakon što se naredba izvrši.
Ključ --force koristi se za popravak problematičnih izdanja i nije povezan s prisilnom nadogradnjom.
Ključ --recreate-pods će nasilno ažurirati aplikacije, ali će to učiniti na vandalski način: naglo će isključiti sve kontejnere. Korisnici će patiti od ovoga, ne isplati se to raditi na rasprodaji.
Direktno izvršite promjene u Kubernetes klasteru koristeći naredbu kubectl edit nemojte: narušit ćemo konzistentnost, a ponašanje će se razlikovati ovisno o verziji Helma.
Izlaskom nove verzije Helma pojavile su se mnoge nijanse. Problemi u Helm repozitorijumu su opisani jasnim jezikom, pomoći će vam da razumete detalje.
Dodavanje promjenjive napomene grafikonu učinit će ga fleksibilnijim. Ovo će omogućiti da se aplikacija pravilno pokrene, bez zastoja.

Misao iz kategorije "mir u svijetu", djelovanje u svim oblastima života: pročitajte upute prije upotrebe, a ne poslije. Samo uz potpune informacije biće moguće izgraditi pouzdane sisteme i usrećiti korisnike.

Ostali povezani linkovi:

Ovaj izvještaj je prvi put predstavljen na @Kubernetes Conference by Mail.ru Cloud Solutions. Vidi видео ostale nastupe i pretplatite se na najave događaja u Telegramu Oko Kubernetesa u Mail.ru grupi.

izvor: www.habr.com

Uređaj Helm i njegove zamke