🥇Úvod do Helmu 3

Pozn. přek.: 16. května tohoto roku – významný milník v rozvoji balíčkového manažera pro Kubernetes – Helm. V tento den byl představen první alfa release budoucí velké verze projektu – 3.0. Její vydání přinese do Helmu významné a dlouho očekávané změny, na které mnozí v Kubernetes komunitě vkládají velké naděje. Mezi ně se počítáme i my, protože aktivně používáme Helm pro nasazení aplikací: integrujeme ho do našeho nástroje pro realizaci CI/CD. werf a příležitostně přispíváme svým dílem k rozvoji upstreamu. Tento překlad spojuje 7 poznámek z oficiálního blogu Helmu, které se váží k prvnímu alfa release Helmu 3 a vypráví o historii projektu a hlavních vlastnostech Helmu 3. Jejich autorem je Matt „bacongobbler“ Fisher, zaměstnanec Microsoftu a jeden z klíčových udržovatelů Helmu.

15. října 2015 se zrodil projekt, nyní známý jako Helm. Jen rok po svém založení se komunita Helmu připojila k Kubernetes a aktivně pracovala na Helmu 2. V červnu 2018 se Helm stal součástí CNCF jako vyvíjející se (incubating) projekt. Přenesme se do současnosti – a již se blíží první alfa release nového Helmu 3 (tento release už proběhl v polovině května – pozn. překladatele).

V tomto materiálu vám povím o tom, jak to všechno začalo, jak jsme se dostali k současnému stadiu, představím některé unikátní vlastnosti dostupné v prvním alfa release Helmu 3 a vysvětlím, jak plánujeme dál vyvíjet.

Shrnutí:

historie vzniku Helmu;
neměkké rozloučení s Tillerem;
repozitáře chartů;
správa release;
změny v závislostech chartů;
library charts;
co dál?

Historie vzniku Helmu

Narození

Helm 1 začínal jako Open Source projekt, který vytvořila společnost Deis. Byli jsme malý startup, který byl pohlcen Microsoftem na jaře 2017. Náš další Open Source projekt, také nazývaný Deis, měl nástroj deisctl, který se používá (mimo jiné) k instalaci a provozu platformy Deis v klastru Fleet. V té době byl Fleet jednou z prvních platforem pro orchestraci kontejnerů.

V polovině roku 2015 jsme se rozhodli změnit kurz a převedli jsme Deis (v té době přejmenovaný na Deis Workflow) z Fleet na Kubernetes. Jedním z prvních nástrojů, který prošel revizí, byl instalační nástroj. deisctlPoužili jsme ho k instalaci a správě Deis Workflow v klastru Fleet.

Helm 1 byl vytvořen na základě známých balíčkových manažerů, jako jsou Homebrew, apt a yum. Jeho hlavním cílem bylo zjednodušení úkolů, jako je balení a instalace aplikací v Kubernetes. Oficiálně byl Helm představen v roce 2015 na konferenci KubeCon v San Franciscu.

Náš první pokus s Helmem fungoval, avšak nebylo to bez vážných omezení. Bral sadu manifestů Kubernetes, obohacených generátory jako vstupními YAML bloky (front-matter)*, a nahrával výsledky do Kubernetes.

* Pozn. přek.: Od první verze Helmu byl pro popis zdrojů Kubernetes vybrán syntaktický jazyk YAML a při psaní konfigurací byly podporovány šablony Jinja a Python skripty. O tom, a také o struktuře první verze Helmu, jsme psali v kapitole „Krátká historie Helmu“ tohoto materiálu.

Například, abyste nahradili pole v YAML souboru, bylo potřeba přidat do manifestu následující konstrukci:

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

Je skvělé, že dnes existují šablonizátory, viďte?

Z mnoha důvodů tento raný instalační program Kubernetes vyžadoval pevně definovaný seznam manifestových souborů a prováděl pouze malou pevně stanovenou sekvenci událostí. Bylo s ním tak složité zacházet, že R&D tým Deis Workflow měl problém, když se pokusil převést svůj produkt na tuto platformu — přesto však byly zasety semena myšlenky. Náš první pokus byl skvělou příležitostí k učení: uvědomili jsme si, že nás skutečně baví vytvářet pragmatické nástroje, které řeší každodenní problémy našich uživatelů.

Na základě zkušeností z minulých chyb jsme se pustili do vývoje Helmu 2.

Vytvoření Helmu 2

Na konci roku 2015 nás kontaktoval tým Google. Pracovali na podobném nástroji pro Kubernetes. Deployment Manager pro Kubernetes byl portem stávajícího nástroje, který se používal pro Google Cloud Platform. „Nechtěli bychom, — ptali se, — strávit pár dní diskusí o podobnostech a rozdílech?“

V lednu 2016 se týmy Helmu a Deployment Manageru setkaly v Seattlu, aby sdílely názory. Jednání skončilo ambiciózním plánem: zkombinovat oba projekty a vytvořit Helm 2. Spolu s Deis a Google se k týmu vývojářů přidali kluci z SkippBox (nyní součást Bitnami — pozn. red.), a pustili jsme se do práce na Helmu 2.

Chtěli jsme zachovat jednoduchost používání Helmu, ale přidat následující:

šablony chartů pro přizpůsobení;
vnitřní řízení pro týmy;
prvotřídní repozitář chartů;
stabilní formát balíčků s možností podpisu;
pevné odhodlání k semantickému verzování a zachování zpětné kompatibility mezi verzemi.

K dosažení těchto cílů byl do ekosystému Helmu přidán druhý prvek. Tento vnitřní komponent byl nazván Tiller a zabýval se instalací Helm chartů a jejich řízením.

Od vydání Helmu 2 v roce 2016 Kubernetes získalo několik významných novinek. Objevilo se řízení přístupu na základě rolí (RBAC), které nakonec nahradilo řízení přístupu na základě atributů (ABAC). Byly představeny nové typy zdrojů (Deployments tehdy stále zůstávaly v beta verzi). Byly vynalezeny Vlastní definice zdrojů (původně nazvané Třetí strany zdroje nebo TPR). A co je nejdůležitější - vznikla sada osvědčených postupů.

Na pozadí všech těchto změn Helm nadále sloužil uživatelům Kubernetes. Po třech letech a mnoha nových dodatcích se stalo jasným, že je čas provést zásadní změny v kódové základně, aby Helm i nadále uspokojoval rostoucí požadavky vyvíjejícího se ekosystému.

Něžné rozloučení s Tillerem

Při vývoji Helmu 2 jsme představili Tiller jako součást našeho integrovaného řešení s Deployment Managerem od Google. Tiller hrál důležitou roli pro týmy pracující v rámci sdíleného clusteru: umožnil různým odborníkům na infrastrukturu interagovat s tím samým souborem vydání.

Jelikož byl řízení přístupu na základě rolí (RBAC) ve výchozím nastavení zahrnut v Kubernetes 1.6, práce s Tillerem v produkci se stala složitější. Vzhledem k obrovskému počtu možných bezpečnostních politik byla naše pozice nabídnout povolující konfiguraci jako výchozí. To umožnilo nováčkům experimentovat s Helm a Kubernetes, aniž by se museli nejprve ponořit do nastavení bezpečnosti. Bohužel, tato povolující konfigurace mohla uživateli poskytnout příliš široký rozsah oprávnění, která nepotřeboval. Inženýři DevOps a SRE se museli naučit další provozní kroky při instalaci Tillera ve vícerozměrném (multi-tenant) clusteru.

Zjistivši, jak členové komunity používají Helm v konkrétních situacích, jsme pochopili, že systém správy vydání Tiller nemusí spoléhat na intra-clusterovou komponentu, aby udržoval stavy nebo fungoval jako centrální uzel s informacemi o vydání. Místo toho bychom mohli jednoduše získat informace z API serveru Kubernetes, generovat chart na straně klienta a uchovávat záznam o instalaci v Kubernetes.

Hlavní úkol Tillera mohl být splněn i bez něj, a proto bylo jedním z našich prvních rozhodnutí ohledně Helmu 3 úplné zrušení Tillera.

S odchodem Tillera se bezpečnostní model Helmu radikálně zjednodušil. Helm 3 nyní podporuje všechny moderní metody bezpečnosti, identifikace a autorizace současného Kubernetes. Oprávnění Helmu jsou určena pomocí souboru kubeconfig. Správci clusteru mohou omezit práva uživatelů s jakoukoliv úrovní podrobnosti. Vydání stále zůstávají v rámci clusteru, a ostatní funkce Helmu zůstávají.

Repozitáře chartů

Na vysoké úrovni je repozitář chartů místem pro ukládání a sdílení chartů. Klient Helmu balí a odesílá chart do repozitáře. Jinými slovy, repozitář chartů je primitivní HTTP server s souborem index.yaml a některými zabalenými charty.

I když existují určité výhody v tom, že API repozitáře chartů splňuje základní požadavky na úložiště, má také několik nevýhod:

Repozitáře chartů jsou špatně kompatibilní s většinou implementací zabezpečení, které jsou potřebné v produkčním prostředí. Mít standardní API pro autentizaci a autorizaci je v produkčních scénářích zásadní.
Nástroje Helmu pro sledování původu chartu, používané pro podepisování, kontrolu integrity a původu chartu, jsou nepovinnou součástí procesu publikace chartu.
V mnohopouživatelských scénářích může být stejný chart nahrán jiným uživatelem, což zdvojnásobuje objem prostoru potřebného pro uchování stejného obsahu. Pro vyřešení tohoto problému byly vyvinuty inteligentnější repozitáře, avšak nejsou součástí formální specifikace.
Použití jednotného indexového souboru pro vyhledávání, uchovávání metadat a získávání chartů ztížilo vývoj bezpečných mnohopouživatelských implementací.

Projekt Docker Distribution (také známý jako Docker Registry v2) je nástupcem Docker Registry a vlastně se jedná o sadu nástrojů pro balení, odesílání, ukládání a dodávání obrazů Dockeru. Mnoho velkých cloudových služeb nabízí produkty založené na Distribution. Díky tomuto zvýšenému zájmu projekt Distribution těžil z let vylepšení, nejlepších praktik v oblasti bezpečnosti a testování v "bojových" podmínkách, což ho proměnilo v jednoho z nejúspěšnějších nedoceněných hrdinů světa Open Source.

Ale víte, že projekt Distribution byl navržen pro distribuci jakéhokoli typu obsahu, a ne jen obrazů kontejnerů?

Díky úsilí Open Container Initiative (nebo OCI) mohou být Helm chartů umístěny na libovolném instance Distribution. Dosud je tento proces experimentální. Práce na podpoře přihlášení a dalších funkcionalit nezbytných pro plnohodnotný Helm 3 ještě není dokončena, ale velmi se těšíme na možnost učit se z objevů, které týmy OCI a Distribution učinily za ta léta. A díky jejich mentoringu a vedení se učíme, co obnáší provozování vysoce dostupné služby ve velkém měřítku.

Podrobnější popis některých nadcházejících změn v repozitářích Helm chartů je k dispozici na odkazu.

Správa verzí

V Helmu 3 je stav aplikace sledován uvnitř clusteru pomocí dvou objektů:

release object — představuje instanci aplikace;
release verze secret — představuje žádoucí stav aplikace v konkrétním okamžiku (například uvedení nové verze).

Zavolání helm install vytváří release objekt a release version secret. Volání helm upgrade vyžaduje existenci release objektu (který může měnit) a vytváří nový release version secret, který obsahuje nové hodnoty a připravený manifest.

Release objekt obsahuje informace o releasu, kde release je konkrétní instalace pojmenovaného chartu a hodnot. Tento objekt popisuje metadata na nejvyšší úrovni o releasu. Release objekt je uchováván po celou dobu životního cyklu aplikace a je vlastníkem všech release version secretů, stejně jako všech objektů, které jsou přímo vytvářeny Helm-chartem.

Release version secret spojuje release s řadou revizí (instalace, aktualizace, návraty, odstranění).

V Helm 2 byly revize výhradně sekvenční. Volání helm install vytvářel v1, následná aktualizace (upgrade) — v2, a tak dále. Release a release version secret byly sloučeny do jednoho objektu, známého jako revize. Revize byly uchovávány ve stejném jmenném prostoru jako Tiller, což znamenalo, že každý release byl „globální“ z hlediska jmenného prostoru; v důsledku toho bylo možné používat pouze jednu instanci názvu.

V Helm 3 je každý release spojen s jedním nebo více release version secret. Release objekt vždy popisuje aktuální release nasazený v Kubernetes. Každý release version secret popisuje pouze jednu verzi tohoto releasu. Aktualizace (upgrade) například vytvoří nový release version secret a poté změní release objekt, aby ukazoval na tuto novou verzi. V případě návratu (rollback) lze použít předchozí release version secret, aby se release vrátil do předchozího stavu.

Po zrušení Tilleru Helm 3 uchovává data o releasu ve stejném jmenném prostoru jako release. Tato změna umožňuje nainstalovat chart se stejným názvem releasu do jiného jmenného prostoru, a data jsou uchovávána mezi aktualizacemi/řetězováním clusteru v etcd. Například lze nainstalovat WordPress do jmenného prostoru „foo“, a poté do jmenného prostoru „bar“, a oba releasy mohou být nazvány „wordpress“.

Změny v závislostech chartů

Chart, zabalené (pomocí helm package) pro použití s Helm 2, lze nainstalovat s Helmem 3, avšak pracovní postup vývoje chartů byl zcela přepracován, a proto je třeba provést některé změny, aby bylo možné pokračovat ve vývoji chartů s Helmem 3. Zejména se změnil systém správy závislostí chartů.

Systém správy závislostí chartu přešel z requirements.yaml a requirements.lock na Chart.yaml a Chart.lock. To znamená, že chart, který používal příkaz helm dependency, vyžaduje určité úpravy, aby fungoval v Helmu 3.

Podívejme se na příklad. Přidáme závislost k chartu v Helmu 2 a podíváme se, co se změní při přechodu na Helm 3.

V Helmu 2 requirements.yaml vypadal následovně:

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

V Helmu 3 bude stejná závislost odražena ve vašem Chart.yaml:

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

Chartů se stále načítají a umisťují do adresáře charts/, takže subcharts (subcharts), ležící v adresáři charts/, budou nadále fungovat beze změny.

Představujeme Library Charts

Helm 3 podporuje typ chartů, který byl nazván chartami-knihovnami (library chart). Tento chart se používá jinými chartry, ale sám nevytváří žádné artefakty vydání. Šablony library chartů mohou deklarovat pouze prvky definovat. Jiný obsah je jednoduše ignorován. To umožňuje uživatelům opakovaně používat a sdílet kódové fragmenty, které lze využít v mnoha chartech, čímž se vyhne duplicitě a dodržuje princip DRY.

Library charts se deklarují v sekci závislosti v souboru Chart.yaml. Instalace a správa nejsou odlišné od ostatních chartů.

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

Těšíme se na možnosti použití, které tento komponent otevře před vývojáři chartů, stejně jako na osvědčené postupy, které mohou vzniknout díky library charts.

Co dál?

Helm 3.0.0-alpha.1 je základem, na kterém začínáme vytvářet novou verzi Helmu. V článku jsem popsal některé zajímavé funkce Helmu 3. Mnoho z nich je zatím ve fázi raného vývoje a to je v pořádku; podstata alpha verze spočívá v testování nápadu, shromažďování zpětné vazby od prvních uživatelů a potvrzení našich předpokladů.

Jakmile bude alpha verze vydána připomeňme, že to již nastalo — pozn. překl.), začneme přijímat patche pro Helm 3 od komunity. Je třeba vytvořit spolehlivý základ, který umožní vyvíjet a přijímat nové funkce, a uživatelé se mohou cítit zapojeni do procesu tím, že otevírají tikety a přispívají opravami.

V článku jsem se snažil osvětlit některá významná vylepšení, která se objeví v Helm 3, nicméně tento seznam rozhodně nelze považovat za vyčerpávající. Plnohodnotný plán pro Helm 3 zahrnuje novinky, jako jsou vylepšené aktualizační strategie, hlubší integrace s OCI registry a použití JSON schémat pro validaci hodnot chartů. Také plánujeme vyčistit kódovou základnu a aktualizovat její části, které zůstaly bez povšimnutí poslední tři roky.

Pokud cítíte, že jsme něco op missed, rádi uslyšíme vaše myšlenky!

Připojte se k diskusi v našich Slack kanálech:

#helm-users pro dotazy a prostou komunikaci s komunitou;
#helm-dev pro diskusi pull requestů, kódu a chyb.

Můžete se také zapojit do našich týdenních Public Developer Calls, které se konají ve čtvrtek v 19:30 MSK. Setkání se věnují diskusi o úkolech, na kterých pracují klíčoví vývojáři a komunita, stejně jako tématům diskuse na týden. Každý se může připojit a zúčastnit se setkání. Odkaz je dostupný v Slack kanálu #helm-dev.