🥇Úvod do Helm 3

Poznámka. preklad.: 16. máj tohto roku znamená významný míľnik vo vývoji správcu balíkov pre Kubernetes – Helm. V tento deň bolo predstavené prvé alfa vydanie budúcej hlavnej verzie projektu – 3.0. Jeho vydanie prinesie do Helmu významné a dlho očakávané zmeny, do ktorých mnohí v komunite Kubernetes vkladajú veľké nádeje. My sami sme jedným z nich, keďže Helm aktívne využívame na nasadzovanie aplikácií: integrovali sme ho do nášho nástroja na implementáciu CI/CD werf a z času na čas prispievame k rozvoju upstreamu. Tento preklad kombinuje 7 poznámok z oficiálneho blogu Helm, ktoré sú venované prvému alpha vydaniu Helm 3 a hovoria o histórii projektu a hlavných črtách Helm 3. Ich autorom je Matt “bacongobbler” Fisher, zamestnanec Microsoftu a jeden z kľúčových správcov Helmu.

15. októbra 2015 sa zrodil projekt dnes známy ako Helm. Len rok po svojom založení sa komunita Helm pripojila ku Kubernetes, pričom aktívne pracovala na Helme 2. V júni 2018 Helm vstúpil do CNCF ako rozvojový (inkubačný) projekt. Rýchly posun vpred do súčasnosti a prvé alfa vydanie nového Helm 3 je na ceste. (toto vydanie sa už uskutočnilo v polovici mája - cca. preklad.).

V tomto článku budem hovoriť o tom, kde to všetko začalo, ako sme sa dostali tam, kde sme dnes, predstavím niektoré jedinečné funkcie dostupné v prvom alfa vydaní Helm 3 a vysvetlím, ako plánujeme ďalší vývoj.

Zhrnutie:

história vzniku Helmu;
nežná rozlúčka s Tillerom;
archívy grafov;
správa uvoľňovania;
zmeny v závislostiach grafu;
knižničné tabuľky;
čo bude ďalej?

História Helmu

Narodenie

Helm 1 začal ako Open Source projekt vytvorený Deisom. Boli sme malý startup absorbované Microsoft na jar 2017. Náš ďalší Open Source projekt, tiež nazývaný Deis, mal nástroj deisctl, ktorý slúžil (okrem iného) na inštaláciu a prevádzku platformy Deis v r Zhluk flotily. V tom čase bola Fleet jednou z prvých platforiem na orchestráciu kontajnerov.

V polovici roka 2015 sme sa rozhodli zmeniť kurz a presunuli sme Deis (v tom čase premenovaný na Deis Workflow) z Fleet do Kubernetes. Jedným z prvých, ktorý bol prepracovaný, bol inštalačný nástroj. deisctl. Použili sme ho na inštaláciu a správu Deis Workflow v klastri Fleet.

Helm 1 bol vytvorený na obraz slávnych správcov balíkov ako Homebrew, apt a yum. Jeho hlavným cieľom bolo zjednodušiť úlohy ako balenie a inštalácia aplikácií na Kubernetes. Helm bol oficiálne predstavený v roku 2015 na konferencii KubeCon v San Franciscu.

Náš prvý pokus s Helmom vyšiel, ale nezaobišiel sa bez vážnych obmedzení. Vzal súbor manifestov Kubernetes, ochutených generátormi ako úvodné bloky YAML (predná strana)* a načítal výsledky do Kubernetes.

* Poznámka. preklad.: Od prvej verzie Helmu bola na popis zdrojov Kubernetes zvolená syntax YAML a pri písaní konfigurácií boli podporované šablóny Jinja a skripty Python. Viac o tomto a všeobecne o štruktúre prvej verzie Helmu sme písali v kapitole „Stručná história Helmu“ tento materiál.

Ak chcete napríklad nahradiť pole v súbore YAML, museli ste do manifestu pridať nasledujúcu konštrukciu:

#helm:generate sed -i -e s|ubuntu-debootstrap|fluffy-bunny| my/pod.yaml

Je skvelé, že nástroje šablón dnes existujú, nie?

Z mnohých dôvodov tento skorý inštalačný program Kubernetes vyžadoval pevne zakódovaný zoznam súborov manifestu a vykonával iba malú, pevnú sekvenciu udalostí. Bolo to také ťažké používať, že tím výskumu a vývoja Deis Workflow mal ťažké časy, keď sa pokúsil preniesť svoj produkt na túto platformu - semienka tejto myšlienky však už boli zasiate. Náš prvý pokus bol skvelou príležitosťou na učenie: uvedomili sme si, že sme skutočne nadšení pre vytváranie pragmatických nástrojov, ktoré riešia každodenné problémy našich používateľov.

Na základe skúseností z minulých chýb sme začali vyvíjať Helm 2.

Výroba prilby 2

Koncom roka 2015 nás kontaktoval tím Google. Pracovali na podobnom nástroji pre Kubernetes. Deployment Manager for Kubernetes bol port existujúceho nástroja, ktorý sa používal pre platformu Google Cloud Platform. "Chceli by sme," spýtali sa, "stráviť niekoľko dní diskusiou o podobnostiach a rozdieloch?"

V januári 2016 sa tímy Helm a Deployment Manager stretli v Seattli, aby si vymenili nápady. Rokovania sa skončili ambicióznym plánom: spojiť oba projekty a vytvoriť Helm 2. Spolu s Deisom a Googlom sa chalani z SkippBox (teraz súčasť Bitnami - približne preklad.)a začali sme pracovať na Helme 2.

Chceli sme zachovať jednoduchosť používania Helmu, ale pridali sme nasledujúce:

šablóny grafov na prispôsobenie;
vnútroklastrové riadenie pre tímy;
úložisko máp svetovej triedy;
stabilný formát balíka s možnosťou podpisu;
silný záväzok k sémantickému vytváraniu verzií a udržiavaniu spätnej kompatibility medzi verziami.

Na dosiahnutie týchto cieľov bol do ekosystému Helm pridaný druhý prvok. Tento komponent v rámci klastra sa nazýval Tiller a bol zodpovedný za inštaláciu a správu Helmových máp.

Od vydania Helm 2 v roku 2016 pridal Kubernetes niekoľko významných inovácií. Pridané riadenie prístupu na základe rolí (RBAC), ktorý nakoniec nahradil Attribute-Based Access Control (ABAC). Boli zavedené nové typy zdrojov (nasadenie bolo v tom čase stále v beta verzii). Boli vynájdené vlastné definície zdrojov (pôvodne nazývané zdroje tretích strán alebo TPR). A čo je najdôležitejšie, objavil sa súbor osvedčených postupov.

Uprostred všetkých týchto zmien Helm naďalej verne slúžil používateľom Kubernetes. Po troch rokoch a mnohých nových prírastkoch bolo jasné, že je čas urobiť významné zmeny v kódovej základni, aby sa zabezpečilo, že Helm bude môcť aj naďalej spĺňať rastúce potreby vyvíjajúceho sa ekosystému.

Nežná rozlúčka s Tillerom

Počas vývoja Helm 2 sme predstavili Tiller ako súčasť našej integrácie s Deployment Managerom Google. Tiller zohral dôležitú úlohu pre tímy pracujúce v rámci spoločného klastra: umožnil rôznym špecialistom prevádzkujúcim infraštruktúru interagovať s rovnakou sadou vydaní.

Keďže riadenie prístupu založené na rolách (RBAC) bolo v Kubernetes 1.6 predvolene povolené, práca s Tillerom vo výrobe sa stala zložitejšou. Kvôli veľkému množstvu možných bezpečnostných politík sme predvolene ponúkli povolenú konfiguráciu. To umožnilo nováčikom experimentovať s Helm a Kubernetes bez toho, aby sa museli najprv ponoriť do nastavení zabezpečenia. Žiaľ, táto konfigurácia povolení by mohla používateľovi poskytnúť príliš široký rozsah povolení, ktoré nepotreboval. Inžinieri DevOps a SRE sa museli naučiť ďalšie prevádzkové kroky pri inštalácii Tiller v klastri s viacerými nájomcami.

Keď sme sa dozvedeli, ako komunita používala Helm v špecifických situáciách, uvedomili sme si, že systém správy verzií Tiller sa nemusí spoliehať na komponent v rámci klastra na udržiavanie stavu alebo funkciu centrálneho centra pre informácie o vydaní. Namiesto toho by sme mohli jednoducho prijímať informácie zo servera Kubernetes API, vygenerovať graf na strane klienta a uložiť záznam o inštalácii v Kubernetes.

Tillerov hlavný cieľ by sa dal dosiahnuť aj bez Tillera, takže jedným z našich prvých rozhodnutí ohľadom Helma 3 bolo úplne opustiť Tillera.

Keď Tiller odišiel, Helmov bezpečnostný model sa radikálne zjednodušil. Helm 3 teraz podporuje všetky moderné metódy zabezpečenia, identity a autorizácie súčasných Kubernetes. Povolenia kormidla sa určujú pomocou súbor kubeconfig. Správcovia klastra môžu obmedziť práva používateľov na akúkoľvek úroveň podrobnosti. Vydania sú stále uložené v klastri a zvyšok funkcií Helm zostáva nedotknutý.

Úložisko grafov

Na vysokej úrovni je úložisko grafov miestom, kde je možné ukladať a zdieľať grafy. Klient Helm zabalí a odošle grafy do úložiska. Jednoducho povedané, úložisko grafov je primitívny HTTP server so súborom index.yaml a niekoľkými zabalenými grafmi.

Aj keď existujú určité výhody rozhrania Charts Repository API, ktoré spĺňa najzákladnejšie požiadavky na úložisko, existuje aj niekoľko nevýhod:

Repozitáre grafov nie sú kompatibilné s väčšinou bezpečnostných implementácií vyžadovaných v produkčnom prostredí. Mať štandardné API na autentifikáciu a autorizáciu je v produkčných scenároch mimoriadne dôležité.
Nástroje Helmovho pôvodu, používané na podpísanie, overenie integrity a pôvodu grafu, sú voliteľnou súčasťou procesu publikovania grafu.
V scenároch pre viacerých používateľov môže rovnaký graf nahrať iný používateľ, čím sa zdvojnásobí množstvo priestoru potrebného na uloženie rovnakého obsahu. Na vyriešenie tohto problému boli vyvinuté inteligentnejšie úložiská, ktoré však nie sú súčasťou formálnej špecifikácie.
Používanie jedného indexového súboru na vyhľadávanie, ukladanie metadát a získavanie grafov sťažilo vývoj bezpečných implementácií pre viacerých používateľov.

Projekt Docker Distribúcia (tiež známy ako Docker Registry v2) je nástupcom Docker Registry a v podstate funguje ako súbor nástrojov na balenie, odosielanie, ukladanie a doručovanie obrázkov Docker. Mnoho veľkých cloudových služieb ponúka produkty založené na distribúcii. Vďaka tejto zvýšenej pozornosti ťažil projekt Distribúcia z rokov vylepšení, najlepších bezpečnostných postupov a testovania v teréne, ktoré z neho urobili jedného z najúspešnejších neospevovaných hrdinov sveta Open Source.

Vedeli ste však, že Distribučný projekt bol navrhnutý tak, aby distribuoval akúkoľvek formu obsahu, nielen obrázky kontajnerov?

Vďaka úsiliu Iniciatíva otvoreného kontajnera (alebo OCI), Helm diagramy môžu byť umiestnené na akejkoľvek inštancii distribúcie. Zatiaľ je tento proces experimentálny. Podpora prihlasovania a ďalšie funkcie potrebné pre úplnú Helmu 3 stále prebiehajú, ale sme nadšení, že sa môžeme poučiť z objavov, ktoré tímy OCI a distribúcie za tie roky urobili. A prostredníctvom ich mentorstva a vedenia sa učíme, aké to je prevádzkovať vysoko dostupnú službu vo veľkom rozsahu.

K dispozícii je podrobnejší popis niektorých nadchádzajúcich zmien v archívoch grafov Helm по ссылке.

Správa vydania

V Helm 3 je stav aplikácie sledovaný v rámci klastra pomocou dvojice objektov:

objekt uvoľnenia - predstavuje inštanciu aplikácie;
tajná verzia verzie - predstavuje požadovaný stav aplikácie v určitom časovom bode (napríklad vydanie novej verzie).

volanie helm install vytvorí objekt vydania a tajomstvo verzie vydania. Zavolajte helm upgrade vyžaduje objekt vydania (ktorý môže zmeniť) a vytvorí nový tajný kľúč verzie vydania obsahujúci nové hodnoty a pripravený manifest.

Objekt vydania obsahuje informácie o vydaní, kde release je špecifická inštalácia pomenovaného grafu a hodnôt. Tento objekt popisuje metadáta najvyššej úrovne o vydaní. Objekt vydania pretrváva počas celého životného cyklu aplikácie a je vlastníkom všetkých tajomstiev verzie vydania, ako aj všetkých objektov, ktoré sú priamo vytvorené grafom Helm.

Tajná verzia verzie spája vydanie so sériou revízií (inštalácia, aktualizácie, vrátenie späť, vymazanie).

V Helme 2 boli revízie mimoriadne konzistentné. Zavolajte helm install vytvorená v1, následná aktualizácia (upgrade) - v2 atď. Tajomstvo vydania a verzie vydania boli zbalené do jedného objektu známeho ako revízia. Revízie boli uložené v rovnakom mennom priestore ako Tiller, čo znamenalo, že každé vydanie bolo z hľadiska menného priestoru „globálne“; v dôsledku toho bolo možné použiť iba jednu inštanciu názvu.

V Helm 3 je každé vydanie spojené s jedným alebo viacerými tajnými kľúčmi verzie vydania. Objekt vydania vždy popisuje aktuálne vydanie nasadené v Kubernetes. Každé tajomstvo verzie vydania popisuje iba jednu verziu daného vydania. Inovácia napríklad vytvorí tajné tajomstvo novej verzie a potom zmení objekt vydania tak, aby ukazoval na túto novú verziu. V prípade vrátenia späť môžete použiť tajné kľúče verzie predchádzajúceho vydania na vrátenie vydania do predchádzajúceho stavu.

Po opustení Tillera Helm 3 uloží údaje o vydaní do rovnakého menného priestoru ako vydanie. Táto zmena vám umožňuje nainštalovať graf s rovnakým názvom vydania v inom priestore názvov a údaje sa uložia medzi aktualizáciami/reštartovaním klastra v etcd. Napríklad môžete nainštalovať WordPress do menného priestoru „foo“ a potom do menného priestoru „bar“ a obe vydania môžu byť pomenované „wordpress“.

Zmeny závislostí grafu

Grafy zabalené (pomocou helm package) na použitie s Helm 2 je možné nainštalovať s Helm 3, avšak pracovný postup vývoja grafu bol úplne prepracovaný, takže je potrebné vykonať určité zmeny, aby vývoj grafu mohol pokračovať s Helm 3. Konkrétne sa zmenil systém správy závislostí grafov.

Systém správy závislostí grafu sa presunul z requirements.yaml и requirements.lock na Chart.yaml и Chart.lock. To znamená, že grafy, ktoré použili príkaz helm dependency, vyžadujú určité nastavenia, aby fungovali v Helm 3.

Pozrime sa na príklad. Pridajme závislosť do grafu v Helm 2 a uvidíme, čo sa zmení pri prechode na Helm 3.

V Helme 2 requirements.yaml vyzeral takto:

dependencies:
- name: mariadb
  version: 5.x.x
  repository: https://kubernetes-charts.storage.googleapis.com/
  condition: mariadb.enabled
  tags:
    - database

V Helm 3 sa rovnaká závislosť prejaví aj vo vašej Chart.yaml:

dependencies:
- name: mariadb
  version: 5.x.x
  repository: https://kubernetes-charts.storage.googleapis.com/
  condition: mariadb.enabled
  tags:
    - database

Grafy sa stále sťahujú a umiestňujú do adresára charts/, teda podkarty (podgrafy), ležiaci v katalógu charts/, bude naďalej fungovať bez zmien.

Predstavujeme knižničné tabuľky

Helm 3 podporuje triedu máp nazývanú knižničné grafy (graf knižnice). Tento graf je používaný inými grafmi, ale sám o sebe nevytvára žiadne artefakty vydania. Šablóny grafov knižnice môžu deklarovať iba prvky define. Iný obsah sa jednoducho ignoruje. To umožňuje používateľom opakovane používať a zdieľať úryvky kódu, ktoré možno použiť vo viacerých grafoch, čím sa zabráni duplicite a zachová sa princíp DRY.

Knižničné grafy sú uvedené v sekcii dependencies v súbore Chart.yaml. Ich inštalácia a správa sa nelíši od iných grafov.

dependencies:
  - name: mylib
    version: 1.x.x
    repository: quay.io

Sme nadšení z prípadov použitia, ktoré tento komponent otvorí pre vývojárov grafov, ako aj z osvedčených postupov, ktoré môžu vyplynúť z knižničných grafov.

Čo bude ďalej?

Helm 3.0.0-alpha.1 je základom, na ktorom začíname stavať novú verziu Helmu. V článku som opísal niektoré zaujímavé vlastnosti Helmu 3. Mnohé z nich sú stále v ranom štádiu vývoja a to je normálne; Cieľom alfa vydania je otestovať nápad, získať spätnú väzbu od prvých používateľov a potvrdiť naše predpoklady.

Hneď ako vyjde alfa verzia (pamätajte, že toto je už sa stalo - približne. preklad.), začneme od komunity prijímať záplaty pre Helm 3. Musíte vytvoriť pevný základ, ktorý umožní vývoj a prijatie novej funkcionality, a aby sa používatelia cítili zapojení do procesu otváraním lístkov a vykonávaním opráv.

Pokúsil som sa poukázať na niektoré z hlavných vylepšení prichádzajúcich do Helma 3, ale tento zoznam nie je v žiadnom prípade vyčerpávajúci. Úplný plán pre Helm 3 obsahuje funkcie, ako sú vylepšené stratégie aktualizácie, hlbšia integrácia s registrami OCI a použitie schém JSON na overenie hodnôt grafu. Plánujeme tiež vyčistiť kódovú základňu a aktualizovať jej časti, ktoré boli posledné tri roky zanedbávané.

Ak máte pocit, že sme niečo vynechali, radi si vypočujeme váš názor!

Zapojte sa do diskusie na našom Slack kanály:

#helm-users za otázky a jednoduchú komunikáciu s komunitou;
#helm-dev prediskutovať požiadavky na stiahnutie, kód a chyby.

Môžete tiež četovať v našich týždenných verejných výzvach pre vývojárov vo štvrtok o 19:30 MSK. Stretnutia sú venované diskusii o problémoch, na ktorých pracujú kľúčoví vývojári a komunita, ako aj témach diskusií na tento týždeň. Ktokoľvek sa môže pripojiť a zúčastniť sa stretnutia. Odkaz je k dispozícii na kanáli Slack #helm-dev.

PS od prekladateľa

Prečítajte si aj na našom blogu:

Zdroj: hab.com

Predstavujeme Helm 3