🥇Helm uređaj i njegove zamke

Koncept teretnog vozila Typhon, Anton Swanepoel

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

Ovo je sažetak temeljen na govoru na konferenciji @Kubernetes konferencija by Mail.ru Cloud rješenja — ako ne želite čitati, pogledajte video.

Zašto koristimo Kubernetes u proizvodnji

Leroy Merlin je lider na maloprodajnom tržištu DIY u Rusiji i Europi. Naša tvrtka ima više od stotinu programera, 33 internih zaposlenika i ogroman broj ljudi koji posjećuju hipermarkete i web stranicu. Kako bismo ih sve usrećili, odlučili smo slijediti standardne pristupe u industriji. Razviti nove aplikacije korištenjem mikroservisne arhitekture; koristiti spremnike za izolaciju okruženja i osigurati pravilnu isporuku; i koristiti Kubernetes za orkestraciju. Cijena korištenja orkestratora ubrzano pada: na tržištu raste broj inženjera koji poznaju tehnologiju, a pojavljuju se i provideri koji nude Kubernetes kao uslugu.

Sve što radi Kubernetes, naravno, može se napraviti i na druge načine, primjerice, pokriti neke Jenkinse i docker-compose sa skriptama, ali zašto komplicirati život ako postoji gotovo i pouzdano rješenje? Zato smo došli u Kubernetes i koristimo ga u produkciji već godinu dana. Trenutačno imamo dvadeset i četiri Kubernetes klastera, od kojih je najstariji star više od godinu dana, s oko dvjesto mahuna.

Prokletstvo velikih YAML datoteka u Kubernetesu

Kako bismo pokrenuli mikroservis u Kubernetesu, izradit ćemo najmanje pet YAML datoteka: za implementaciju, uslugu, ulaz, ConfigMap, tajne - i poslati ih u klaster. Za sljedeću aplikaciju ćemo napisati isti paket skele, za treću ćemo napisati još jednu, i tako dalje. Ako pomnožimo broj dokumenata s brojem okruženja, već ćemo dobiti stotine datoteka, a to još ne uzima u obzir dinamička okruženja.

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

Kopiraj YAML - kopirajte YAML datoteku.
Zalijepite YAML - zalijepite ga.
Fix Indents - popraviti uvlake.
Ponovi - ponovi opet.

Opcija radi, ali YAML datoteke morate kopirati mnogo puta. Da bi se promijenio ovaj ciklus, izumljen je Helm.

Što je Helm

Prvo, Helm - upravitelj paketa, koji vam pomaže pronaći i instalirati programe koji su vam potrebni. Da biste instalirali npr. MongoDB, ne morate ići na službenu stranicu i preuzimati binarne datoteke, samo pokrenite naredbu helm install stable/mongodb.

Drugo, Helm - mehanizam za predloške, pomaže u parametrizaciji datoteka. Vratimo se na situaciju s YAML datotekama u Kubernetesu. Lakše je napisati istu YAML datoteku, dodati joj neka rezervirana mjesta u koja će Helm zamijeniti vrijednosti. Odnosno, umjesto velikog skupa skela, postojat će skup predložaka u koje će se potrebne vrijednosti zamijeniti u pravo vrijeme.

Treće, Helm - voditelj postavljanja. Pomoću njega možete instalirati, vratiti i ažurirati aplikacije. Smislimo kako to učiniti.

Kako koristiti Helm za postavljanje vlastitih aplikacija

Instalirajmo Helm klijent na vaše računalo, slijedeći službeni instrukcije. Zatim ćemo stvoriti skup YAML datoteka. Umjesto navođenja specifičnih vrijednosti, ostavit ćemo rezervirana mjesta koja će Helm u budućnosti ispuniti informacijama. Skup takvih datoteka naziva se Helmov dijagram. Može se poslati klijentu Helm konzole na tri načina:

označite mapu s predlošcima;
zapakirajte arhivu u .tar i pokažite na nju;
stavite predložak u udaljeni repozitorij i dodajte vezu na repozitorij u Helm klijentu.

Također vam je potrebna datoteka s vrijednostima - values.yaml. Podaci odatle bit će umetnuti u predložak. Kreirajmo i mi.

Druga verzija Helma ima dodatnu poslužiteljsku aplikaciju - Tiller. Visi izvan Kubernetesa i čeka zahtjeve Helm klijenta, a kada se pozove, zamjenjuje tražene vrijednosti u predlošku i šalje ga Kubernetesu.

Helm 3 je jednostavniji: umjesto obrade predložaka na poslužitelju, informacije se sada u potpunosti obrađuju na Helm klijentskoj strani i šalju izravno u Kubernetes API. Ovo pojednostavljenje poboljšava sigurnost klastera i olakšava shemu uvođenja.

Kako to sve funkcionira

Pokrenite naredbu helm install. Naznačimo naziv izdanja aplikacije i dajmo put do values.yaml. Na kraju ćemo navesti repozitorij u kojem se grafikon nalazi i naziv grafikona. U primjeru, to su "lmru" odnosno "bestchart".

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

Naredba se može izvršiti samo jednom, kada se umjesto toga izvrši ponovno install treba koristiti upgrade. Radi jednostavnosti, umjesto dvije naredbe, možete pokrenuti naredbu upgrade s dodatnim ključem --install. Kada se prvi put izvrši, Helm će poslati naredbu za instaliranje izdanja i ažurirat će ga u budućnosti.

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

Zamke postavljanja novih verzija aplikacije s Helmom

U ovom trenutku u priči, igram s publikom Who Wants to Be a Millionaire i smišljamo kako natjerati Helma da ažurira verziju aplikacije. Gledaj video.

Dok sam učio kako Helm radi, iznenadilo me čudno ponašanje pri pokušaju ažuriranja verzija pokrenutih aplikacija. Ažurirao sam kod aplikacije, učitao novu sliku u Docker registar, poslao naredbu za implementaciju - i ništa se nije dogodilo. Ispod su neki ne baš uspješni načini ažuriranja aplikacija. Proučavajući svaki od njih detaljnije, počinjete razumjeti unutarnju strukturu instrumenta i razloge za ovo ne očito ponašanje.

Metoda 1. Nemojte mijenjati informacije od zadnjeg pokretanja

Kao što piše Službena web stranica Helm, "Kubernetes grafikoni mogu biti veliki i složeni, tako da Helm pokušava ništa ne dirati previše." 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 slati naredbu Kubernetesu za ažuriranje aplikacije.

Ovdje i dolje, najnovija oznaka prikazana je samo kao primjer. Kada navedete ovu oznaku, Kubernetes će preuzeti sliku iz docker registra svaki put, bez obzira na parametar imagePullPolicy. Korištenje najnovijih u proizvodnji je nepoželjno i uzrokuje nuspojave.

Metoda 2. Ažurirajte LABEL na slici

Kao što je napisano u istom dokumentacija, “Helm će ažurirati aplikaciju samo ako se promijenila od zadnjeg izdanja.” Čini se da je logična opcija za to ažuriranje LABEL-a u samoj docker slici. Međutim, Helm ne gleda u slike aplikacije i nema pojma o bilo kakvim promjenama na njima. Sukladno tome, prilikom ažuriranja oznaka na slici, Helm neće znati za njih, a naredba za ažuriranje aplikacije neće biti poslana Kubernetesu.

Metoda 3: Koristite ključ --force

Okrenimo se priručnicima i potražimo potrebni ključ. Ključ ima najviše smisla --force. Unatoč očitom nazivu, ponašanje je drugačije od očekivanog. Umjesto prisilnog ažuriranja aplikacije, njegova stvarna svrha je vratiti izdanje koje je u statusu FAILED. Ako ne koristite ovu tipku, morate izvršiti naredbe sekvencijalno helm delete && helm install --replace. Umjesto toga preporučuje se korištenje ključa --force, koji automatizira sekvencijalno izvršavanje ovih naredbi. Više informacija u ovom zahtjev za povlačenjem. Kako biste rekli Helmu da ažurira verziju aplikacije, ovaj ključ nažalost neće raditi.

Metoda 4. Promijenite oznake izravno u Kubernetesu

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

Kako djeluje Helm?

Kako bi utvrdio je li se aplikacija promijenila od zadnjeg izdanja, Helm može koristiti:

pokretanje aplikacije u Kubernetesu;
nove vrijednosti.yaml i trenutni grafikon;
Helmove interne informacije o izdanju.

Za znatiželjnije: gdje Helm pohranjuje interne informacije o izdanjima?Izvršenjem naredbe helm history, dobit ćemo sve informacije o verzijama instaliranim pomoću Helma.

Tu su i detaljne informacije o poslanim predlošcima i vrijednostima. Možemo zatražiti:

U drugoj verziji Helma, ove informacije se nalaze u istom prostoru imena gdje je pokrenut Tiller (kube-sustav prema zadanim postavkama), u ConfigMap-u, označene oznakom “OWNER=TILLER”:

Kada se pojavila treća verzija Helma, informacije su se preselile u tajne, i to u isti prostor imena u kojem je bila pokrenuta aplikacija. Zahvaljujući tome, postalo je moguće pokrenuti nekoliko aplikacija istovremeno u različitim imenskim prostorima s istim nazivom izdanja. U drugoj verziji bila je ozbiljna glavobolja kada su prostori imena izolirani, ali mogu utjecati jedni na druge.

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

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

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

Metoda 5. Koristite prekidač --recreate-pods

S ključem --recreate-pods možete postići ono što ste prvotno planirali postići pomoću ključa --force. Spremnici će se ponovno pokrenuti i, u skladu s pravilom 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 početi pokretati nove. Tijekom ponovnog pokretanja sustav neće raditi, korisnici će patiti.

U samom Kubernetesu također je dugo postojao sličan problem. I sada, 4 godine nakon otvaranja Izdanje, problem je riješen, a počevši od verzije 1.15 Kubernetesa, pojavljuje se mogućnost ponovnog pokretanja modula.

Helm jednostavno isključuje sve aplikacije i pokreće nove spremnike u blizini. To ne možete učiniti u produkciji kako ne biste uzrokovali prekid rada aplikacije. Ovo je potrebno samo za razvojne potrebe i može se izvesti samo u pozornici.

Kako ažurirati verziju aplikacije pomoću Helma?

Promijenit ćemo vrijednosti poslane Helmu. Obično su to vrijednosti koje se zamjenjuju umjesto oznake slike. U slučaju najnovijeg, koji se često koristi za neproduktivna okruženja, promjenjiva informacija je napomena, koja je beskorisna za sam Kubernetes, a za Helm će djelovati kao signal za potrebu ažuriranja aplikacije. Opcije za popunjavanje vrijednosti napomene:

Slučajna vrijednost koristeći standardnu funkciju - {{ randAlphaNum 6 }}.
Postoji upozorenje: nakon svake implementacije pomoću grafikona s takvom varijablom, vrijednost napomene bit će jedinstvena, a Helm će pretpostaviti da postoje promjene. Ispada da ćemo uvijek ponovno pokrenuti aplikaciju, čak i ako nismo promijenili njezinu verziju. Ovo nije kritično, jer neće biti zastoja, ali je svejedno neugodno.
Zalijepi trenutni Datum i vrijeme - {{ .Release.Date }}.
Varijanta je slična slučajnoj vrijednosti s trajno jedinstvenom varijablom.
Ispravniji način je korištenje kontrolni zbrojevi. Ovo je SHA slike ili SHA posljednjeg urezivanja u git-u - {{ .Values.sha }}.
Trebat će ih prebrojati i poslati Helm klijentu na pozivajućoj strani, na primjer u Jenkinsu. Ako se aplikacija promijenila, promijenit će se i kontrolni zbroj. Stoga će Helm ažurirati aplikaciju samo kada je to potrebno.

Rezimirajmo naše pokušaje

Helm vrši promjene na najmanje invazivan način, tako da svaka promjena na razini slike aplikacije u Docker registru neće rezultirati ažuriranjem: ništa se neće dogoditi nakon što se naredba izvrši.
ključ --force koristi se za vraćanje problematičnih izdanja i nije povezan s prisilnim ažuriranjima.
ključ --recreate-pods nasilno će ažurirati aplikacije, ali će to učiniti na vandalski način: naglo će isključiti sve spremnike. Korisnici će zbog toga patiti; ne biste to trebali raditi u proizvodnji.
Izravno napravite promjene u Kubernetes klasteru pomoću naredbe kubectl edit nemojte: narušit ćemo dosljednost, a ponašanje će se razlikovati ovisno o verziji Helma.
Izlaskom nove verzije Helma pojavile su se mnoge nijanse. Problemi u Helm repozitoriju opisani su jasnim jezikom, pomoći će vam da razumijete detalje.
Dodavanje napomene koja se može uređivati grafikonu će ga učiniti fleksibilnijim. To će vam omogućiti ispravno postavljanje aplikacije, bez prekida rada.

Misao o "svjetskom miru" koja djeluje u svim područjima života: pročitajte upute prije uporabe, a ne nakon. Samo s potpunim informacijama moguće je izgraditi pouzdane sustave i učiniti korisnike zadovoljnima.

Ostali povezani linkovi:

Ovo je izvješće prvi put predstavljeno na @Kubernetes konferencija od Mail.ru Cloud Solutions. Izgled video ostale izvedbe i pretplatite se na najave događaja na Telegramu Oko Kubernetesa u Mail.ru grupi.

Izvor: www.habr.com

Uređaj Helm i njegove zamke