Volám sa Dmitrij Sugrobov, som vývojár v Leroy Merlin. V tomto článku vám poviem, prečo je Helm potrebný, ako zjednodušuje prácu s Kubernetes, čo sa zmenilo v tretej verzii a ako ho použiť na aktualizáciu aplikácií vo výrobe bez prestojov.
Toto je zhrnutie založené na prejave na konferencii by - ak nechcete čítať, pozrite si video.
Prečo používame Kubernetes vo výrobe
Leroy Merlin je lídrom na maloobchodnom trhu pre domácich majstrov v Rusku a Európe. Naša spoločnosť má viac ako sto vývojárov, 33 000 interných zamestnancov a obrovské množstvo ľudí navštevujúcich hypermarkety a webovú stránku. Aby boli všetci spokojní, rozhodli sme sa postupovať podľa štandardných priemyselných prístupov. Vývoj nových aplikácií pomocou architektúry mikroslužieb; používať kontajnery na izoláciu prostredia a zabezpečiť správne doručenie; a na orchestráciu použite Kubernetes. Cena používania orchestrátorov sa rapídne znižuje: na trhu rastie počet inžinierov, ktorí ovládajú túto technológiu, a objavujú sa poskytovatelia, ktorí ponúkajú Kubernetes ako službu.
Všetko, čo robí Kubernetes, sa dá samozrejme robiť aj inak, napríklad prekrytím niektorých Jenkinov a docker-compose skriptami, ale prečo si komplikovať život, ak existuje hotové a spoľahlivé riešenie? Preto sme prišli do Kubernetes a už rok ho používame vo výrobe. V súčasnosti máme dvadsaťštyri klastrov Kubernetes, z ktorých najstarší má viac ako rok, s asi dvesto tobolkami.
Prekliatie veľkých súborov YAML v Kubernetes
Na spustenie mikroslužby v Kubernetes vytvoríme aspoň päť súborov YAML: pre Deployment, Service, Ingress, ConfigMap, Secrets – a pošleme ich do klastra. Pre ďalšiu aplikáciu napíšeme rovnaký balík džemov, s tretím napíšeme ďalší atď. Ak vynásobíme počet dokumentov počtom prostredí, dostaneme už stovky súborov, a to ešte neberieme do úvahy dynamické prostredia.
Adam Reese, hlavný správca spoločnosti Helm, predstavil koncept „“, ktorý vyzerá takto:
- Kopírovať YAML – skopírujte súbor YAML.
- Prilepiť YAML – prilepiť.
- Opraviť zarážky - opraviť zarážky.
- Opakovať - opakovať znova.
Táto možnosť funguje, ale súbory YAML musíte skopírovať mnohokrát. Na zmenu tohto cyklu bol vynájdený Helm.
Čo je Helm
Po prvé, Helm - správca balíkov, ktorý vám pomôže nájsť a nainštalovať programy, ktoré potrebujete. Ak chcete nainštalovať napríklad MongoDB, nemusíte ísť na oficiálnu webovú stránku a sťahovať binárne súbory, stačí spustiť príkaz helm install stable/mongodb.
Po druhé, Helm - nástroj šablón, pomáha parametrizovať súbory. Vráťme sa k situácii so súbormi YAML v Kubernetes. Jednoduchšie je napísať rovnaký súbor YAML, pridať doň nejaké zástupné symboly, do ktorých Helm nahradí hodnoty. To znamená, že namiesto veľkej sady lešení bude existovať sada šablón, do ktorých budú v správnom čase nahradené požadované hodnoty.
Po tretie, Helm - majstra nasadenia. S ním môžete inštalovať, vrátiť späť a aktualizovať aplikácie. Poďme zistiť, ako to urobiť.
Ako používať Helm na nasadenie vlastných aplikácií
Nainštalujte klienta Helm do vášho počítača podľa oficiálnych pokynov . Ďalej vytvoríme sadu súborov YAML. Namiesto špecifikovania konkrétnych hodnôt ponecháme zástupné symboly, ktoré Helm doplní informáciami v budúcnosti. Súbor takýchto súborov sa nazýva Helmova tabuľka. Dá sa odoslať klientovi konzoly Helm tromi spôsobmi:
- označiť priečinok so šablónami;
- zabaľte archív do .tar a ukážte naň;
- vložte šablónu do vzdialeného úložiska a pridajte odkaz na úložisko v klientovi Helm.
Potrebujete tiež súbor s hodnotami - values.yaml. Údaje odtiaľ sa vložia do šablóny. Poďme si ho tiež vytvoriť.
Druhá verzia Helm má ďalšiu serverovú aplikáciu - Tiller. Visí mimo Kubernetes a čaká na požiadavky od klienta Helm a po zavolaní nahradí požadované hodnoty do šablóny a odošle ju Kubernetes.
Helm 3 je jednoduchší: namiesto spracovania šablón na serveri sa informácie teraz spracúvajú výlučne na strane klienta Helm a odosielajú sa priamo do Kubernetes API. Toto zjednodušenie zlepšuje bezpečnosť klastra a uľahčuje schému zavádzania.
Ako to celé funguje
Spustite príkaz helm install. Označme názov vydania aplikácie a cestu k hodnotám.yaml. Na konci uvedieme úložisko, v ktorom sa graf nachádza a názov grafu. V tomto príklade sú to „lmru“ a „bestchart“.
helm install --name bestapp --values values.yaml lmru/bestchart
Príkaz možno vykonať iba raz, keď sa namiesto toho vykoná znova install treba použiť upgrade. Pre jednoduchosť môžete namiesto dvoch príkazov spustiť príkaz upgrade s prídavným kľúčom --install. Pri prvom spustení Helm odošle príkaz na inštaláciu vydania a v budúcnosti ho aktualizuje.
helm upgrade --install bestapp --values values.yaml lmru/bestchart
Úskalia nasadzovania nových verzií aplikácie s Helm
V tomto bode príbehu hrám s publikom Kto chce byť milionárom a vymýšľame, ako prinútiť Helma, aby aktualizoval verziu aplikácie. .
Keď som sa učil, ako Helm funguje, prekvapilo ma zvláštne správanie pri pokuse o aktualizáciu verzií spustených aplikácií. Aktualizoval som kód aplikácie, nahral nový obrázok do registra Docker, odoslal príkaz na nasadenie - a nič sa nestalo. Nižšie sú uvedené niektoré nie úplne úspešné spôsoby aktualizácie aplikácií. Podrobnejším štúdiom každého z nich začnete chápať vnútornú štruktúru nástroja a dôvody tohto nie zrejmého správania.
Metóda 1. Nemeňte informácie od posledného spustenia
Ako sa hovorí Helm: "Grafy Kubernetes môžu byť veľké a zložité, takže Helm sa snaží ničoho príliš nedotýkať." Ak teda aktualizujete najnovšiu verziu obrazu aplikácie v registri dockerov a spustíte príkaz helm upgrade, tak sa nič nestane. Helm si bude myslieť, že sa nič nezmenilo a nie je potrebné posielať príkaz Kubernetes na aktualizáciu aplikácie.
Tu a nižšie je najnovšia značka zobrazená iba ako príklad. Keď zadáte túto značku, Kubernetes stiahne obrázok z registra docker zakaždým, bez ohľadu na parameter imagePullPolicy. Používanie najnovších produktov vo výrobe je nežiaduce a spôsobuje vedľajšie účinky.
Metóda 2. Aktualizujte LABEL na obrázku
Ako je napísané v tom istom "Helm aktualizuje aplikáciu iba vtedy, ak sa od posledného vydania zmenila." Zdá sa, že logickou možnosťou je aktualizácia LABEL v samotnom obrázku doku. Helm sa však do obrázkov aplikácie nepozerá a o žiadnych zmenách na nich netuší. Preto pri aktualizácii štítkov v obraze o nich Helm nebude vedieť a príkaz na aktualizáciu aplikácie sa neodošle do Kubernetes.
Metóda 3: Použite kľúč --force
Obráťme sa na manuály a hľadajme potrebný kľúč. Kľúč dáva najväčší zmysel --force. Napriek jasnému názvu sa správanie líši od očakávania. Namiesto vynútenia aktualizácie aplikácie je jej skutočným účelom obnovenie vydania, ktoré je v stave FAILED. Ak tento kľúč nepoužívate, musíte príkazy vykonávať postupne helm delete && helm install --replace. Namiesto toho sa odporúča použiť kľúč --force, ktorý automatizuje postupné vykonávanie týchto príkazov. Viac informácií v tomto . Tento kľúč, žiaľ, nebude fungovať, aby ste Helmu povedali, aby aktualizoval verziu aplikácie.
Metóda 4. Zmeňte štítky priamo v Kubernetes
Aktualizácia štítku priamo v klastri pomocou príkazu kubectl edit - zlý nápad. Táto akcia povedie k nesúladu informácií medzi spustenou aplikáciou a tou, ktorá bola pôvodne odoslaná na nasadenie. Správanie Helmu počas nasadenia sa v tomto prípade líši od jeho verzie: Helm 2 neurobí nič a Helm 3 nasadí novú verziu aplikácie. Aby ste pochopili prečo, musíte pochopiť, ako Helm funguje.
Ako Helm funguje?
Ak chcete zistiť, či sa aplikácia od posledného vydania zmenila, Helm môže použiť:
- spustenie aplikácie v Kubernetes;
- nové hodnoty.yaml a aktuálny graf;
- Helmove interné informácie o vydaní.
Pre zvedavejších: kde Helm uchováva interné informácie o vydaniach?Vykonaním príkazu helm history, získame všetky informácie o verziách nainštalovaných pomocou Helm.
Nechýbajú ani podrobné informácie o odoslaných šablónach a hodnotách. Môžeme o to požiadať:
V druhej verzii Helm sa tieto informácie nachádzajú v rovnakom mennom priestore, kde je spustený Tiller (predvolene systém kube), v ConfigMap, označený štítkom „OWNER=TILLER“:
Keď sa objavila tretia verzia Helm, informácie sa presunuli do tajomstiev a do rovnakého menného priestoru, kde bola spustená aplikácia. Vďaka tomu bolo možné spustiť niekoľko aplikácií súčasne v rôznych menných priestoroch s rovnakým názvom vydania. V druhej verzii to bola vážna bolesť hlavy, keď sú menné priestory izolované, ale môžu sa navzájom ovplyvňovať.
Druhý Helm, keď sa snaží pochopiť, či je potrebná aktualizácia, používa iba dva zdroje informácií: to, čo sa mu poskytuje teraz, a interné informácie o vydaniach, ktoré sa nachádzajú v ConfigMap.
Tretí Helm používa stratégiu trojcestného zlúčenia: okrem týchto informácií berie do úvahy aj aplikáciu, ktorá práve beží v Kubernetes.
Z tohto dôvodu stará verzia Helm neurobí nič, keďže neberie do úvahy informácie o aplikácii v klastri, ale Helm 3 prijme zmeny a odošle novú aplikáciu na nasadenie.
Metóda 5. Použite prepínač --recreate-pods
S kľúčom --recreate-pods kľúčom môžete dosiahnuť to, čo ste pôvodne plánovali dosiahnuť --force. Kontajnery sa reštartujú a podľa zásady imagePullPolicy: Always pre najnovšiu značku (viac o tom v poznámke pod čiarou vyššie), Kubernetes stiahne a spustí novú verziu obrázka. Nebude to urobené najlepším spôsobom: bez zohľadnenia StrategyType nasadenia sa náhle vypnú všetky staré inštancie aplikácií a začnú sa spúšťať nové. Počas reštartu systém nebude fungovať, používatelia budú trpieť.
V samotnom Kubernetes podobný problém tiež existoval už dlho. A teraz, 4 roky po otvorení , problém bol vyriešený a počnúc verziou 1.15 Kubernetes sa objavuje možnosť opätovného spustenia modulov.
Helm jednoducho vypne všetky aplikácie a spustí nové kontajnery v blízkosti. Nemôžete to urobiť vo výrobe, aby ste nespôsobili prestoje aplikácie. Toto je potrebné len pre potreby vývoja a môže sa vykonávať iba v prostredí javiska.
Ako aktualizovať verziu aplikácie pomocou Helm?
Zmeníme hodnoty odoslané Helmu. Zvyčajne ide o hodnoty, ktoré sa nahradia namiesto značky obrázka. V prípade najnovšej, ktorá sa často používa pre neproduktívne prostredia, je meniteľnou informáciou anotácia, ktorá je pre samotný Kubernetes zbytočná a pre Helmu bude pôsobiť ako signál pre potrebu aktualizácie aplikácie. Možnosti vyplnenia hodnoty anotácie:
- Náhodná hodnota pomocou štandardnej funkcie -
{{ randAlphaNum 6 }}.
Existuje upozornenie: po každom nasadení pomocou grafu s takouto premennou bude hodnota anotácie jedinečná a Helm bude predpokladať, že došlo k zmenám. Ukazuje sa, že aplikáciu vždy reštartujeme, aj keď sme jej verziu nezmenili. Toto nie je kritické, pretože nedôjde k prestojom, ale stále je to nepríjemné. - Vložiť prúd dátum a čas -
{{ .Release.Date }}.
Variant je podobný náhodnej hodnote s trvalo jedinečnou premennou. - Správnejším spôsobom je použitie kontrolné súčty. Toto je SHA obrázka alebo SHA posledného odovzdania v git -
{{ .Values.sha }}.
Bude potrebné ich spočítať a odoslať klientovi Helm na strane volania, napríklad v Jenkins. Ak sa aplikácia zmenila, kontrolný súčet sa zmení. Preto Helm aktualizuje aplikáciu iba v prípade potreby.
Zhrňme si naše pokusy
- Helm robí zmeny najmenej invazívnym spôsobom, takže akákoľvek zmena na úrovni obrazu aplikácie v registri Docker nebude mať za následok aktualizáciu: po vykonaní príkazu sa nič nestane.
- kľúč
--forcepoužíva sa na obnovu problematických vydaní a nie je spojená s vynútenými aktualizáciami. - kľúč
--recreate-podsnásilne aktualizuje aplikácie, ale urobí to vandalským spôsobom: náhle vypne všetky kontajnery. Používatelia tým budú trpieť; nemali by ste to robiť vo výrobe. - Priamo vykonajte zmeny v klastri Kubernetes pomocou príkazu
kubectl editnie: narušíme konzistenciu a správanie sa bude líšiť v závislosti od verzie Helm. - S vydaním novej verzie Helm sa objavilo veľa nuancií. Problémy v archíve Helm sú popísané jasným jazykom, pomôžu vám pochopiť podrobnosti.
- Pridaním upraviteľnej anotácie do grafu bude graf flexibilnejší. To vám umožní spustiť aplikáciu správne, bez prestojov.
Myšlienka „svetového mieru“, ktorá funguje vo všetkých oblastiach života: prečítajte si návod pred použitím, nie po ňom. Iba s úplnými informáciami bude možné vybudovať spoľahlivé systémy a urobiť radosť používateľom.
Ďalšie súvisiace odkazy:
Táto správa bola prvýkrát prezentovaná na od Mail.ru Cloud Solutions. Pozri iné predstavenia a prihláste sa na odber oznamov o udalostiach na Telegrame .
Zdroj: hab.com