🥇Oznamovanie Helmu 3

Pozn. prekl.: 16. mája tohto roku — významná míľa v rozvoji správcu balíkov pre Kubernetes — Helm. V tento deň bol predstavený prvý alfa-release budúcej veľkej verzie projektu — 3.0. Jej vydanie prinesie do Helmu podstatné a dlh ожиданиé zmeny, na ktoré mnohí v Kubernetes komunite vkladajú veľké nádeje. K týmto zmenám patríme aj my, pretože aktívne používame Helm na nasadzovanie aplikácií: integrovali sme ho do nášho nástroja pre realizáciu CI/CD. werf a príležitostne prispievame k rozvoju upstream. Tento preklad spája 7 poznámok z oficiálneho blogu Helmu, ktoré sú venované prvému alfa-release Helmu 3 a rozprávajú o histórii projektu a hlavných funkciách Helmu 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 založení sa komunita Helmu pripojila k Kubernetes, pričom aktívne pracovala na Helme 2. V júni 2018 sa Helm stal súčasťou CNCF ako rozvíjajúci sa (incubating) projekt. Presuňme sa do súčasnosti — a už je na ceste prvý alfa-release nového Helmu 3 (tento release už prebehol v polovici mája — pozn. prekl.).

V tomto materiáli vám poviem o tom, ako to všetko začalo, ako sme sa dostali k súčasnému štádiu, predstavím niektoré unikátne funkcie, dostupné v prvom alfa-release Helmu 3, a vysvetlím, ako plánujeme ďalej rozvíjať.

Krátke zhrnutie:

história vzniku Helmu;
jemné rozlúčenie s Tillerom;
repozitáre chartov;
správa release-ov;
zmeny v závislostiach chartov;
library charts;
čo ďalej?

História vzniku Helmu

Národzenie

Helm 1 začínal ako Open Source projekt, vytvorený spoločnosťou Deis. Boli sme malý startup, pohltený Microsoftom na jar 2017. Našim druhým Open Source projektom, taktiež nesúcim meno Deis, bol nástroj deisctl, ktorý bol používaný (okrem iného) na inštaláciu a prevádzku platformy Deis v klasteri Fleet. V tom čase bol Fleet jednou z prvých platforiem pre orchestráciu kontajnerov.

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

Helm 1 bol vytvorený na základe známych balíkových manažérov, ako sú Homebrew, apt a yum. Jeho hlavnou úlohou bolo zjednodušiť úlohy, ako je balenie a inštalácia aplikácií v Kubernetes. Oficiálne bol Helm predstavený v roku 2015 na konferencii KubeCon v San Franciscu.

Naša prvá pokus s Helmom bol úspešný, avšak nevyhli sme sa vážnym obmedzeniam. Vzal súbor manifestov Kubernetes, obohatených generátormi ako vstupné YAML bloky (front-matter)*, a načítal výsledky do Kubernetes.

* Pozn. prekl.: Od prvej verzie Helm bol pre popis zdrojov Kubernetes zvolený syntaktický jazyk YAML a pri písaní konfigurácií sa podporovali šablóny Jinja a Python skripty. Viac o tom a prvej verzii Helmu sme písali v kapitole „Krátka história Helmu“ tohto materiálu.

Napríklad, aby ste nahradili pole v YAML súbore, bolo potrebné pridať do manifestu nasledujúcu konštrukciu:

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

Je úžasné, že dnes existujú šablonizátory, nie pravda?

Z mnohých dôvodov tento raný inštalátor Kubernetes vyžadoval presne definovaný zoznam manifestových súborov a vykonával iba malú fixnú sekvenciu udalostí. Používať ho bolo tak ťažké, že R&D tím Deis Workflow mal ťažkosti, keď sa pokúsil preniesť svoj produkt na túto platformu — napriek tomu, semeno myšlienky už bolo zasadené. Náš prvý pokus sa stal skvelou príležitosťou na učenie: uvedomili sme si, že sme skutočne nadšení vytváraním pragmatických nástrojov, ktoré riešia každodenné problémy našich používateľov.

Využívajúc skúsenosti z minulých chýb, sme sa pustili do vývoja Helmu 2.

Vytvorenie Helmu 2

Na konci roka 2015 sa s nami skontaktoval tím Google. Pracovali na podobnom nástroji pre Kubernetes. Deployment Manager pre Kubernetes bol portom existujúceho nástroja, ktorý sa využíval pre Google Cloud Platform. 'Nechcete, — pýtali sa, — stráviť niekoľko dní diskusiou o podobnostiach a rozdieloch?'

V januári 2016 sa tím Helmu a Deployment Managera stretol v Seattli, aby si vymenil nápady. Rokovania sa skončili ambicióznym plánom: skombinovať oba projekty, aby vznikol Helm 2. Spolu s Deis a Google sa k tímu vývojárov pridali chlapci zo SkippBox (dnes súčasť Bitnami — pozn. prekl.)., a my sme sa pustili do práce na Helme 2.

Chceli sme zachovať jednoduché používanie Helm, ale pridať nasledujúce:

šablóny grafov na prispôsobenie;
interné riadenie pre tímov;
prvotriedny repozitár grafov;
stabilný formát balíkov s možnosťou podpisu;
silný záväzok k semantickému verzionovaniu a zachovaniu spätnej kompatibility medzi verziami.

Na dosiahnutie týchto cieľov bol do ekosystému Helm pridaný druhý komponent. Tento interný komponent bol nazvaný Tiller a zaoberal sa inštaláciou Helm grafov a ich správou.

Od vydania Helm 2 v roku 2016 Kubernetes prešiel niekoľkými významnými novinkami. Objavilo sa riadenie prístupu na základe rolí (RBAC), ktoré nakoniec nahradilo riadenie prístupu na základe atribútov (ABAC). Boli predstavené nové typy zdrojov (Deployments vtedy boli stále v beta verzii). Boli vynájdené Definície vlastných zdrojov (pôvodne sa nazývali Third Party Resources alebo TPRs). A čo je najdôležitejšie — objavil sa súbor najlepších praktík.

V kontexte všetkých týchto zmien Helm naďalej slúžil verne používateľom Kubernetes. Po troch rokoch a mnohých nových doplnkoch sa ukázalo, že nastal čas na významné zmeny v kódovej základni, aby Helm mohol naďalej uspokojovať rastúce potreby rozvíjajúceho sa ekosystému.

Nežné rozlúčenie s Tillerom

Počas vývoja Helm 2 sme predstavili Tiller ako súčasť našej integrácie s Deployment Managerom od Googlu. Tiller zohrával dôležitú úlohu pre tímy pracujúce v rámci spoločného klastra: umožňoval rôznym odborníkom na infraštruktúru interagovať s rovnakým súborom vydaní.

Keď sa v Kubernetes 1.6 predvolene zapol prístup na základe rolí (RBAC), práca s Tillerom v produkcii sa stala zložitejšou. Vzhľadom na obrovské množstvo možných bezpečnostných politík sme považovali za vhodné predvolene ponúknuť povolenú konfiguráciu. To umožnilo nováčikom experimentovať s Helm a Kubernetes bez toho, aby sa museli najprv zaoberať bezpečnostnými nastaveniami. Bohužiaľ, táto povolená konfigurácia mohla dať používateľovi príliš široký rozsah oprávnení, ktoré nepotreboval. DevOps a SRE inžinieri museli študovať ďalšie operačné kroky pri inštalácii Tillera v multi-tenant klastre.

Zistili sme, ako zástupcovia komunity používajú Helm v konkrétnych situáciách, a uvedomili sme si, že systém správy release Tillera nemusí spoliehať na intra-klastrovú zložku, aby udržal stavy alebo fungoval ako centrálny uzol s informáciami o release. Namiesto toho by sme mohli jednoducho získavať informácie z API servera Kubernetes, generovať chart na strane klienta a uchovávať záznam o inštalácii v Kubernetes.

Hlavnú úlohu Tillera bolo možné vykonať aj bez Tillera, takže jedným z našich prvých rozhodnutí ohľadom Helmu 3 bolo úplne sa vzdať Tillera.

S odchodom Tillera sa model bezpečnosti Helmu radikálne zjednodušil. Helm 3 teraz podporuje všetky moderné metódy zabezpečenia, identity a autorizácie v aktuálnom Kubernetes. Oprávnenia Helmu sú definované pomocou súboru kubeconfig. Správcovia klastrov môžu obmedziť práva používateľov s akoukoľvek úrovňou podrobnosti. Release zostáva naďalej uložený v rámci klastru, ostatná funkcionalita Helmu zostáva.

Repository chartov

Na vysokej úrovni je repository chartov miesto, kde sa dá uchovávať a zdieľať chartov. Klient Helm balí a odosiela chart do repository. Jednoducho povedané, repository chartov je primitívny HTTP server s index.yaml súborom a niektorými zabalenými chartami.

Hoci existujú niektoré výhody, keď API repository chartov vyhovuje základným požiadavkám na úložisko, má aj niekoľko nevýhod:

Repozitáre grafov sú zle kompatibilné so väčšinou implementácií zabezpečenia potrebného v produkčnom prostredí. Prítomnosť štandardného API na autentifikáciu a autorizáciu je mimoriadne dôležitá v produkčných scenároch.
Nástroje Helm na sledovanie pôvodu grafu, používané na podpisovanie, kontrolu integrity a pôvodu grafu, sú voliteľnou súčasťou procesu publikácie grafu.
V multiužívateľských scenároch môže byť rovnaký graf nahraný ďalším používateľom, čím sa zdvojnásobí objem priestoru potrebného na uloženie rovnakého obsahu. Na riešenie tohto problému boli vyvinuté inteligentnejšie repo, ale nie sú súčasťou formálnej špecifikácie.
Použitie 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 multiužívateľských implementácií.

Projekt Docker Distribution (tiež známy ako Docker Registry v2) je nástupcom Docker Registry a vlastne ide o súbor nástrojov na balenie, odosielanie, ukladanie a dodávanie Docker obrazov. Mnohé veľké cloudové služby ponúkajú produkty založené na Distribution. Vďaka zvýšenému zameraniu získal projekt Distribution z mnohých rokov vylepšení, osvedčených bezpečnostných praktík a testovania v 'boji', čo ho premenilo na jedného z najúspešnejších neocenovaných hrdinov sveta open-source.

Ale vedeli ste, že projekt Distribution bol navrhnutý na distribúciu akéhokoľvek typu obsahu, nie len obrazov kontajnerov?

Vďaka úsilí Open Container Initiative (alebo OCI) môžu byť Helm grafy umiestnené na akomkoľvek inštancii Distribution. Zatiaľ je tento proces experimentálny. Práca na podpore prihlásení a iných funkcií potrebných pre plnohodnotný Helm 3 ešte nie je dokončená, ale veľmi sa tešíme na možnosť učiť sa z objavov, ktoré za tieto roky uskutočnili tímy OCI a Distribution. A vďaka ich mentorstvu a vedeniu sa učíme, čo znamená prevádzkovanie vysoko dostupnej služby vo veľkom meradle.

Podrobnejší popis niektorých nadchádzajúcich zmien v repozitároch Helm grafov je k dispozícii na odkaze.

Správa vydaní

V Helme 3 je stav aplikácie sledovaný v rámci klastra dvojicou objektov:

release object — predstavuje inštanciu aplikácie;
verzia uvoľnenia tajné — predstavuje želaný stav aplikácie v konkrétnom okamihu (napríklad uvoľnenie novej verzie).

Vyvolanie helm install vytvára release object a release version secret. Volanie helm upgrade vyžaduje existenciu release object (ktorý môže meniť) a vytvára nový release version secret, ktorý obsahuje nové hodnoty a pripravený manifest.

Release object obsahuje informácie o uvoľnení, kde uvoľnenie — konkrétna inštalácia pomenovanej šablóny a hodnôt. Tento objekt popisuje metadáta na najvyššej úrovni o uvoľnení. Release object sa uchováva počas celého životného cyklu aplikácie a vystupuje ako majiteľ všetkých release version secret a všetkých objektov, ktoré sú priamo vytvorené Helm šablónou.

Release version secret spája uvoľnenie so sériou revízií (inštalácia, aktualizácie, návraty, odstránenie).

V Helm 2 boli revízie striktne sekvenčné. Volanie helm install vytvorilo v1, následná aktualizácia (upgrade) — v2, a tak ďalej. Release a release version secret boli zlučované do jedného objektu, známeho ako revízia. Revizie sa ukladali v tom istom priestore názvov, ako Tiller, čo znamenalo, že každé uvoľnenie bolo „globálne“ z hľadiska priestoru názvov; v dôsledku toho mohol byť použitý iba jeden príklad názvu.

V Helm 3 je každé uvoľnenie spojené s jedným alebo viacerými release version secret. Release object vždy popisuje aktuálne uvoľnenie nasadené v Kubernetes. Každý release version secret popisuje iba jednu verziu tohto uvoľnenia. Aktualizácia (upgrade), napríklad, vytvorí nový release version secret a potom zmení release object, aby ukazoval na túto novú verziu. V prípade návratu (rollback) je možné použiť predchádzajúce release version secret na vrátenie uvoľnenia do predchádzajúceho stavu.

Po zrušení Tiller Helm 3 uchováva údaje o uvoľnení v rovnakom priestore názvov ako uvoľnenie. Takáto zmena umožňuje nainštalovať šablónu s rovnakým názvom uvoľnenia do iného priestoru názvov a údaje sa uchovávajú medzi aktualizáciami/reštartami klastrove v etcd. Napríklad, môžete nainštalovať WordPress v priestore názvov „foo“ a potom v priestore názvov „bar“, a obe uvoľnenia môžu byť pomenované „wordpress.“

Zmeny v závislostiach šablón

Šablóny, zabalene (pomocou helm package) na použitie s Helm 2, je možné ho nainštalovať aj pomocou Helmu 3, avšak proces vývoja chartov bol úplne prepracovaný, preto je potrebné urobiť niektoré úpravy pre pokračovanie vo vývoji chartov s Helm 3. Konkrétne sa zmenil systém správy závislostí chartov.

Systém správy závislostí chartu prešiel na requirements.yaml a requirements.lock na Chart.yaml a Chart.lock. To znamená, že roomy, ktoré použili príkaz helm dependency, vyžadujú niektoré úpravy, aby fungovali s Helm 3.

Pozrime sa na príklad. Pridajme závislosť k chartu v Helme 2 a pozrime sa, čo sa zmení pri prechode na Helm 3.

V Helme 2 requirements.yaml vyzeralo nasledovne:

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

V Helme 3 bude tá istá závislosť zobrazená vo vašom Chart.yaml:

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

Chartové súbory sa stále načítavajú a ukladajú do adresára charts/, takže subcharty (subcharts), ležiace v adresári charts/, budú fungovať bez zmien.

Predstavujeme Library Charts

Helm 3 podporuje typ chartov, ktorý dostal názov chartov knižnice (library chart). Tento chart sa používa inými chartami, ale sám nevytvára žiadne artefakty vydania. Šablóny chartov knižnice môžu vyhlasovať iba prvky define. Iný obsah je jednoducho ignorovaný. To umožňuje používateľom opätovne využívať a zdieľať kódové fragmenty, ktoré môžu byť použité v mnohých chartech, čím sa vyhýbajú duplikovaniu a dodržiavajú princíp DRY.

Library charts sa vyhlasujú v časti závislosti v súbore Chart.yaml. Inštalácia a správa sú rovnaké ako pri iných chartech.

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

S napätím čakáme na možnosti využitia, ktoré tento komponent otvorí pred vývojármi chartov, ako aj na osvedčené praktiky, ktoré môžu vzniknúť vďaka chartom knižnice.

Čo ďalej?

Helm 3.0.0-alpha.1 je základ, na ktorom začíname budovať novú verziu Helmu. V článku som opísal niektoré zaujímavé funkcie Helmu 3. Mnohé z nich sú zatiaľ vo fáze vývoja, a to je v poriadku; podstata alfa verzie spočíva v testovaní myšlienky, získaní spätnej väzby od prvých používateľov a potvrdení našich predpokladov.

Akonáhle bude alfa verzia uvoľnená (nezabúdajme, že už sa tak stalo — pozn. prekl.), začneme prijímať opravy pre Helm 3 od komunity. Je potrebné vytvoriť spoľahlivý základ, ktorý umožní vyvíjať a prijímať nové funkcie, pričom používatelia sa budú môcť cítiť zapojení do procesu, otvorením tiketov a zasielaním opráv.

V článku som sa snažil osvetliť niektoré vážne zlepšenia, ktoré sa objavia v Helme 3, avšak tento zoznam rozhodne nemožno považovať za vyčerpávajúci. Celkový plán pre Helm 3 zahŕňa také novinky ako zlepšené stratégie aktualizácie, hlbšiu integráciu s OCI registry a využitie JSON schém na overovanie hodnôt grafov. Taktiež plánujeme vyčistiť kódovú základňu a aktualizovať tie jej časti, ktoré zostávali bez povšimnutia posledné tri roky.

Ak máte pocit, že sme na niečo zabudli, radi sa dozvieme vaše názory!

Pridajte sa k diskusii v našich Slack kanáloch:

#helm-users na otázky a jednoduchú komunikáciu s komunitou;
#helm-dev na diskusiu o pull requestoch, kóde a chybách.

Môžete sa tiež zúčastniť našich týždenných verejných vývojárskych hovorov každú stredu o 19:30 MSK. Stretnutia sú zamerané na diskusiu o úlohách, na ktorých pracujú kľúčoví vývojári a komunita, ako aj o témach diskusie na týždeň. Každý, kto má záujem, sa môže pripojiť a zúčastniť sa stretnutia. Odkaz je k dispozícii v Slack kanáli #helm-dev.