🥇Helm'i struktuur ja selle peidetud probleemid

Typhon freight hauler concept, Anton Swanepoel

Minu nimi on Dmitri Sugrobov, olen arendaja «Leroy Merlinis». Artiklis räägin, miks on Helm vajalik, kuidas see lihtsustab Kubernetesega töötamist, mis on muutunud kolmandas versioonis ja kuidas selle abil uuendada rakendusi tootmises seisaku ajal.

See on kokkuvõte konverentsi ettekandest @Kubernetes Conference by Mail.ru Pilve Lahendused — kui te ei soovi lugeda, vaadake videot.

Miks me kasutame Kubernetesit tootmises

«Leroy Merlin» on DIY-kaubanduse turuliider Venemaal ja Euroopas. Meie ettevõttes töötab üle saja arendaja, 33 000 sisemist töötajat ja tohutu hulk inimesi, kes külastavad hüpermarketeid ja veebisaiti. Kõigi nende õnnelikuks tegemiseks otsustasime järgida tööstuse standardseid lähenemisviise. Arendame uusi rakendusi mikroteenuste arhitektuuri kasutades, kasutame keskkondade isolatsiooniks ja õigeks tarnimiseks konteinerit, ning orkestreerimisel Kubernetesit. Orkestreerijate kasutamise hind langeb kiiresti: turul suureneb inseneride arv, kes valdab tehnoloogiat, ja ilmuvad teenusepakkujad, kes pakuvad Kubernetesit teenusena.

Kõik, mida Kubernetes teeb, on loomulikult võimalik teha ka muul viisil, näiteks skriptides mõne Jenkinsiga ja docker-compose’iga, aga miks elu keerulisemaks teha, kui on olemas usaldusväärne lahendus? Seetõttu jõudsime Kubernetesini ja oleme seda juba aasta tootmises kasutanud. Praegu on meil kakskümmend neli Kubernetes klastrit, kõige vanem neist on üle aasta vana, selles on umbes kakssada podi.

Paljude YAML-failide needus Kuberneteses

Mikroteenuse 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-failidest, kolmanda jaoks veel ühe ja nii edasi. Korruta dokumentide arv keskkondade arvuga ja saame juba sadu faile, ja see ei arvestagi dünaamilisi keskkondi.

Adam Reese, Helm'i põhihooldaja, tutvustas mõistet «Arendussükkel Kuberneteses», mis näeb välja nii:

Copy YAML — kopeeri YAML-fail.
Paste YAML — kleebi see.
Fix Indents — paranda sisesid.
Repeat — korda uuesti.

Variant on töökindel, kuid tuleb palju kordi YAML-faile kopeerida. Selle ringi muutmiseks leiutati Helm.

Mis on Helm

Esiteks, Helm — paketihaldur, mis aitab leida ja installida vajalikke programme. Näiteks MongoDB installimiseks ei pea ametlikule veebisaidile minema ja binaare alla laadima, piisab käsu täitmisest helm install stable/mongodb.

Teiseks, Helm — malligeneraator, mis aitab failide parametriseerimisel. Naaseme Kuberneteses YAML-failide olukorra juurde. Lihtsam on kirjutada sama YAML-fail, lisada sinna mõned kohatäitjad, kuhu Helm sobitab väärtused. Teisisõnu, selle asemel, et kasutada suurt hulka YAML-e, on olemas mallide kogum (šabloonid), kuhu õigel ajal sobitatakse vajalikud väärtused.

Kolmandaks, Helm — paigalduse meister. Selle abil saab installida, tagasi pöörata ja uuendada rakendusi. Vaatame, kuidas seda teha.

Kuidas kasutada Helmi oma rakenduste paigaldamiseks

Installime Helmi kliendi arvutisse, järgides ametlikku juhendis. Seejärel loome komplekti YAML-failidest. Konkreetsete väärtuste näitamise asemel jätame kohatäitjad, mille Helmi hiljem teabega täidab. Sellesugust failide kogumit nimetatakse Helmi kaardiks. Helmi konsooli kliendile saab selle saata kolmel viisil:

näidates mallide kausta;
pakendades .tar arhiivi ja viidates sellele;
paneme šablooni kaugrepositorysse ja lisame linki repo Helmi kliendile.

Veel on vajalik väärtuste fail — values.yaml. Siit saadud andmed sobitatakse šablooni. Loome selle samuti.

Teises Helmi versioonis on lisanduv serveri rakendus — Tiller. See asub Kubernetesest väljaspool ja ootab Helmi kliendi päringuid ning sobitab nõutud väärtused šablooni ja saadab need Kubernetesesse.

Helm 3 on lihtsam: šabloonide töötlemise asemel serveris töödeldakse info nüüd täielikult Helmi kliendi poolel ja saadetakse otse Kubernetes API-le. See lihtsustus suurendab klastrite turvalisust ja lihtsustab levitamisstrateegiat.

Kuidas see kõik töötab

Käivitame käsu helm install. Näitame rakenduse väljaande nime, määrame teed values.yaml failini. Lõpus nimetame repository, kus kaardi asub, ja kaardi nime. Näiteks on need 'lmru' ja 'bestchart'.

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

Käsku saab täita ainult üks kord. Korduva täitmise korral asemel install tuleb kasutada upgrade. Lihtsuse huvides võib kasutada kahte käsku ühe käskude kombinatsioonina upgrade lisavõtmega --installEsimese käivitamise korral saadab Helm käsu väljaande installimiseks ja edaspidi uuendab seda.

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

Uute versioonide rakendamise probleemid Helmiga

Selle loo juures mängin saalis „Kes tahab saada miljonäriks” ja selgitame välja, kuidas sundida Helmi rakenduse versiooni värskendama. Vaata videot.

Kui uurisin Helmi tööd, üllatas mind kummaline käitumine, kui proovisin käivitatud rakenduste versioone värskendada. Rakenduskoodi uuendasin, laadisin Docker registrisse uue pildi, saatsin käskluse rakenduse käivitamiseks – ja midagi ei juhtunud. Allpool on mõned mitte just kõige paremad viisid rakenduste värskendamiseks. Igaüht neist sügavamalt uurides hakkad mõistma tööriista sisemist ülesehitust ja põhjuseid selle ebaselge käitumise taha.

Viis 1. Mitte muuta teavet alates viimati käivitamisest

Kuidas ütleb ametlik veebisait Helm, „Kubernetesi graafikud võivad olla suured ja keerulised, seetõttu püüab Helm mitte midagi liiga tihti muuta.” Seega, kui uuendada pildi latest versiooni Docker registris ja käivitada käsk helm upgrade, siis ei juhtu midagi. Helm arvab, et midagi ei ole muutunud ja seetõttu ei pea Kubernetes'ele rakenduse värskendamise käsku saatma.

Siin ja edaspidi on tag 'latest' näidatud vaid näitena. Selle sildi määramisel laadib Kubernetes igal korral pildi Docker registrist, sõltumata imagePullPolicy parameetrist. 'Latest' kasutamine tootmises on soovitatav vältida ja võib põhjustada kõrvaltoimeid.

Viis 2. Värskendada LABELi imajas

Nagu on öeldud samas dokumentatsioon, „Helm värskendab rakendust, ainult kui see on muutunud alates viimase väljaande.” Loogiliseks variandiks tundub olla LABEL'i sildi värskendamine ise Docker-pildis. Siiski, Helm ei piilu rakenduste piltidesse ja ei tea nende muutustest. Seetõttu, kui sildi värskendamisel on eeldatav, et Helm neist teada ei saa ja rakenduse värskendamise käsk Kubernetes'esse ei jõua.

Viis 3. Kasutada võtmeid --force

Vaatame manuaale ja otsime vajalikke võtmeid. Kõige rohkem sobib konteksti võtme --force. Hoolimata kõnelevast nimest, käitumine erineb ootamatust. Selle asemel, et sundida rakendust värskendama, on selle tegelik eesmärk taastada FAILED olekus oleva versiooni. Kui seda võtit ei kasutata, tuleb järjestikku teostada käske. helm delete && helm install --replace. Selle asemel soovitatakse kasutada võtit --force, mis automatiseerib nende käskude järjestikulise täitmise. Rohkem teavet leiate sellest pull-requestist.. Et öelda Helmile, et rakenduse versioon ikkagi uuendada, ei sobi kahjuks see võti.

Viis 4. Muuda labels otse Kuberneteses.

Labeli otse uuendamine klastris käsu abil kubectl edit — halb mõte. See tegevus toob kaasa teabe järjepidevuse rikkumise töötava rakenduse ja selle vahel, mis algselt saadeti juurutamiseks. Helmi käitumine juurutamisel on sel juhul erinev selle versioonist: Helm 2 ei tee midagi, samas kui Helm 3 juurutab rakenduse uue versiooni. Selle põhjuse mõistmiseks tuleb aru saada, kuidas Helm töötab.

Kuidas Helm töötab?

Et määrata, kas rakendus on viimasest väljaandest alates muutunud, võib Helm kasutada:

Kuberneteses käivitatud rakendust;
uut values.yaml faili ja asjakohast chart'i;
Helmi siseteavet väljaannete kohta.

Kõige uudishimu üle: kus Helm salvestab siseteabe väljaannete kohta?Käsku täites helm history, saame kogu teabe versioonide kohta, mis on Helmi abil installitud.

Seal on ka üksikasjalik teave saadetud mallide ja väärtuste kohta. Saame seda küsida:

Helmi teises versioonis on see teave samas nimiruumis, kus Tiller töötab (vaikimisi — kube-system), ConfigMap'is, mis on märgistatud sildiga 'OWNER=TILLER':

Kolmanda versiooni saabudes kolis teave saledatesse, kes töötab samas nimiruumis, kus rakendus on käimas. See võimaldas samal ajal käitada mitut rakendust erinevates nimiruumides sama väljaande nimega. Teises versioonis oli see tõsine peavalu, kuna nimiruumid on isoleeritud, kuid saavad omavahel mõjutada.

Teine Helm, kui ta üritab aru saada, kas uuendamine on vajalik, kasutab ainult kahte teabeallikat: seda, mida talle praegu pakuti, ja siseteavet väljaannete kohta, mis on ConfigMap'is.

Kolmas Helm kasutab kolme ühinemise strateegiat: lisaks sellele teabele arvestab ta ka rakendusega, mis hetkel Kuberneteses töötab.

Seetõttu ei tee vana versioon Helm midagi, kuna see ei arvestanud klastri rakenduse infot, kuid Helm 3 saab muudatused ja saadab uue rakenduse väljastamiseks.

Viis meetodit. Kasutada võtme —recreate-pods

Võtme --recreate-pods abil on võimalik saavutada seda, mida algselt sooviti saavutada võtme --force. Konteinerid taaskäivituvad ja vastavalt poliitikale imagePullPolicy: Always märgis latest (sellest oli juba eespool juttu) laadib Kubernetes alla ja käivitab uue pildi versiooni. Kuid see toimub mitte eriti hästi: jättes tähelepanuta StrategyType juurutuse, lülitab see järsku välja kõik vanad rakenduse instantsid ja hakkab käivitama uusi. Taaskäivitamise ajal süsteem ei tööta, kasutajad kannatavad.

Kuberneteses oli sarnane probleem pikka aega. Ja nüüd, neli aastat pärast probleemi avastamist Probleem, on probleem lahendatud ning alates 1.15 versioonist on Kuberneteses võimalik tehtud podide rolling-restart.

Helm lihtsalt lõpetab kõik rakendused ja käivitab kõrval uued konteinerid. Tootmisrežiimis ei tohi niimoodi teha, et mitte tekitada rakenduse seiskumist. Seda tuleks teha ainult arenduse vajadusteks, seda saab teostada ainult etapi keskkondades.

Kuidas uuendada rakenduse versiooni Helmiga?

Muudame Helmile edastatavaid väärtusi. Reeglina on need väärtused, mis asendavad pildi sildi. Juhul, kui kasutatakse latest, mida sageli kasutatakse mitteproduktiivsetes keskkondades, on muudetav teave märk, mis on Kubernetesile kasutu, kuid Helmile annab signaali rakenduse uuendamise vajadusest. Annootatsiooni väärtuste täitmise variandid:

Juhuslik väärtus kasutades standardfunktsiooni — {{ randAlphaNum 6 }}.
On nüanss: pärast iga juurutamist selle chardi abil, millel on selline muutujaväärtus, on annootatsiooni väärtus ainulaadne ning Helm arvab, et on muutused. Seega taaskäivitame rakenduse alati, isegi kui me ei ole selle versiooni muutnud. See ei ole kriitiline, kuna seismist ei tule, aga siiski ebameeldiv.
Sisestada praegune kuupäev ja kellaaeg — {{ .Release.Date }}.
Variant on sarnane juhuslikule väärtusele, kuid pidevalt ainulaadse muutujaga.
Õigeim viis on kasutada kontrollsummad. See on SHA pildi või SHA viimase git commit'i — {{ .Values.sha }}.
Need tuleb arvestada ja saata Helm klientile kutsuva poole, näiteks Jenkinsis. Kui rakendus muutub, muutub ka kontrollsumma. Seega uuendab Helm rakendust ainult siis, kui see on vajalik.

Kokkuvõtteks meie katsetest

Helm teeb muudatused võimalikult vähem invasiivsel viisil, seega ei too rakenduse pildi tasemel muutmine Docker Registry's kaasa uuendamist: käsu täitmisel ei juhtu midagi.
Võti --force kasutatakse probleemsete versioonide taastamiseks ning ei ole seotud sunduuendamisega.
Võti --recreate-pods sunduuendab rakendusi, kuid teeb seda vandalismi meetodil: sulgeb järsult kõik konteinerid. Selle tagajärjel kannatavad kasutajad, tootmises ei tohiks seda teha.
Otse Kubernetes klastrisse muudatuste tegemine käsu abil kubectl edit ei ole vajalik: see rikub järjepidevust ja käitumine sõltub Helm'i versioonist.
Uue Helm'i versiooni väljaandmisega on tulnud palju nüansse. Issues Helm'i hoidlas on selgelt kirjeldatud ning need aitavad detailides selgust saada.
Muudetava annotatsiooni lisamine charti muudab selle paindlikumaks. See võimaldab rakenduse õigesti juurutada, ilma seisakuteta.

Mõte, mis kehtib igas eluvaldkonnas: loe juhendit enne kasutamist, mitte pärast. Ainult täielikku teavet omades on võimalik ehitada usaldusväärseid süsteeme ja teha kasutajaid õnnelikuks.

Teised seotud lingid:

See ettekande kuulutati esmakordselt @Kubernetes Conference Mail.ru Cloud Solutions poolt. Näe video teisi ettekandeid ja jälgi ürituste teadaandeid Telegramis Kubernetesest Mail.ru Groupis.

Allikas: habr.com