Volám sa Dmitrij Sugrobov, som vývojár vo „Lerua Merlen“. V článku vysvetlím, prečo je Helm potrebný, ako uľahčuje prácu s Kubernetes, čo sa zmenilo v tretej verzii a ako pomocou neho aktualizovať aplikácie na produkcii bez prestojov.
Toto je stručný prehľad na základe vystúpenia na konferencii od — ak nechcete čítať, pozrite si video.
Prečo používame Kubernetes na produkcii
„Lerua Merlen“ je lídrom na trhu DIY maloobchodu v Rusku a Európe. Naša spoločnosť má viac ako sto vývojárov, 33 000 zamestnancov a nespočetné množstvo ľudí, ktorí navštevujú hypermarkety a web. Aby sme ich všetkých urobili šťastnými, rozhodli sme sa dodržiavať štandardné prístupy v priemysle. Vyvíjať nové aplikácie s využitím mikroslužbovej architektúry; na izoláciu prostredí a správnu distribúciu používať kontajnery; a na orchestráciu používať Kubernetes. Cena používania orchestrátorov rýchlo klesá: na trhu rastie počet inžinierov, ktorí ovládajú technológiu, objavujú sa poskytovatelia ponúkajúci Kubernetes ako službu.
Všetko, čo robí Kubernetes, sa dá samozrejme urobiť aj inými spôsobmi, napríklad natiahnutím skripty cez nejaký Jenkins a docker-compose, ale prečo si komplikovať život, keď máme hotové a spoľahlivé riešenie? Preto sme prešli na Kubernetes a už rok ho používame na produkcii. Teraz máme dvadsať štyri klastrov Kubernetes, najstarší z nich je starší ako rok, obsahuje okolo dvesto podov.
Kliatba veľkého množstva YAML súborov v Kubernetes
Na spustenie mikroslužby v Kubernetes vytvoríme aspoň päť YAML súborov: pre Deployment, Service, Ingress, ConfigMap, Secrets — a pošleme ich do klastru. Pre ďalšiu aplikáciu napíšeme rovnaký balík yaml, s treťou — ďalší a tak ďalej. Násobíme počet dokumentov počtom prostredí, už dostávame stovky súborov, a to ešte nezohľadňujeme dynamické prostredia.
Adam Reese, hlavný správca Helm, zaviedol pojem „“, ktorý vyzerá takto:
- Kopírovať YAML — skopírovať YAML súbor.
- Vložiť YAML — vložiť ho.
- Opraviť odsadenia — opraviť odsadenia.
- Opakovať — zopakovať znova.
Varianta je funkčná, ale musíme veľakrát kopírovať YAML súbory. Aby sme tento cyklus zmenili, vymysleli sme Helm.
Čo je Helm
Po prvé, Helm je správca balíkov, ktorý pomáha nájsť a inštalovať potrebné programy. Na inštaláciu, napríklad MongoDB, netreba navštevovať oficiálnu stránku a sťahovať binárne súbory, stačí vykonať príkaz helm install stable/mongodb.
Po druhé, Helm — šablónový systém, pomáha parametrizovať súbory. Vráťme sa k situácii so súbormi YAML v Kubernetes. Je jednoduchšie napísať ten istý YAML súbor, pridať doň niekoľko placeholderov, do ktorých Helm vloží hodnoty. Teda namiesto veľkého množstva YAML súborov bude sada šablón, do ktorých sa v potrebnom okamihu vložia potrebné hodnoty.
Po tretie, Helm — majster nasadzovania. S jeho pomocou je možné inštalovať, vracať a aktualizovať aplikácie. Poďme si ukázať, ako to robiť.
Ako používať Helm na nasadenie vlastných aplikácií
Nainštalujeme klienta Helm na počítač podľa oficiálnych . Potom vytvoríme sadu YAML súborov. Namiesto uvedenia konkrétnych hodnôt necháme placeholdery, ktoré v budúcnosti Helm vyplní informáciami. Sada takýchto súborov sa nazýva Helm chart. Do konzolového klienta Helm je možné ho poslať tromi spôsobmi:
- uvedením priečinka so šablónami;
- zabalením do .tar archívu a uvedením naň;
- vložením šablóny do vzdialeného repozitára a pridaním odkazu na repozitár do klienta Helm.
Ešte potrebujeme súbor so hodnotami — values.yaml. Dáta odtiaľ sa budú vkladať do šablóny. Vytvoríme aj ten.
V druhej verzii Helm existuje ďalšia serverová aplikácia — Tiller. Tá visí vonku z Kubernetes a čaká na požiadavky od klienta Helm, a pri volaní vkladá potrebné hodnoty do šablóny a odosiela do Kubernetes.
Helm 3 je jednoduchší: namiesto spracovania šablón na serveri sa informácie teraz spracúvajú úplne na strane klienta Helm a odosielajú priamo do Kubernetes API. Toto zjednodušenie zvyšuje bezpečnosť klastra a uľahčuje model nasadzovania.
Ako to všetko funguje
Spustíme príkaz helm install. Uvedieme názov releasu aplikácie, dáme cestu k values.yaml. Na konci uvedieme repozitár, v ktorom sa nachádza chart a názov chartu. V príklade je to „lmru“ a „bestchart“ respektíve.
helm install --name bestapp --values values.yaml lmru/bestchart
Spustenie príkazu je možné len raz, pri opakovaní namiesto install je potrebné použiť upgrade. Pre jednoduchosť je namiesto dvoch príkazov možné vykonať príkaz upgrade s dodatočným kľúčom --install. Pri prvom vykonaní Helm odošle príkaz na inštaláciu vydania a neskôr ho bude aktualizovať.
helm upgrade --install bestapp --values values.yaml lmru/bestchart
Úskalia nasadzovania nových verzií aplikácie s Helmom
Na tomto mieste príbehu sa hrám s publikom v „Kto chce byť milionárom“ a zistíme, ako prinútiť Helm aktualizovať verziu aplikácie. .
Keď som sa učil, ako pracovať s Helmom, prekvapilo ma zvláštne správanie pri pokuse o aktualizáciu verzií spustených aplikácií. Kód aplikácie bol aktualizovaný, v docker registry som nahral nový obraz, poslal príkaz na nasadenie – a nič sa nestalo. Nižšie sú niektoré menej úspešné spôsoby aktualizácie aplikácií. Studujúc každý z nich podrobnejšie, začínaš chápať vnútornú štruktúru nástroja a dôvody takého nepovšimnutého správania.
Spôsob 1. Nemeniť informácie od posledného spustenia
Ako hovorí Helm, „Kubernetes charte môžu byť veľké a zložité, preto sa Helm snaží neprerušovať zbytočne.“ Preto, ak aktualizuješ latest-verziu obrazu aplikácie v docker registry a vykonáš príkaz helm upgrade, tak sa nič nestane. Helm bude myslieť, že sa nič nezmenilo a nebude potrebné posielať v Kubernetes príkaz na aktualizáciu aplikácie.
Tu a ďalej je tag latest uvedený výlučne ako príklad. Pri uvedení tohto tagu Kubernetes vždy stiahne obraz z docker registry bez ohľadu na parameter imagePullPolicy. Používanie latest v produkcii je neželané a spôsobuje vedľajšie účinky.
Spôsob 2. Aktualizovať LABEL v image
Ako je napísané v tej istej , „Helm bude aktualizovať aplikáciu, iba ak sa od posledného vydania zmenila.“ Logickým variantom pre toto sa javí aktualizácia značky LABEL v samotnom docker obraze. Avšak Helm nechádza do obrazov aplikácií a nemá informácie o akýchkoľvek zmenách v nich. Tým pádom, pri aktualizácii značiek v obraze sa Helm o nich nedozvie a príkaz na aktualizáciu aplikácie v Kubernetes nepríde.
Spôsob 3. Použiť kľúč --force
Obráťme sa na manuály a hľadajme potrebný kľúč. Najviac sa zmyslu hodí kľúč --force. Napriek svojmu názvu, správanie sa líši od očakávaného. Namiesto núteného aktualizovania aplikácie je jej skutočný účel obnoviť vydanie, ktoré je vo statusu FAILED. Ak tento parameter nepoužijete, je potrebné postupne vykonať príkazy. helm delete && helm install --replace. Namiesto toho sa odporúča použiť parameter --force, ktorý automatizuje postupné vykonávanie týchto príkazov. Viac informácií v tomto . Aby ste povedali Helm, aby predsa len aktualizoval verziu aplikácie, bohužiaľ, tento parameter nie je vhodný.
Spôsob 4. Meniť labels priamo v Kubernetes.
Aktualizácia labelu priamo v klastri pomocou príkazu kubectl edit — zlý nápad. Tento krok povedie k nekonzistentnosti informácií medzi bežiacou aplikáciou a tým, čo bolo pôvodne odoslané na nasadenie. Správanie Helm pri nasadení v tomto prípade sa líši od jeho verzie: Helm 2 nič neurobí, zatiaľ čo Helm 3 nasadí novú verziu aplikácie. Na pochopenie príčiny je potrebné pochopiť, ako Helm funguje.
Ako je Helm navrhnutý.
Na určenie, či sa aplikácia od posledného vydania zmenila, môže Helm využiť:
- bežiacu aplikáciu v Kubernetes;
- nový values.yaml a aktuálny chart;
- vnútorné informácie Helmu o vydaniach.
Pre tých, ktorí sa radi pýtajú: kde Helm uchováva vnútorné informácie o vydaniach?Po vykonaní príkazu helm history, získame všetky informácie o verziách nainštalovaných pomocou Helmu.
Okrem toho sú k dispozícii podrobné informácie o odoslaných šablónach a hodnotách. Môžeme ich získať:
V druhej verzii Helmu sú tieto informácie uložené v rovnakom namespace, kde je spustený Tiller (predvolene — kube-system), v ConfigMap, označenej značkou «OWNER=TILLER»:
S príchodom tretej verzie Helmu sa informácie presunuli do tajomstiev, pričom v tom istom namespace, kde je spustená aplikácia. Vďaka tomu je možné spúšťať viacero aplikácií v rôznych namespace s rovnakým názvom vydania. V druhej verzii to bola veľká bolesť hlavy, keď sú namespace izolované, ale môžu si navzájom zasahovať.
Druhý Helm, keď sa snaží zistiť, či je potrebná aktualizácia, používa iba dva zdroje informácií: to, čo mu poskytli teraz, a vnútorné informácie o vydaniach, ktoré sú uložené v ConfigMap.
Tretí Helm využíva stratégiu three-way merge: okrem informácií zohľadňuje aj aplikáciu, ktorá aktuálne beží v Kubernetes.
Z toho dôvodu staršia verzia Helmu nič neurobí, pretože nezohľadňuje informácie aplikácie v klastri, avšak Helm 3 získa zmeny a nasadí novú aplikáciu.
Spôsob 5. Použiť kľúč —recreate-pods
Pomocou kľúča --recreate-pods môžeme dosiahnuť to, čo sa pôvodne plánovalo dosiahnuť pomocou kľúča --force. Kontajnery sa reštartujú a podľa politiky imagePullPolicy: Always pre tag latest (o tom vyššie v poznámke) Kubernetes stiahne a spustí novú verziu obrazu. Bude to robiť nie najlepším spôsobom: bez ohľadu na StrategyType nasadenia náhle vypne všetky staré inštancie aplikácie a pôjde spustiť nové. Počas reštartu systém nebude fungovať, používatelia budú trpieť.
V samotnom Kubernetes podobný problém existoval dlhšiu dobu. A tak, po štyroch rokoch od otvorenia , problém opravili a od verzie 1.15 je v Kubernetes možnosť rolling-restart podov.
Helm jednoducho vypne všetky aplikácie a spustí vedľa nové kontajnery. V produkte to robiť nemožno, aby sa nezpôsobilo nečinnosť aplikácie. Takéto akcie sú potrebné len na vývojové účely, môžu sa vykonávať iba v stage prostrediach.
Ako aktualizovať verziu aplikácie pomocou Helmu?
Budeme meniť hodnoty zasielané do Helmu. Zvyčajne ide o hodnoty, ktoré sa vkladajú na miesto tagu obrazu. V prípade latest, často využívaného pre neprodukčné prostredia, hrá úlohu premenlivá informácia anotácia, ktorá je pre samotný Kubernetes zbytočná, ale pre Helm bude signálom k potrebe aktualizácie aplikácie. Možnosti vyplnenia hodnoty anotácie:
- Náhodná hodnota pomocou štandardnej funkcie —
{{ randAlphaNum 6 }}.
Je tu jeden detail: po každom nasadení pomocou chartu s takouto premennou bude hodnota anotácie unikátna a Helm bude predpokladať, že existujú zmeny. Vzhľadom na to, vždy budeme reštartovať aplikáciu, aj keď sme jej verziu nezmenili. Nie je to kritické, pretože nečinnosť nebude, ale predsa len je to nepríjemné. - Vložiť aktuálnu dátum a čas —
{{ .Release.Date }}.
Tento variant je podobný náhodnej hodnote s neustále unikátnou premennou. - Správnejším spôsobom je použiť opakované sumy. Toto je SHA obrazu alebo SHA posledného commitu v Gite —
{{ .Values.sha }}.
Musíme ich spočítať a poslať klientovi Helm na volajúcej strane, napríklad v Jenkins. Ak sa aplikácia zmení, zmení sa aj kontrolná suma. Preto Helm aktualizuje aplikáciu iba vtedy, keď je to potrebné.
Zhrnime naše pokusy
- Helm robí zmeny najmenej invazívnym spôsobom, preto akákoľvek zmena na úrovni obrazu aplikácie v Docker Registry nevedie k aktualizácii: po vykonaní príkazu sa nič nestane.
- Parameter
--forcesa používa na obnovu problémových vydaní a nie je spojený s nútenou aktualizáciou. - Parameter
--recreate-podsnútene aktualizuje aplikácie, ale robí to násilným spôsobom: náhle vypne všetky kontajnery. Tým trpia používatelia, na produkcii by sa to nemalo robiť. - Priamo vkladať zmeny do klastra Kubernetes pomocou príkazu
kubectl editby sa nemalo: narušíme konzistenciu a správanie sa bude líšiť v závislosti od verzie Helmu. - S vydaním novej verzie Helmu sa objavilo veľa nuáns. Problémy v repozitári Helmu sú opísané zrozumiteľným spôsobom, pomôžu zorientovať sa v detailoch.
- Pridanie meniteľnej anotácie do chartu ho urobí flexibilnejším. To umožní správne nasadenie aplikácie bez výpadkov.
Myšlienka z kategórie «mier vo svete», platná vo všetkých oblastiach života: prečítajte si návod pred použitím, nie po ňom. Iba s kompletnými informáciami dokážete budovať spoľahlivé systémy a robiť používateľov šťastnými.
Ďalšie odkazy na tému:
Tento príspevok bol prvýkrát prednesený na od Mail.ru Cloud Solutions. Pozrite sa iné vystúpenia a prihláste sa na oznámenia udalostí v Telegrame .
Zdroj: habr.com
