🥇Úvod do Helmu 3

Poznámka. přel.: 16. květen tohoto roku znamená významný milník ve vývoji správce balíčků pro Kubernetes - Helm. V tento den bylo představeno první alfa vydání budoucí hlavní verze projektu – 3.0. Jeho vydání přinese do Helmu významné a dlouho očekávané změny, do kterých mnozí v komunitě Kubernetes vkládají velké naděje. My sami jsme jedním z nich, protože Helm aktivně využíváme pro nasazení aplikací: integrovali jsme jej do našeho nástroje pro implementaci CI/CD werf a čas od času přispíváme k rozvoji upstreamu. Tento překlad kombinuje 7 poznámek z oficiálního blogu Helm, které jsou věnovány prvnímu alfa vydání Helm 3 a hovoří o historii projektu a hlavních rysech Helm 3. Jejich autorem je Matt „bacongobbler“ Fisher, zaměstnanec Microsoftu a jeden z klíčových správců Helmu.

15. října 2015 se zrodil projekt nyní známý jako Helm. Pouhý rok po svém založení se komunita Helm připojila ke Kubernetes, zatímco aktivně pracovala na Helmu 2. V červnu 2018 Helm vstoupil do CNCF jako rozvojový (inkubační) projekt. Rychle vpřed do současnosti a první alfa verze nového Helm 3 je na cestě. (toto vydání již proběhlo v polovině května - cca. překlad.).

V tomto díle budu hovořit o tom, kde to všechno začalo, jak jsme se dostali tam, kde jsme dnes, představím některé jedinečné funkce dostupné v prvním alfa vydání Helm 3 a vysvětlím, jak se plánujeme posunout vpřed.

Shrnutí:

historie vzniku Helmu;
něžné rozloučení s Tillerem;
úložiště grafů;
správa vydání;
změny v závislosti na grafu;
knihovní grafy;
co bude dál?

Historie Helmu

Narození

Helm 1 začal jako Open Source projekt vytvořený společností Deis. Byli jsme malý startup absorbován Microsoft na jaře 2017. Náš další Open Source projekt, také pojmenovaný Deis, měl nástroj deisctl, která sloužila (mimo jiné) k instalaci a provozu platformy Deis v Seskupení flotily. V té době byla Fleet jednou z prvních platforem pro orchestraci kontejnerů.

V polovině roku 2015 jsme se rozhodli změnit kurz a přesunuli Deis (tehdy přejmenovaného na Deis Workflow) z Fleet do Kubernetes. Jedním z prvních, který byl přepracován, byl instalační nástroj. deisctl. Použili jsme jej k instalaci a správě Deis Workflow v clusteru Fleet.

Helm 1 byl vytvořen k obrazu slavných správců balíčků, jako jsou Homebrew, apt a yum. Jeho hlavním cílem bylo zjednodušit úkoly, jako je balení a instalace aplikací na Kubernetes. Helm byl oficiálně představen v roce 2015 na konferenci KubeCon v San Franciscu.

Náš první pokus s Helmem vyšel, ale neobešel se bez vážných omezení. Vzal sadu manifestů Kubernetes, ochucených generátory jako úvodní bloky YAML (přední záležitost)* a načte výsledky do Kubernetes.

* Poznámka. přel.: Od první verze Helmu byla k popisu zdrojů Kubernetes zvolena syntaxe YAML a při psaní konfigurací byly podporovány šablony Jinja a skripty Python. Více o tomto ao struktuře první verze Helmu obecně jsme psali v kapitole „Stručná historie Helmu“ tento materiál.

Chcete-li například nahradit pole v souboru YAML, museli jste do manifestu přidat následující konstrukci:

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

Je skvělé, že šablonovací enginy dnes existují, ne?

Z mnoha důvodů tento raný instalační program Kubernetes vyžadoval pevně zakódovaný seznam souborů manifestu a spouštěl pouze malou pevnou sekvenci událostí. Použití bylo tak obtížné, že tým výzkumu a vývoje Deis Workflow měl těžké chvíle, když se pokusil přenést svůj produkt na tuto platformu - semínko nápadu však již bylo zaseto. Náš první pokus byl skvělou příležitostí k učení: uvědomili jsme si, že jsme skutečně nadšení pro vytváření pragmatických nástrojů, které řeší každodenní problémy našich uživatelů.

Na základě zkušeností z minulých chyb jsme začali vyvíjet Helm 2.

Výroba helmy 2

Na konci roku 2015 nás kontaktoval tým Google. Pracovali na podobném nástroji pro Kubernetes. Deployment Manager for Kubernetes byl port existujícího nástroje, který byl použit pro Google Cloud Platform. "Chtěli bychom," zeptali se, "strávit několik dní diskusí o podobnostech a rozdílech?"

V lednu 2016 se týmy Helm a Deployment Manager setkaly v Seattlu, aby si vyměnily nápady. Jednání skončila ambiciózním plánem: spojit oba projekty a vytvořit Helm 2. Spolu s Deis a Google se kluci z SkippBox (nyní součást Bitnami - cca. překlad)a začali jsme pracovat na Helmu 2.

Chtěli jsme zachovat snadnost použití Helmu, ale přidali jsme následující:

šablony grafů pro přizpůsobení;
intra-cluster management pro týmy;
prvotřídní úložiště grafů;
stabilní formát balíčku s možností podpisu;
silný závazek k sémantickému verzování a zachování zpětné kompatibility mezi verzemi.

K dosažení těchto cílů byl do ekosystému Helm přidán druhý prvek. Tato komponenta uvnitř klastru se jmenovala Tiller a byla zodpovědná za instalaci Helmových diagramů a jejich správu.

Od vydání Helm 2 v roce 2016 přidal Kubernetes několik významných inovací. Přidáno řízení přístupu na základě rolí (RBAC), který nakonec nahradil Attribute-Based Access Control (ABAC). Byly představeny nové typy zdrojů (Deployments byly v té době stále ve verzi beta). Byly vynalezeny vlastní definice zdrojů (původně nazývané zdroje třetích stran nebo TPR). A hlavně se objevila sada osvědčených postupů.

Uprostřed všech těchto změn Helm nadále věrně sloužil uživatelům Kubernetes. Po třech letech a mnoha nových přírůstcích bylo jasné, že nastal čas provést významné změny v kódové základně, aby bylo zajištěno, že Helm bude moci i nadále plnit rostoucí potřeby vyvíjejícího se ekosystému.

Něžné rozloučení s Tillerem

Během vývoje Helm 2 jsme představili Tiller jako součást naší integrace s Google Deployment Manager. Tiller hrál důležitou roli pro týmy pracující v rámci společného clusteru: umožňoval různým specialistům provozujícím infrastrukturu komunikovat se stejnou sadou verzí.

Vzhledem k tomu, že řízení přístupu na základě rolí (RBAC) bylo ve výchozím nastavení v Kubernetes 1.6 povoleno, práce s Tillerem v produkci se stala obtížnější. Vzhledem k velkému množství možných bezpečnostních politik je naším postojem nabízet ve výchozím nastavení povolenou konfiguraci. To umožnilo nováčkům experimentovat s Helm a Kubernetes, aniž by se museli nejprve ponořit do nastavení zabezpečení. Bohužel tato konfigurace oprávnění mohla uživateli poskytnout příliš širokou škálu oprávnění, která nepotřeboval. Inženýři DevOps a SRE se museli naučit další provozní kroky při instalaci Tilleru v clusteru s více nájemci.

Poté, co jsme se dozvěděli, jak komunita používala Helm v konkrétních situacích, jsme si uvědomili, že systém správy verzí Tiller se nemusí spoléhat na komponentu uvnitř clusteru, aby udržoval stav nebo fungoval jako centrální centrum pro informace o vydání. Místo toho bychom mohli jednoduše přijímat informace ze serveru Kubernetes API, vygenerovat graf na straně klienta a uložit záznam o instalaci v Kubernetes.

Tillerova hlavního cíle by bylo možné dosáhnout i bez Tillera, takže jedním z našich prvních rozhodnutí ohledně Helmu 3 bylo Tillera úplně opustit.

Když Tiller odešel, Helmův bezpečnostní model byl radikálně zjednodušen. Helm 3 nyní podporuje všechny moderní metody zabezpečení, identity a autorizace aktuálních Kubernetes. Oprávnění kormidla se určují pomocí soubor kubeconfig. Správci klastru mohou omezit uživatelská práva na libovolnou úroveň podrobnosti. Verze jsou stále uloženy v clusteru a zbytek funkcí Helmu zůstává nedotčen.

Úložiště grafů

Na vysoké úrovni je úložiště grafů místem, kde lze grafy ukládat a sdílet. Klient Helm zabalí a odešle grafy do úložiště. Jednoduše řečeno, úložiště grafů je primitivní HTTP server se souborem index.yaml a několika zabalenými grafy.

Zatímco rozhraní API pro úložiště grafů, které splňuje nejzákladnější požadavky na úložiště, má některé výhody, má také několik nevýhod:

Úložiště grafů nejsou kompatibilní s většinou implementací zabezpečení požadovaných v produkčním prostředí. Mít standardní API pro ověřování a autorizaci je v produkčních scénářích nesmírně důležité.
Nástroje Helm pro provenienci diagramů, používané k podepisování, ověřování integrity a původu diagramů, jsou volitelnou součástí procesu publikování diagramů.
Ve scénářích pro více uživatelů může být stejný graf nahrán jiným uživatelem, čímž se zdvojnásobí množství místa potřebného k uložení stejného obsahu. K vyřešení tohoto problému byly vyvinuty chytřejší repozitáře, které však nejsou součástí formální specifikace.
Použití jednoho indexového souboru pro vyhledávání, ukládání metadat a načítání grafů znesnadnilo vývoj bezpečných implementací pro více uživatelů.

projekt Distribuce Docker (také známý jako Docker Registry v2) je nástupcem Docker Registry a v podstatě funguje jako sada nástrojů pro balení, odesílání, ukládání a doručování obrázků Docker. Mnoho velkých cloudových služeb nabízí produkty založené na distribuci. Díky této zvýšené pozornosti těžil projekt Distribuce z let vylepšování, osvědčených bezpečnostních postupů a testování v terénu, které z něj udělaly jednoho z nejúspěšnějších neopěvovaných hrdinů světa Open Source.

Věděli jste ale, že Distribuční projekt byl navržen tak, aby distribuoval jakoukoli formu obsahu, nejen obrázky kontejnerů?

Díky úsilí Otevřená iniciativa na kontejnery (nebo OCI), Helm diagramy lze umístit na jakoukoli instanci Distribuce. Prozatím je tento proces experimentální. Přihlašovací podpora a další funkce potřebné pro kompletní Helm 3 jsou ve vývoji, ale jsme rádi, že se můžeme poučit z objevů, které týmy OCI a Distribuce během let učinily. A díky jejich mentorství a vedení se učíme, jaké to je provozovat vysoce dostupnou službu ve velkém měřítku.

K dispozici je podrobnější popis některých nadcházejících změn v úložištích grafů Helm по ссылке.

Správa vydání

V Helm 3 je stav aplikace sledován v rámci clusteru dvojicí objektů:

objekt uvolnění - představuje instanci aplikace;
tajná verze vydání - představuje požadovaný stav aplikace v určitém okamžiku (například vydání nové verze).

Výzva helm install vytvoří objekt vydání a tajný klíč verze vydání. Volání helm upgrade vyžaduje objekt vydání (který může změnit) a vytvoří nový tajný klíč verze vydání obsahující nové hodnoty a připravený manifest.

Objekt Release obsahuje informace o vydání, kde release je konkrétní instalace pojmenovaného grafu a hodnot. Tento objekt popisuje metadata nejvyšší úrovně o vydání. Objekt vydání přetrvává po celou dobu životního cyklu aplikace a je vlastníkem všech tajných klíčů verze vydání a také všech objektů, které jsou přímo vytvořeny grafem Helm.

Tajná verze vydání spojuje vydání s řadou revizí (instalace, aktualizace, vrácení zpět, odstranění).

V Helmu 2 byly revize extrémně konzistentní. Volání helm install vytvořená v1, následná aktualizace (upgrade) - v2 a tak dále. Tajné tajemství vydání a verze vydání byly sbaleny do jediného objektu známého jako revize. Revize byly uloženy ve stejném jmenném prostoru jako Tiller, což znamenalo, že každé vydání bylo z hlediska jmenného prostoru „globální“; v důsledku toho bylo možné použít pouze jednu instanci názvu.

V Helm 3 je každé vydání přidruženo k jednomu nebo více tajemstvím verze vydání. Objekt vydání vždy popisuje aktuální vydání nasazené do Kubernetes. Každý tajný klíč vydání popisuje pouze jednu verzi tohoto vydání. Upgrade například vytvoří tajný klíč nové verze a poté změní objekt vydání tak, aby ukazoval na tuto novou verzi. V případě vrácení můžete použít tajné klíče předchozí verze k vrácení vydání do předchozího stavu.

Poté, co je Tiller opuštěn, Helm 3 ukládá data vydání do stejného jmenného prostoru jako vydání. Tato změna vám umožňuje nainstalovat graf se stejným názvem vydání do jiného jmenného prostoru a data se ukládají mezi aktualizacemi/restartováním clusteru v etcd. Například můžete nainstalovat WordPress do jmenného prostoru „foo“ a poté do jmenného prostoru „bar“ a obě vydání lze pojmenovat „wordpress“.

Změny závislostí grafu

Grafy zabalené (pomocí helm package) pro použití s Helm 2 lze nainstalovat s Helm 3, nicméně pracovní postup vývoje grafu byl zcela přepracován, takže je nutné provést některé změny, aby vývoj grafu mohl pokračovat s Helm 3. Zejména se změnil systém správy závislostí grafů.

Systém správy závislostí grafu se přesunul requirements.yaml и requirements.lock na Chart.yaml и Chart.lock. To znamená, že grafy, které používají příkaz helm dependency, vyžadují určité nastavení, aby fungoval v Helm 3.

Podívejme se na příklad. Pojďme přidat závislost do grafu v Helmu 2 a uvidíme, co se změní při přechodu na Helm 3.

V Helmu 2 requirements.yaml vypadal takto:

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

V Helm 3 se stejná závislost projeví i ve vaší Chart.yaml:

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

Grafy se stále stahují a ukládají do adresáře charts/, takže podgrafy (podgrafy), ležící v katalogu charts/, bude nadále fungovat beze změn.

Představujeme žebříčky knihoven

Helm 3 podporuje třídu grafů zvanou knihovní grafy (graf knihovny). Tento graf je používán jinými grafy, ale sám o sobě nevytváří žádné artefakty vydání. Šablony grafu knihovny mohou deklarovat pouze prvky define. Ostatní obsah je jednoduše ignorován. To umožňuje uživatelům opakovaně používat a sdílet úryvky kódu, které lze použít ve více grafech, čímž se zabrání duplicitě a dodrží se princip DRY.

Knihovní schémata jsou deklarována v sekci dependencies v souboru Chart.yaml. Jejich instalace a správa se neliší od ostatních grafů.

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

Jsme nadšeni z případů použití, které tato komponenta otevře vývojářům grafů, a také z osvědčených postupů, které mohou vyplynout z grafů knihoven.

Co bude dál?

Helm 3.0.0-alpha.1 je základem, na kterém začínáme stavět novou verzi Helmu. V článku jsem popsal některé zajímavé vlastnosti Helmu 3. Mnohé z nich jsou stále v raných fázích vývoje a to je normální; Smyslem alfa verze je otestovat nápad, získat zpětnou vazbu od prvních uživatelů a potvrdit naše předpoklady.

Jakmile vyjde alfa verze (pamatujte, že toto je už se stalo - Cca. překlad.), začneme od komunity přijímat opravy pro Helm 3. Musíte vytvořit pevný základ, který umožní vývoj a přijetí nových funkcí a uživatelé se budou cítit zapojeni do procesu otevíráním lístků a prováděním oprav.

Snažil jsem se upozornit na některá z hlavních vylepšení přicházejících do Helmu 3, ale tento seznam není v žádném případě vyčerpávající. Kompletní plán pro Helm 3 zahrnuje funkce, jako jsou vylepšené strategie aktualizací, hlubší integrace s registry OCI a použití schémat JSON k ověření hodnot grafu. Plánujeme také vyčistit kódovou základnu a aktualizovat její části, které byly poslední tři roky zanedbávány.

Pokud máte pocit, že nám něco uniklo, rádi bychom slyšeli váš názor!

Zapojte se do diskuze na našem Slack kanály:

#helm-users za dotazy a jednoduchou komunikaci s komunitou;
#helm-dev diskutovat o žádostech o stažení, kódu a chybách.

Můžete také chatovat v našich týdenních veřejných výzvách pro vývojáře ve čtvrtek v 19:30 MSK. Setkání jsou věnována diskuzi o problémech, na kterých klíčoví vývojáři a komunita pracují, a také tématům diskuzí na tento týden. Kdokoli se může připojit a zúčastnit se schůzky. Odkaz je dostupný na kanálu Slack #helm-dev.

PS od překladatele

Přečtěte si také na našem blogu:

Zdroj: www.habr.com

Představujeme Helm 3