Helm'i seade ja selle võimalikud probleemid

Typhon kaubaveo kontseptsioon, Anton Swanepoel

Minu nimi on Dmitri Sugrobov, olen arendaja ettevõttes 'Leroy Merlin'. Artikli eesmärk on rääkida, miks on Helm vajalik, kuidas see lihtsustab Kubernetes'ega töötamist, mis on muutunud kolmandas versioonis ja kuidas selle abil rakendusi tootmises katkematuks uuendada.

See on kokkuvõte kõnest konverentsil @Kubernetes Konverents by Mail.ru Cloud Solutions — kui te ei soovi lugeda, vaadake videot.

Miks me kasutame Kubernetes't tootmises

'Leroy Merlin' on DIY-jaemüügi turuliider Venemaal ja Euroopas. Meie ettevõttes on üle saja arendaja, 33 000 sisemist töötajat ja tohutu hulk inimesi, kes külastavad hüpermarketeid ja veebisaiti. Kõikide nende õnnelikuks tegemiseks otsustasime järgida tööstusharu standardseid lähenemisviise. Arendame uusi rakendusi, kasutades mikroteenuste arhitektuuri; keskkondade isoleerimiseks ja õige tarnimise tagamiseks kasutame konteinerite tehnoloogiat; ning orkestreerimiseks kasutame Kubernetes't. Orkestreerijate kasutushind väheneb kiiresti: turule tuleb üha rohkem insenere, kes valdavad tehnoloogiat, ja ilmuvad teenusepakkujad, kes pakuvad Kubernetes't teenusena.

Kõik, mida Kubernetes teeb, on muidugi võimalik teha ka muude meetoditega, näiteks kirjutades skripte Jenkinsile ja docker-compose'ile, kuid miks elamist keerulisemaks teha, kui on olemas valmis ja usaldusväärne lahendus? Seetõttu jõudsime Kuberneteseni, mida oleme kasutanud tootmises juba aasta. Praegu on meil kakskümmend neli Kubernetes'e klastrit, kõige vanem neist on üle aasta vana ja selles on umbes kakssada pod'i.

YAML-failide hulk Kuberneteses on tõeline nuhtlus.

Mikrosüsteemi käivitamiseks Kuberneteses loome vähemalt viis YAML-faili: Deployment, Service, Ingress, ConfigMap, Secrets — ja saadame need klastrisse. Järgmise rakenduse jaoks kirjutame sama komplekti YAML-faile, kolmandale lisame veel ühe ja nii edasi. Korrutades failide arvu keskkondade arvuga, saame juba sadu faile, ja see ei arvestagi dünaamilisi keskkondi.

Adam Reese, Helm'i peamine hooldaja, tutvustas mõistet „Arendusprotsess Kuberneteses”, mis näeb välja järgmine:

1. Kopeeri YAML — kopeeri YAML-fail.
2. Kleebi YAML — kleebi see sisse.
3. Paranda sisendid — paranda tükid.
4. Korrake — korda uuesti.

See variant töötab, kuid peab korduvalt YAML-faile kopeerima. Selle tsükli muutmiseks loodi Helm.

Mis on Helm

Esiteks, Helm — paketihaldur, mis aitab leida ja installida vajalikke programme. Näiteks MongoDB installimiseks ei ole vaja minna ametlikule veebisaidile ja allalaadimiseks bin faile, piisab käsu täitmisest helm install stable/mongodb.

Teiseks, Helm — šablonigeneraator, aitab parameteriseerida faile. Naaseme Kuberneteses YAML-failide olukorda. Sama YAML faili kirjutamine on lihtsam, kui lisada mõned kohandatavad väärtused, mida Helm vahetab. Ehk et suure hulga YAML-failide asemel on olemas šablonid (template'id), kuhu õigel ajal õiged väärtused sisse pannakse.

Kolmandaks, Helm — rakenduste juurutamise meister. Selle abil on võimalik installida, tagasi pöörduda ja värskendada rakendusi. Vaadakem, kuidas seda teha.

Kuidas kasutada Helmi oma rakenduste juurutamiseks

Installeerime Helm kliendi arvutisse, järgides ametlikku juhendis. Seejärel loome komplekti YAML-faile. Konkreetsete väärtuste määramise asemel jätame kohandatavad väärtused, mille Helm tulevikus täidab. Sellise failide komplekti nimetatakse Helm chart'iks. Helm'i konsoolikliendile saab selle edastada kolme viisi:

• näidata šablonite kausta;
• pakendada .tar arhiivi ja viidata sellele;
• asetage mall template kaugserverisse ja lisage link repositooriumisse Helm kliendis.

Me vajame ka väärtuste faili — values.yaml. Sealt olevad andmed asendatakse mallis. Loome selle ka.

Helm 2. versioonis on lisaks serverirakendus — Tiller. See asub väljaspool Kubernetes'i ja ootab päringuid Helm kliendilt ning kutsudes asendab vajalikud väärtused mallis ja saadab need Kubernetes'i.

Helm 3 on lihtsam: selle asemel, et töödelda malle serveris, töödeldakse teavet nüüd täielikult Helm kliendi poolel ja saadetakse otse Kubernetes API-le. See lihtsustus suurendab klasteri turvalisust ja lihtsustab juurutamise protsessi.

Kuidas see kõik töötab

Käivitame käsu helm install. Näitame rakenduse välja nime, anname teed values.yaml failini. Lõpus näitame repositooriumi, kus chart asub, ja charti nime. Näiteks on see «lmru» ja «bestchart» vastavalt.

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

Käsku saab teostada ainult üks kord, korduv täitmine asendab install peaks kasutama uuenda. Lihtsuse huvides võite kahte käsku asendada käsuga uuenda täiendava võtmega --install. Esimese käivitamise korral saadab Helm käsu versiooni installimiseks ja seejärel uuendab seda.

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

Uute versioonide rakendamise takistused Helmiga

Selles loo osas mängin ma saaliga mängu "Kes tahab saada miljonäriks" ja me selgitame välja, kuidas sundida Helmi rakenduse versiooni uuendama. Vaata videot.

Kui uurisin Helmi toimimist, üllatas mind kummaline käitumine rakenduste käivitatud versioonide uuendamisel. Rakenduse koodi uuendasin, Docker registry's laadisin uue pildi üles, saatsin käsu juurutamiseks – ja midagi ei juhtunud. Allpool on mõned mitte eriti hästi õnnestunud viisid rakenduste uuendamiseks. Igaühe põhjalikum uurimine aitab mõista tööriista sisemist ülesehitust ja sellise mitte ilmselge käitumise põhjuseid.

Meetod 1. Mitte muuta teavet alates viimati käivitamisest

Kuidas öeldakse ametlik veebisait Helm, "Kubernetesi graafikud võivad olla suured ja keerulised, seetõttu püüab Helm mitte segada">. Seega, kui uuendada rakenduse viimase versiooni pilt docker registry's ja käivitada käsk. helm upgrade, siis ei juhtu midagi. Helm arvab, et mitte midagi ei ole muutunud ja ei saada Kubernetes'e käsu rakenduse värskendamiseks.

Siin ja edaspidi on silt latest esitatud vaid näitena. Selle sildi määramisel laadib Kubernetes iga kord pildi docker registreerimisest, sõltumata parameetrist imagePullPolicy. Latest'i kasutamine tootmises ei ole soovitatav ja võib põhjustada kõrvaltoimeid.

Meetod 2. Värskenda LABEL'i pildis

Nagu on kirjutatud samas dokumentatsioonis, «Helm värskendab rakendust ainult siis, kui see on viimase väljaande ajast alates muutunud». Loogiline variant selle jaoks oleks LABEL'i märgi värskendamine otseselt docker-pildis. Siiski ei vaata Helm rakenduse pilte sisse ega tea nende muudatustest midagi. Seega ei saa Helm pilti tähistades neist teadlikuks, ja käsk rakenduse värskendamiseks Kubernetes'e ei väljastata.

Meetod 3. Kasuta võtit --force

Oleme juhtumid ja otsime vajalikku võtit. Kõige rohkem sobib tähenduse poolest võti --force. Kuigi nimi on ise rääkiv, erineb käitumine ootusest. Selle asemel, et rakendust sunduuendada, on selle tegelik eesmärk taastada FAILED seisundis olev väljaanne. Kui seda võtit ei kasutata, tuleb käsud järjestikku täita. helm delete && helm install --replace. Selle asemel on soovitatav kasutada võtit --force, mis automatiseerib nende käskude järjestikuse täitmise. Rohkem teavet leiate sellest pull requestist.. Kahjuks ei sobi see võti, et öelda Helmile rakenduse versiooni ikkagi uuendada.

Viis 4. Muuda etikette otse Kuberneteses

Etiketi otse muutmine klastris käsu abil kubectl edit on halb mõte. See tegevus toob kaasa teabe vastuolulisuse töötava rakenduse ja selle vahel, mis algselt saadeti juurutamiseks. Sellisel juhul erineb Helmi käitumine juurutamisel oma versioonist: Helm 2 ei tee midagi, samas kui Helm 3 juurutab uue rakenduse versiooni. Probleemi mõistmiseks on oluline mõista, kuidas Helm töötab.

Kuidas Helm töötab

Et määrata, kas rakendus on muutunud alates viimase väljaande versioonist, võib Helm kasutusele võtta:

• Kubernetes'is käimasoleva rakendusega;
• uus values.yaml ja актуальный чарт;
• Helmi sisemise teabega versioonide kohta.

Karmeim uurija: kus Helm salvestab sisemise teabe versioonide kohta?Käivitades käsu helm history, saame kogu teabe versioonide kohta, mis on Helmi abil installitud.

Lisaks on saadaval üksikasjalik teave saadetud malli ja väärtuste kohta. Saame neid küsida:

Teises versioonis asub see teave samas nimede ruumis, kus Tiller töötab (vaikimisi - kube-system), ConfigMap'is, mis on märgitud tunnusega «OWNER=TILLER»:

Kolmanda versiooni ilmumisel kolis teave saladustesse, jäädes samasse nimede ruumi, kus rakendus töötab. See võimaldas korraga käivitada mitu rakendust erinevates nimede ruumides, millel on sama versiooni nimi. Teises versioonis oli see suur peavalu, kuna nimede ruumid olid eraldatud, kuid said omavahel mõjutada.

Teine Helm, püüdes mõista, kas uuendust on vaja, kasutab ainult kahte teabeallikat: seda, mida talle praegu pakutakse, ja sisemist teavet versioonide kohta, mis asub ConfigMap'is.

Kolmas Helm kasutab kolme suuna ühinemise strateegiat: lisaks sellele, millele ta tähelepanu pöörab, arvestab ta ka rakendust, mis töötab praegu Kuberneteses.

Sel põhjusel ei tee vana versioon Helm midagi, kuna ta ei arvesta klastris oleva rakenduse teavet, kuid Helm 3 saab muudatused ja saadab uue rakenduse juurutamiseks.

Viis: Kasuta võtit —recreate-pods

Võtme abil --recreate-pods saab saavutada selle, mida algselt plaaniti saavutada võtmega --force. Konteinerid taaskäivituvad ja vastavalt imagePullPolicy: Always poliitikale, mis on seotud latest sildiga (selle kohta on mainitud eespool), laadib Kubernetes alla ja käivitab uue pildi versiooni. Seda tehakse mitte kõige paremal viisil: arvestamata juurutamise StrategyType’it, lülitab ta järsult välja kõik vana rakenduse instantsid ja hakkab käivitama uusi. Taaskäivitamise ajal ei tööta süsteem, kasutajad kannatavad.

Samas esines Kuberneteses sarnane probleem pikka aega. Ja voilà, neli aastat pärast probleemi avastamist Issue, probleem on lahendatud ja alates Kubernetes 1.15 versioonist on olemas võimalus podide rolling-restartiks.

Helm lihtsalt lukustab kõik rakendused ja käivitab kõrval uusi konteinerite. Toote keskkonnas ei tohi seda teha, et mitte põhjustada rakenduse seiskumist. Sellist käitumist on vaja ainult arenduse eesmärkidel ning seda võib teha ainult stseenikeskkondades.

Kuidas uuendada rakenduse versiooni Helmiga?

Muudame väärtusi, mis saadetakse Helmile. Reeglina on need väärtused, mis asendavad pildi sildi. Kui tegemist on 'latest' sildiga, mida sageli kasutatakse tootmises, siis on muudetav teave annotatsioon, mis Kubernetes'i jaoks on kasutu, kuid Helmile signaal uuendada rakendust. Annotatsiooni väärtuse täitmise variandid:

1. Juhuslik väärtus standardse funktsiooni abil — {{ randAlphaNum 6 }}.
   On üks nüanss: iga kord, kui rakendatakse seda muudatuste määratlemise charti, on annotatsiooni väärtus ainulaadne ning Helm arvab, et muudatusi on toimunud. Seega käivitame rakenduse alati uuesti, isegi kui me ei ole selle versiooni muutnud. See ei ole kriitiline, kuna seisakut ei toimu, aga siiski ebameeldiv.
2. Sisestada praegune kuupäev ja kellaaeg — {{ .Release.Date }}.
   Variant on juhuslik väärtus pidevalt unikaalse muutujaga.
3. Õigem viis on kasutada kontrollsummasid. See on SHA pildi või viimase git commit'i SHA — {{ .Values.sha }}.
   Need tuleb arvutada ja saata Helm kliendile kutsujapoolel, näiteks Jenkinsis. Kui rakendus muutub, muutub ka kontrollsumma. Seetõttu uuendab Helm rakendust ainult siis, kui on vajalik.

Kokkuvõtteks meie katsetest

• Helm teeb muudatused võimalikult vähe invasiivselt, seega ei too rakenduse pildi tasemel muudatus Docker Registry's kaasa uuendamist: pärast käsu täitmist ei toimu midagi.
• Ala --force kasutatakse probleemsete väljalaskude taastamiseks ja ei ole seotud sunduuendamisega.
• Ala --recreate-pods sunduuendab rakendusi, kuid teeb seda rüüstamise viisil: kustutab kõik konteinerid järsult. See kahjustab kasutajaid, seda ei tohiks tootmises teha.
• Otseselt muudatusi Kubernetese klastrisse käsu kubectl edit teha ei tohi: rikume järjepidevust ja käitumine sõltub Helm'i versioonist.
• Uue Helm versiooni ilmumisega on tulnud palju nüansse. Helm'i repostiitursis olevad küsimused on selgelt sõnastatud ja aitavad üksikasjadest aru saada.
• Muudetava annotatsiooni lisamine chart'ile muudab selle paindlikumaks. See võimaldab rakendust õigesti juurutada ilma seisakuteta.

Mõte, mida võiks nimetada 'rahuks kogu maailmas', toimib igas elu valdkonnas: loe juhendit enne kasutamist, mitte pärast. Ainult täieliku teabe omandamisega on võimalik ehitada usaldusväärseid süsteeme ja muuta kasutajad õnnelikuks.

Teemaga seotud muud lingid:

1. Tutvumine Helm 3
2. Helm ametlik veebileht
3. Helm'i repostiit GitHub'is
4. 25 kasulikku Kubernetes'i tööriista: juurutamine ja haldamine

See ettekannet kõlas esmakordselt @Kubernetes Konverents Mail.ru Cloud Solutions esitlus. Vaadake video teisi ettekandeid ja tellige ürituste teateid Telegramis Kubernetesest Mail.ru Grupis.

Allikas: habr.com