Myn namme is Dmitry Sugrobov, ik bin in ûntwikkelder by Leroy Merlin. Yn dit artikel sil ik jo fertelle wêrom't Helm nedich is, hoe't it it wurkjen mei Kubernetes ferienfâldiget, wat is feroare yn 'e tredde ferzje, en hoe't jo it brûke om applikaasjes yn produksje te aktualisearjen sûnder downtime.
Dit is in gearfetting basearre op in taspraak op in konferinsje by - as jo net wolle lêze, sjoch dan de fideo.
Wêrom brûke wy Kubernetes yn produksje
Leroy Merlin is in lieder yn 'e DIY retailmerk yn Ruslân en Europa. Us bedriuw hat mear as hûndert ûntwikkelders, 33 ynterne meiwurkers en in grut oantal minsken dy't hypermerken en de webside besykje. Om se allegear lokkich te meitsjen, hawwe wy besletten om oanpak fan yndustrystandert te folgjen. Untwikkelje nije applikaasjes mei help fan microservice-arsjitektuer; brûke konteners om omjouwings te isolearjen en soargje foar goede levering; en brûk Kubernetes foar orkestraasje. De priis fan it brûken fan orkestrators wurdt hurd goedkeaper: it oantal yngenieurs dy't bekwaam binne yn 'e technology groeit op 'e merke, en oanbieders ferskine dy't Kubernetes as tsjinst oanbiede.
Alles wat Kubernetes docht, kin fansels op oare manieren dien wurde, bygelyks troch guon Jenkins te dekken en docker-compose mei skripts, mar wêrom komplisearje it libben as d'r in klearmakke en betroubere oplossing is? Dêrom kamen wy by Kubernetes en brûke wy it no in jier yn produksje. Wy hawwe op it stuit fjouwerentweintich Kubernetes-klusters, wêrfan de âldste mear as in jier âld is, mei sa'n twahûndert peulen.
De flok fan grutte YAML-bestannen yn Kubernetes
Om in mikrotsjinst yn Kubernetes te starten, sille wy op syn minst fiif YAML-bestannen oanmeitsje: foar ynset, tsjinst, yngong, ConfigMap, geheimen - en stjoere se nei it kluster. Foar de folgjende applikaasje sille wy itselde pakket mei jambs skriuwe, mei de tredde sille wy in oare skriuwe, ensfh. As wy it oantal dokuminten fermannichfâldigje mei it oantal omjouwings, krije wy al hûnderten bestannen, en dit wurdt noch net rekken holden mei dynamyske omjouwings.
Adam Reese, kearnûnderhâlder fan Helm, yntrodusearre it konsept fan "", dy't der sa útsjocht:
- Kopiearje YAML - kopiearje in YAML-bestân.
- Plak YAML - plak it.
- Fix ynspringen - fix ynspringen.
- Werhelje - werhelje wer.
De opsje wurket, mar jo moatte de YAML-bestannen in protte kearen kopiearje. Om dizze syklus te feroarjen, waard Helm útfûn.
Wat is Helm
Earst, Helm - pakket manager, dy't jo helpt om de programma's te finen en te ynstallearjen dy't jo nedich binne. Om bygelyks MongoDB te ynstallearjen, hoege jo net nei de offisjele webside te gean en binaries te downloaden, gewoan it kommando útfiere helm install stable/mongodb.
Twad, Helm - template motor, helpt by it parameterisearjen fan bestannen. Litte wy weromgean nei de situaasje mei YAML-bestannen yn Kubernetes. It is makliker om itselde YAML-bestân te skriuwen, wat plakhâlders ta te foegjen, wêryn Helm de wearden sil ferfange. Dat is, ynstee fan in grutte set steigers, sil d'r in set sjabloanen wêze wêryn de fereaske wearden op it krekte momint wurde ferfongen.
Tredde, Helm - ynset master. Mei it kinne jo applikaasjes ynstallearje, weromdraaie en bywurkje. Litte wy útfine hoe't jo dit dwaan.
Hoe kinne jo Helm brûke om jo eigen applikaasjes yn te setten
Litte wy de Helm-kliïnt op jo kompjûter ynstallearje, folgje de offisjele . Dêrnei meitsje wy in set fan YAML-bestannen. Yn stee fan in spesifisearje spesifike wearden, wy sille ferlitte plakhâlders, dy't Helm sil folje mei ynformaasje yn 'e takomst. In set fan sokke bestannen wurdt in Helm-diagram neamd. It kin op trije manieren nei de Helm-konsole-kliïnt stjoerd wurde:
- in map oanjaan mei sjabloanen;
- pak it argyf yn in .tar en wiis derop;
- set it sjabloan yn in repository op ôfstân en foegje in keppeling ta nei it repository yn 'e Helm-kliïnt.
Jo hawwe ek in bestân nedich mei wearden - values.yaml. De gegevens dêrwei wurde ynfoege yn it sjabloan. Litte wy it ek meitsje.
De twadde ferzje fan Helm hat in ekstra serverapplikaasje - Tiller. It hinget bûten Kubernetes en wachtet op oanfragen fan 'e Helm-kliïnt, en as oproppen, ferfangt de fereaske wearden yn it sjabloan en stjoert it nei Kubernetes.
Helm 3 is ienfâldiger: ynstee fan sjabloanen op 'e server te ferwurkjen, wurdt ynformaasje no folslein ferwurke oan' e Helm-kliïntkant en direkt nei de Kubernetes API stjoerd. Dizze ferienfâldiging ferbetteret klusterfeiligens en fasilitearret it útrolskema.
Hoe wurket it allegear
Run it kommando helm install. Litte wy de namme fan 'e applikaasje-útjefte oanjaan en it paad jaan oan values.yaml. Oan 'e ein sille wy it repository oanjaan wêryn't de kaart leit en de namme fan 'e kaart. Yn it foarbyld binne dit respektivelik "lmru" en "bestchart".
helm install --name bestapp --values values.yaml lmru/bestchart
It kommando kin mar ien kear útfierd wurde, as it ynstee wer útfierd wurdt install moatte brûke upgrade. Foar ienfâld, ynstee fan twa kommando's, kinne jo it kommando útfiere upgrade mei ekstra kaai --install. As it foar de earste kear útfierd wurdt, sil Helm in kommando stjoere om de release te ynstallearjen, en sil it yn 'e takomst bywurkje.
helm upgrade --install bestapp --values values.yaml lmru/bestchart
Fallefallen fan it ynsetten fan nije ferzjes fan in applikaasje mei Helm
Op dit punt yn it ferhaal spielje ik Who Wants to Be a Millionaire mei it publyk, en wy sykje út hoe't Helm de ferzje fan 'e app kin bywurkje. .
Doe't ik learde hoe't Helm wurket, waard ik ferrast troch frjemd gedrach by it besykjen om ferzjes fan rinnende applikaasjes te aktualisearjen. Ik haw de applikaasjekoade bywurke, in nije ôfbylding uploade nei it Docker-register, it ynsetkommando stjoerde - en neat barde. Hjirûnder binne wat net hielendal suksesfolle manieren om applikaasjes te aktualisearjen. Troch elk fan har yn mear detail te studearjen, begjinne jo de ynterne struktuer fan it ynstrumint te begripen en de redenen foar dit net foar de hân lizzende gedrach.
Metoade 1. Feroarje gjin ynformaasje sûnt de lêste lansearring
As it seit Helm, "Kubernetes-kaarten kinne grut en kompleks wêze, dus Helm besiket neat te folle oan te reitsjen." Dêrom, as jo de lêste ferzje fan 'e applikaasjeôfbylding yn it docker-register bywurkje en it kommando útfiere helm upgrade, dan bart der neat. Helm sil tinke dat neat is feroare en d'r is gjin need nedich om in kommando nei Kubernetes te stjoeren om de applikaasje te aktualisearjen.
Hjir en hjirûnder wurdt de lêste tag allinich as foarbyld werjûn. As jo dizze tag oantsjutte, sil Kubernetes elke kear de ôfbylding downloade fan it docker-register, nettsjinsteande de parameter imagePullPolicy. It brûken fan lêste yn produksje is net winsklik en feroarsake side-effekten.
Metoade 2. Update LABEL yn ôfbylding
Lykas skreaun yn itselde , "Helm sil in applikaasje allinich bywurkje as it is feroare sûnt de lêste release." In logyske opsje hjirfoar liket it LABEL te aktualisearjen yn 'e dockerôfbylding sels. Helm sjocht lykwols net yn 'e applikaasje-ôfbyldings en hat gjin idee oer feroaringen dêryn. Sadwaande, by it bywurkjen fan labels yn 'e ôfbylding, sil Helm der net oer witte, en it kommando foar applikaasje-update sil net nei Kubernetes stjoerd wurde.
Metoade 3: Brûk in kaai --force
Litte wy nei de hantliedingen gean en sykje nei de fereaske kaai. De kaai makket it measte sin --force. Nettsjinsteande de foar de hân lizzende namme is it gedrach oars as ferwachte. Yn stee fan in applikaasje-fernijing te twingen, is it echte doel it herstellen fan in release dy't yn FAILED-status is. As jo dizze kaai net brûke, moatte jo de kommando's sequentially útfiere helm delete && helm install --replace. It wurdt oanrikkemandearre om ynstee de kaai te brûken --force, dy't de opienfolgjende útfiering fan dizze kommando's automatisearret. Mear ynformaasje yn dizze . Om Helm te fertellen om de applikaasjeferzje te aktualisearjen, sil dizze kaai spitigernôch net wurkje.
Metoade 4. Feroarje labels direkt yn Kubernetes
It bywurkjen fan label direkt yn it kluster mei it kommando kubectl edit - min idee. Dizze aksje sil liede ta inkonsistinsje fan ynformaasje tusken de rinnende applikaasje en dejinge dy't oarspronklik stjoerd is foar ynset. It gedrach fan Helm by ynset yn dit gefal ferskilt fan syn ferzje: Helm 2 sil neat dwaan, en Helm 3 sil de nije ferzje fan 'e applikaasje ynsette. Om te begripen wêrom, moatte jo begripe hoe't Helm wurket.
Hoe wurket Helm?
Om te bepalen as in applikaasje is feroare sûnt de lêste release, kin Helm brûke:
- rinnende applikaasje yn Kubernetes;
- nije values.yaml en aktuele grafyk;
- Helm syn ynterne release ynformaasje.
Foar de mear nijsgjirrige: wêr bewarret Helm ynterne ynformaasje oer releases?Troch it kommando út te fieren helm history, sille wy alle ynformaasje krije oer de ferzjes dy't ynstalleare binne mei Helm.
D'r is ek detaillearre ynformaasje oer de ferstjoerde sjabloanen en wearden. Wy kinne it oanfreegje:
Yn 'e twadde ferzje fan Helm leit dizze ynformaasje yn deselde nammeromte wêr't Tiller rint (kube-systeem standert), yn 'e ConfigMap, markearre mei it label "OWNER=TILLER":
Doe't de tredde ferzje fan Helm ferskynde, ferhuze de ynformaasje nei geheimen, en nei deselde nammeromte wêr't de applikaasje rûn. Hjirmei waard it mooglik om ferskate applikaasjes tagelyk út te fieren yn ferskate nammeromten mei deselde releasenamme. Yn de twadde ferzje wie it in serieuze hoofdpijn as nammeromten isolearre binne, mar inoar beynfloedzje kinne.
De twadde Helm, as jo besykje te begripen oft in fernijing nedich is, brûkt mar twa boarnen fan ynformaasje: wat der no oan wurdt levere, en ynterne ynformaasje oer releases, dy't leit yn 'e ConfigMap.
De tredde Helm brûkt in trije-wize gearfoegingsstrategy: neist dy ynformaasje hâldt it ek rekken mei de applikaasje dy't no yn Kubernetes rint.
Om dizze reden sil de âlde ferzje fan Helm neat dwaan, om't it gjin rekken hâldt mei de applikaasjeynformaasje yn it kluster, mar Helm 3 sil de wizigingen ûntfange en de nije applikaasje foar ynset stjoere.
Metoade 5. Brûk de --recreate-pods switch
Mei in kaai --recreate-pods kinne jo berikke wat jo oarspronklik pland te berikken mei de kaai --force. De konteners sille opnij starte en, neffens de imagePullPolicy: Altyd belied foar de lêste tag (mear oer dit yn 'e fuotnoat hjirboppe), sil Kubernetes in nije ferzje fan' e ôfbylding downloade en lansearje. Dit sil net op 'e bêste manier dien wurde: sûnder rekken te hâlden mei it StrategyType fan ynset, sil it alle âlde applikaasje-eksimplaren abrupt útsette en nije begjinne te lansearjen. Tidens it opstarten sil it systeem net wurkje, brûkers sille lije.
Yn Kubernetes sels bestie ek al langer in ferlykber probleem. En no, 4 jier nei de iepening , it probleem is reparearre, en begjinnend mei ferzje 1.15 fan Kubernetes, ferskynt de mooglikheid om pods opnij te begjinnen.
Helm skeakelt gewoan alle applikaasjes út en lanseart nije konteners yn 'e buert. Jo kinne dit net dwaan yn 'e produksje, om gjin downtime fan applikaasje te feroarsaakjen. Dit is allinich nedich foar ûntwikkelingsbehoeften en kin allinich útfierd wurde yn poadiumomjouwings.
Hoe kinne jo de applikaasjeferzje bywurkje mei Helm?
Wy sille de wearden feroarje nei Helm. Typysk binne dit wearden dy't wurde ferfongen yn plak fan 'e ôfbyldingstag. Yn it gefal fan lêste, dy't faak brûkt wurdt foar ûnproduktive omjouwings, is de feroarjende ynformaasje in annotaasje, dy't nutteloos is foar Kubernetes sels, en foar Helm sil it fungearje as in sinjaal foar de needsaak om de applikaasje te aktualisearjen. Opsjes foar it ynfoljen fan de annotaasjewearde:
- Willekeurige wearde mei help fan de standertfunksje -
{{ randAlphaNum 6 }}.
D'r is in warskôging: nei elke ynset mei in diagram mei sa'n fariabele sil de annotaasjewearde unyk wêze, en Helm sil oannimme dat d'r feroaringen binne. It docht bliken dat wy de applikaasje altyd opnij starte, sels as wy de ferzje net hawwe feroare. Dit is net kritysk, want der sil gjin downtime, mar it is noch altyd onaangenaam. - Plak aktuele Datum en tiid -
{{ .Release.Date }}.
In fariant is gelyk oan in willekeurige wearde mei in permanint unike fariabele. - In mear korrekte manier is te brûken checksums. Dit is de SHA fan 'e ôfbylding as de SHA fan' e lêste commit yn 'e git -
{{ .Values.sha }}.
Se sille moatte wurde teld en stjoerd nei de Helm-kliïnt oan 'e ropende kant, bygelyks yn Jenkins. As de applikaasje is feroare, dan sil de kontrôlesum feroarje. Dêrom sil Helm de applikaasje allinich bywurkje as it nedich is.
Litte wy ús besykjen gearfetsje
- Helm makket wizigingen op 'e minst invasive manier, dus elke feroaring op it nivo fan tapassingôfbylding yn' e Docker Registry sil net resultearje yn in update: neat sil barre nei't it kommando is útfierd.
- Key
--forcebrûkt om problematyske releases te herstellen en is net ferbûn mei twongen updates. - Key
--recreate-podssil applikaasjes krêftich bywurkje, mar sil it dwaan op in fandale manier: it sil alle konteners abrupt útsette. Brûkers sille hjir lêst fan hawwe; jo moatte dit net dwaan yn produksje. - Meitsje wizigingen direkt oan it Kubernetes-kluster mei it kommando
kubectl editnet dwaan: wy sille brekke gearhing, en it gedrach sil ferskille ôfhinklik fan 'e ferzje fan Helm. - Mei de frijlitting fan 'e nije ferzje fan Helm binne in protte nuânses ferskynd. Problemen yn it Helm-repository wurde yn dúdlike taal beskreaun, se sille jo helpe om de details te begripen.
- It tafoegjen fan in bewurkbere annotaasje oan in diagram sil it fleksibeler meitsje. Hjirmei kinne jo de applikaasje korrekt útrolje, sûnder downtime.
In "wrâldfrede" gedachte dy't wurket op alle gebieten fan it libben: lês de ynstruksjes foar gebrûk, net nei. Allinich mei folsleine ynformaasje sil it mooglik wêze om betroubere systemen te bouwen en brûkers lokkich te meitsjen.
Oare relatearre keppelings:
Dit rapport waard foar it earst presintearre by troch Mail.ru Cloud Solutions. Sjen oare optredens en abonnearje op oankundigings fan eveneminten op Telegram .
Boarne: www.habr.com