Podstatu příběhu o nejoblíbenějším správci balíčků pro Kubernetes lze vykreslit pomocí emotikonu:
- krabice je Helm (což je nejblíže nejnovějšímu vydání Emoji);
- zámek - zabezpečení;
- malý muž je řešením problému.
Ve skutečnosti bude všechno trochu komplikovanější a příběh je plný technických detailů Jak zajistit, aby Helm byl bezpečný.
- Stručně, co je Helm pro případ, že byste to nevěděli nebo zapomněli. Jaké problémy řeší a kde se v ekosystému nachází.
- Podívejme se na architekturu Helmu. Žádná konverzace o zabezpečení a o tom, jak učinit nástroj nebo řešení bezpečnější, se neobejde bez pochopení architektury komponenty.
- Pojďme diskutovat o součástech Helm.
- Nejpalčivější otázkou je budoucnost – nová verze Helm 3.
Vše v tomto článku platí pro Helm 2. Tato verze je v současné době ve výrobě a s největší pravděpodobností je to ta, kterou aktuálně používáte, a je to verze, která obsahuje bezpečnostní rizika.
O řečníkovi: Alexander Khayorov () se vyvíjí 10 let a pomáhá zlepšovat obsah a vstoupil do výboru . Nyní pracuje ve společnosti Chainstack jako vedoucí vývoje – jedná se o hybrid mezi vývojovým manažerem a osobou, která je zodpovědná za dodávání finálních verzí. To znamená, že se nachází na bojišti, kde se děje vše od vytvoření produktu až po jeho provoz.
Chainstack je malý, aktivně rostoucí startup, jehož posláním je umožnit klientům zapomenout na infrastrukturu a složitost provozu decentralizovaných aplikací, vývojový tým sídlí v Singapuru. Nežádejte Chainstack o prodej nebo nákup kryptoměny, ale nabídněte, že si promluvíte o podnikových blockchainových rámcích, a oni vám rádi odpoví.
Kormidlo
Toto je správce balíčků (grafů) pro Kubernetes. Nejintuitivnější a nejuniverzálnější způsob, jak přivést aplikace do clusteru Kubernetes.
Mluvíme samozřejmě o strukturálnějším a průmyslovějším přístupu, než je vytváření vlastních YAML manifestů a psaní malých utilit.
Helm je to nejlepší, co je v současnosti dostupné a oblíbené.
Proč Helm? Především proto, že je podporován CNCF. Cloud Native je velká organizace a je mateřskou společností pro projekty Kubernetes, etcd, Fluentd a další.
Dalším důležitým faktem je, že Helm je velmi oblíbený projekt. Když jsem v lednu 2019 začal mluvit o tom, jak zajistit Helm bezpečný, projekt měl na GitHubu tisíc hvězdiček. V květnu jich bylo 12 tisíc.
O Helm se zajímá mnoho lidí, takže i když ho ještě nepoužíváte, budete mít prospěch z toho, že budete vědět o jeho zabezpečení. Bezpečnost je důležitá.
Základní tým Helm je podporován Microsoft Azure a jde tedy o poměrně stabilní projekt, na rozdíl od mnoha jiných. Vydání Helm 3 Alpha 2 v polovině července naznačuje, že na projektu pracuje poměrně hodně lidí, kteří mají chuť a energii Helm vyvíjet a vylepšovat.
Helm řeší několik základních problémů správy aplikací v Kubernetes.
- Balení aplikace. Dokonce i aplikace jako „Hello, World“ na WordPress již obsahuje několik služeb a chcete je zabalit dohromady.
- Správa složitosti, která je spojena se správou těchto aplikací.
- Životní cyklus, který nekončí po instalaci nebo nasazení aplikace. Stále žije, je třeba jej aktualizovat a Helm s tím pomáhá a snaží se pro to přinést správná opatření a zásady.
Pytlování je uspořádán přehledně: jsou zde metadata plně v souladu s prací běžného správce balíčků pro Linux, Windows nebo MacOS. Tedy úložiště, závislosti na různých balíčcích, meta informace pro aplikace, nastavení, konfigurační funkce, indexování informací atd. To vše vám Helm umožňuje získávat a používat pro aplikace.
Řízení složitosti. Pokud máte mnoho aplikací stejného typu, je potřeba parametrizace. Šablony vycházejí z toho, ale abyste nemuseli vymýšlet vlastní způsob vytváření šablon, můžete použít to, co Helm nabízí hned po vybalení.
Správa životního cyklu aplikací - to je podle mě nejzajímavější a nevyřešená otázka. To je důvod, proč jsem tenkrát přišel do Helmu. Potřebovali jsme dohlížet na životní cyklus aplikace a chtěli jsme přesunout naše CI/CD a aplikační cykly do tohoto paradigmatu.
Helm vám umožňuje:
- řídit nasazení, zavádí pojem konfigurace a revize;
- úspěšně provést vrácení zpět;
- používat háčky pro různé události;
- přidat další kontroly aplikací a reagovat na jejich výsledky.
Navíc Helma má "baterie" - obrovské množství chutných věcí, které lze zahrnout ve formě pluginů, zjednodušujících váš život. Pluginy lze psát nezávisle, jsou dosti izolované a nevyžadují harmonickou architekturu. Pokud chcete něco implementovat, doporučuji to udělat jako plugin, a pak to případně zařadit do upstreamu.
Helma je založena na třech hlavních konceptech:
- Graf Repo — popis a pole možných parametrizací pro váš manifest.
- Config —to znamená hodnoty, které budou použity (text, číselné hodnoty atd.).
- Uvolnění shromažďuje dvě horní složky a společně se promění v Release. Vydání lze verzovat, čímž se dosáhne organizovaného životního cyklu: malé v době instalace a velké v době upgradu, downgradu nebo vrácení zpět.
Architektura kormidla
Diagram koncepčně znázorňuje architekturu Helmu na vysoké úrovni.
Dovolte mi připomenout, že Helm je něco, co souvisí s Kubernetes. Bez Kubernetes clusteru (obdélníku) se tedy neobejdeme. Komponenta kube-apiserver je umístěna na hlavním serveru. Bez Helma máme Kubeconfig. Helm přináší jednu malou binárku, dá-li se to tak nazvat, utilitu Helm CLI, která se instaluje do počítače, notebooku, sálového počítače – na cokoliv.
Ale to nestačí. Helm má serverovou komponentu nazvanou Tiller. Zastupuje zájmy Helmu v rámci clusteru, je to aplikace v rámci clusteru Kubernetes, jako každá jiná.
Další součástí Chart Repo je úložiště s grafy. Existuje oficiální úložiště a může existovat soukromé úložiště společnosti nebo projektu.
Interakce
Podívejme se, jak se vzájemně ovlivňují komponenty architektury, když chceme nainstalovat aplikaci pomocí Helm.
- Mluvíme
Helm install, přejděte do úložiště (Chart Repo) a získejte Helmův diagram.
- Nástroj Helm (Helm CLI) spolupracuje s Kubeconfigem, aby zjistil, který cluster kontaktovat.
- Po obdržení těchto informací nástroj odkazuje na Tiller, který se nachází v našem clusteru, jako na aplikaci.
- Tiller volá Kube-apiserver, aby provedl akce v Kubernetes, vytvořil nějaké objekty (služby, pody, repliky, tajemství atd.).
Dále diagram zkomplikujeme, abychom viděli vektor útoku, kterému může být vystavena celá architektura Helmu jako celek. A pak se ji pokusíme ochránit.
Vektor útoku
První potenciální slabé místo je privilegované API-uživatel. V rámci schématu se jedná o hackera, který získal administrátorský přístup do Helm CLI.
Neprivilegovaný uživatel API může také představovat nebezpečí, pokud je někde poblíž. Takový uživatel bude mít jiný kontext, například může být v nastavení Kubeconfig zafixován v jednom jmenném prostoru clusteru.
Nejzajímavějším vektorem útoku může být proces, který se nachází uvnitř shluku někde poblíž Tilleru a má k němu přístup. Může to být webový server nebo mikroslužba, která vidí síťové prostředí clusteru.
Exotická, ale stále oblíbenější varianta útoku zahrnuje Chart Repo. Tabulka vytvořená bezohledným autorem může obsahovat nebezpečné zdroje a vy ji dokončíte tím, že ji vezmete na vědomí. Nebo může nahradit graf, který si stáhnete z oficiálního úložiště a například vytvořit zdroj ve formě politik a eskalovat jeho přístup.
Pokusme se odrazit útoky ze všech těchto čtyř stran a zjistit, kde jsou v architektuře Helmu problémy a kde snad žádné nejsou.
Schéma zvětšíme, přidáme další prvky, ale ponecháme všechny základní komponenty.
Helm CLI komunikuje s Chart Repo, spolupracuje s Kubeconfigem a práce se přenáší do clusteru do komponenty Tiller.
Tiller je reprezentován dvěma objekty:
- Tiller-deploy svc, který zpřístupňuje určitou službu;
- Tiller-deploy pod (v diagramu v jediné kopii v jedné replice), na kterém běží celá zátěž, která přistupuje ke clusteru.
Pro interakci se používají různé protokoly a schémata. Z bezpečnostního hlediska nás nejvíce zajímá:
- Mechanismus, kterým Helm CLI přistupuje k repo grafu: jaký protokol, existuje autentizace a co s tím lze dělat.
- Protokol, kterým Helm CLI pomocí kubectl komunikuje s Tillerem. Toto je server RPC nainstalovaný uvnitř clusteru.
- Samotný Tiller je přístupný mikroslužbám, které jsou umístěny v clusteru a interagují s Kube-apiserverem.
Pojďme si probrat všechny tyto oblasti popořadě.
RBAC
Nemá smysl mluvit o jakémkoli zabezpečení pro Helm nebo jakoukoli jinou službu v rámci clusteru, pokud není povoleno RBAC.
Zdá se, že to není nejnovější doporučení, ale jsem si jistý, že mnoho lidí stále nepovolilo RBAC ani ve výrobě, protože je to spousta povyku a je třeba nakonfigurovat spoustu věcí. Doporučuji vám to však udělat.
— právník webových stránek společnosti RBAC. Obsahuje obrovské množství zajímavých materiálů, které vám pomohou RBAC nastavit, ukážou, proč je dobrý a jak se s ním v podstatě ve výrobě sžije.
Pokusím se vysvětlit, jak Tiller a RBAC fungují. Tiller pracuje uvnitř clusteru pod určitým servisním účtem. Pokud RBAC není nakonfigurován, bude to obvykle superuživatel. V základní konfiguraci bude Tiller správcem. To je důvod, proč se často říká, že Tiller je SSH tunel do vašeho clusteru. Ve skutečnosti je to pravda, takže můžete použít samostatný vyhrazený servisní účet namísto výchozího servisního účtu ve výše uvedeném diagramu.
Když inicializujete Helm a nainstalujete jej na server poprvé, můžete nastavit účet služby pomocí --service-account. To vám umožní používat uživatele s minimální požadovanou sadou práv. Je pravda, že budete muset vytvořit takovou „věnec“: Role a RoleBinding.
Helm to za vás bohužel neudělá. Vy nebo váš správce clusteru Kubernetes musíte předem připravit sadu rolí a vazeb rolí pro servisní účet, abyste mohli projít Helmem.
Nabízí se otázka – jaký je rozdíl mezi Role a ClusterRole? Rozdíl je v tom, že ClusterRole funguje pro všechny jmenné prostory, na rozdíl od běžných rolí a vazeb rolí, které fungují pouze pro specializovaný jmenný prostor. Zásady můžete konfigurovat pro celý cluster a všechny obory názvů nebo je můžete personalizovat pro každý obor názvů jednotlivě.
Za zmínku stojí, že RBAC řeší další velký problém. Mnoho lidí si stěžuje, že Helm bohužel není multitenancy (nepodporuje multitenancy). Pokud několik týmů spotřebovává cluster a používá Helm, je v podstatě nemožné nastavit politiky a omezit jejich přístup v rámci tohoto clusteru, protože existuje určitý servisní účet, pod kterým Helm běží a z něj vytváří všechny prostředky v clusteru. , což je někdy velmi nepohodlné. To je pravda – stejně jako samotný binární soubor, jako proces, Helm Tiller nemá žádnou koncepci vícenájmu.
Existuje však skvělý způsob, který vám umožní spustit Tiller vícekrát v clusteru. S tím není problém, Tiller lze spustit v každém jmenném prostoru. Můžete tedy použít RBAC, Kubeconfig jako kontext a omezit přístup ke speciálnímu Helmu.
Bude to vypadat takto.
Například existují dva Kubeconfigy s kontextem pro různé týmy (dva jmenné prostory): X Team pro vývojový tým a administrátorský cluster. Admin cluster má svůj vlastní široký Tiller, který se nachází v jmenném prostoru systému Kube, což je odpovídající pokročilý servisní účet. A samostatný jmenný prostor pro vývojový tým, budou moci nasadit své služby do speciálního jmenného prostoru.
Toto je funkční přístup, Tiller není tak hladový, aby to výrazně ovlivnilo váš rozpočet. Toto je jedno z rychlých řešení.
Neváhejte nakonfigurovat Tiller samostatně a poskytnout Kubeconfigu kontext pro tým, pro konkrétního vývojáře nebo pro prostředí: Dev, Staging, Production (je pochybné, že vše bude na stejném clusteru, ale lze to udělat).
Pokračujeme v našem příběhu, přejděme z RBAC a promluvme si o ConfigMaps.
ConfigMaps
Helm používá ConfigMaps jako úložiště dat. Když jsme se bavili o architektuře, nikde nebyla databáze, která by uchovávala informace o vydáních, konfiguracích, rollbackech atd. K tomu slouží ConfigMaps.
Hlavní problém s ConfigMaps je známý – nejsou z principu bezpečné; není možné ukládat citlivá data. Mluvíme o všem, co by nemělo přesahovat rámec služby, například o heslech. Nejpřirozenějším způsobem pro Helm je nyní přejít z používání ConfigMaps na tajné.
To se provádí velmi jednoduše. Přepište nastavení Tiller a určete, že úložiště bude tajné. Pak pro každé nasazení nedostanete ConfigMap, ale tajemství.
Dalo by se namítnout, že samotná tajemství jsou zvláštní pojem a nejsou příliš bezpečné. Je však třeba pochopit, že to dělají samotní vývojáři Kubernetes. Počínaje verzí 1.10, tzn. Již poměrně dlouho je možné, alespoň ve veřejných cloudech, připojit správné úložiště pro ukládání tajemství. Tým nyní pracuje na způsobech, jak lépe distribuovat přístup k tajemstvím, jednotlivým modulům nebo jiným entitám.
Je lepší přenést Storage Helm na tajemství a ta jsou zase centrálně zabezpečena.
Samozřejmě to zůstane limit úložiště dat 1 MB. Helm zde používá etcd jako distribuované úložiště pro ConfigMaps. A tam usoudili, že je to vhodný datový blok pro replikaci atd. Na Redditu je o tom zajímavá diskuze, doporučuji si najít toto vtipné čtení na víkend nebo si přečíst úryvek .
Graf Repos
Grafy jsou sociálně nejzranitelnější a mohou se stát zdrojem „Muž uprostřed“, zvláště pokud používáte akciové řešení. V první řadě mluvíme o úložištích, která jsou vystavena přes HTTP.
Rozhodně musíte vystavit Helm Repo přes HTTPS - to je nejlepší možnost a je levná.
Poznámka: mechanismus podpisu grafu. Technologie je pekelně jednoduchá. To je to samé, co používáte na GitHubu, běžném počítači PGP s veřejnými a soukromými klíči. Nastavte a ujistěte se, že máte potřebné klíče a vše podepište, že toto je skutečně váš graf.
Kromě toho, Klient Helm podporuje TLS (ne ve smyslu HTTP na straně serveru, ale vzájemné TLS). Ke komunikaci můžete použít serverové a klientské klíče. Abych byl upřímný, takový mechanismus nepoužívám, protože nemám rád vzájemné certifikáty. V podstatě, - hlavní nástroj pro nastavení Helm Repo pro Helm 2 - podporuje také základní autentizaci. Pokud je to pohodlnější a tišší, můžete použít základní auth.
Existuje také plugin , která vám umožňuje hostovat úložiště grafů na Google Cloud Storage. To je docela pohodlné, funguje to skvěle a je to docela bezpečné, protože všechny popsané mechanismy jsou recyklované.
Pokud povolíte HTTPS nebo TLS, použijete mTLS a povolíte základní ověření pro další snížení rizik, získáte zabezpečený komunikační kanál s Helm CLI a Chart Repo.
gRPC API
Další krok je velmi důležitý – zabezpečit Tiller, který se nachází v clusteru a je na jedné straně server, na druhou stranu sám přistupuje k dalším komponentám a snaží se za někoho vydávat.
Jak jsem již řekl, Tiller je služba, která odhaluje gRPC, klient Helm k ní přichází přes gRPC. Standardně je TLS samozřejmě zakázáno. Proč se to udělalo, je diskutabilní otázka, zdá se mi, že to zjednodušuje nastavení na začátku.
Pro produkci a dokonce i staging doporučuji povolit TLS na gRPC.
Podle mého názoru, na rozdíl od mTLS pro grafy, je to zde vhodné a provádí se velmi jednoduše - vygenerovat infrastrukturu PQI, vytvořit certifikát, spustit Tiller, přenést certifikát při inicializaci. Poté můžete provádět všechny příkazy Helm a prezentovat se vygenerovaným certifikátem a soukromým klíčem.
Tímto způsobem se budete chránit před všemi požadavky na Tiller z vnějšku clusteru.
Zajistili jsme tedy připojovací kanál k Tilleru, již jsme probrali RBAC a upravili práva apiserveru Kubernetes, čímž jsme zredukovali doménu, se kterou může interagovat.
Chráněná přilba
Podívejme se na konečný diagram. Je to stejná architektura se stejnými šipkami.
Všechna spojení lze nyní bezpečně nakreslit zeleně:
- pro Chart Repo používáme TLS nebo mTLS a základní auth;
- mTLS pro Tiller a je vystavena jako služba gRPC s TLS, používáme certifikáty;
- cluster používá speciální účet služby s Role a RoleBinding.
Cluster jsme významně zabezpečili, ale někdo chytrý řekl:
"Naprosto bezpečné řešení může být jen jedno - vypnutý počítač, který je umístěn v betonové krabici a hlídají ho vojáci."
Existují různé způsoby, jak manipulovat s daty a najít nové vektory útoku. Jsem však přesvědčen, že tato doporučení dosáhnou základního průmyslového standardu bezpečnosti.
prémie
Tato část přímo nesouvisí s bezpečností, ale bude také užitečná. Ukážu vám pár zajímavostí, o kterých málokdo ví. Například jak hledat grafy – oficiální i neoficiální.
V úložišti Nyní existuje asi 300 grafů a dva streamy: stabilní a inkubátor. Každý, kdo přispívá, moc dobře ví, jak těžké je dostat se z inkubátoru do stáje a jak snadné je vylétnout ze stáje. Toto však není nejlepší nástroj pro vyhledávání grafů pro Prometheus a cokoli dalšího, co se vám líbí, a to z jednoho prostého důvodu – není to portál, kde byste mohli pohodlně vyhledávat balíčky.
Ale je tu služba , díky čemuž je hledání grafů mnohem pohodlnější. Nejdůležitější je, že je k dispozici mnohem více externích úložišť a téměř 800 kouzel. Navíc můžete své úložiště připojit, pokud z nějakého důvodu nechcete své grafy posílat do stáje.
Vyzkoušejte hub.helm.sh a pojďme to společně vyvinout. Tato služba spadá pod projekt Helm a můžete dokonce přispět k jejímu uživatelskému rozhraní, pokud jste front-end vývojář a chcete pouze vylepšit vzhled.
Rád bych vás také upozornil na Otevřená integrace Service Broker API. Zní to těžkopádně a nejasně, ale řeší problémy, se kterými se potýká každý. Dovolte mi to vysvětlit na jednoduchém příkladu.
Existuje cluster Kubernetes, ve kterém chceme provozovat klasickou aplikaci – WordPress. Obecně je pro plnou funkčnost potřeba databáze. Existuje mnoho různých řešení, například můžete spustit vlastní stavovou službu. To není příliš pohodlné, ale mnoho lidí to dělá.
Jiní, jako my v Chainstack, používají pro své servery spravované databáze jako MySQL nebo PostgreSQL. Proto jsou naše databáze umístěny někde v cloudu.
Nastává ale problém: potřebujeme propojit naši službu s databází, vytvořit příchuť databáze, přenést přihlašovací údaje a nějak to spravovat. To vše obvykle provádí ručně správce systému nebo vývojář. A není problém, když je aplikací málo. Když je jich hodně, potřebujete kombajn. Existuje takový kombajn - to je Service Broker. Umožňuje používat speciální plugin pro veřejný cloudový cluster a objednávat zdroje od poskytovatele přes Broker, jako by to bylo API. K tomu můžete použít nativní nástroje Kubernetes.
Je to velmi jednoduché. Můžete se například dotazovat na Managed MySQL v Azure se základní vrstvou (tu lze nakonfigurovat). Pomocí Azure API bude databáze vytvořena a připravena k použití. Do toho nemusíte zasahovat, za to může plugin. Například OSBA (Azure plugin) vrátí pověření do služby a předá je Helmu. Budete moci používat WordPress s cloudovým MySQL, vůbec se nezabývat spravovanými databázemi a nestarat se o stavové služby uvnitř.
Můžeme říci, že Helm funguje jako lepidlo, které na jedné straně umožňuje nasazovat služby a na druhé spotřebovává zdroje cloudových poskytovatelů.
Můžete si napsat svůj vlastní plugin a použít celý tento příběh on-premise. Pak už budete mít jednoduše svůj vlastní plugin pro firemního poskytovatele Cloudu. Doporučuji vyzkoušet tento přístup, zvláště pokud máte velký rozsah a chcete rychle nasadit vývoj, staging nebo celou infrastrukturu pro funkci. To usnadní život vašim operacím nebo DevOps.
Další nález, který jsem již zmínil, je plugin helm-gcs, která vám umožňuje používat Google-buckety (úložiště objektů) k ukládání Helmových diagramů.
Abyste jej mohli začít používat, potřebujete pouze čtyři příkazy:
- nainstalovat plugin;
- iniciovat to;
- nastavte cestu k bucketu, který se nachází v gcp;
- publikovat grafy standardním způsobem.
Krása spočívá v tom, že pro autorizaci bude použita nativní metoda gcp. Můžete použít servisní účet, účet vývojáře, cokoli chcete. Je to velmi pohodlné a provoz nic nestojí. Pokud jako já prosazujete filozofii opsless, pak to bude velmi výhodné, zejména pro malé týmy.
Alternativy
Helm není jediným řešením správy služeb. Je kolem toho spousta otazníků, pravděpodobně proto se tak rychle objevila třetí verze. Samozřejmě existují alternativy.
Mohou to být specializovaná řešení, například Ksonnet nebo Metaparticle. Ke stejným účelům, o kterých jsem mluvil, můžete použít své klasické nástroje pro správu infrastruktury (Ansible, Terraform, Chef atd.).
Konečně existuje řešení , jehož obliba roste.
Operator Framework je nejlepší alternativou Helm, kterou je třeba zvážit.
Je nativní pro CNCF a Kubernetes, ale překážka vstupu je mnohem vyšší, musíte více programovat a méně popisovat manifesty.
Existují různé addony, jako je Draft, Scaffold. Hodně usnadňují život, například vývojářům zjednodušují cyklus odesílání a spouštění Helmu k nasazení testovacího prostředí. Nazval bych je zmocněnci.
Zde je vizuální tabulka, kde vše je.
Na ose x je úroveň vaší osobní kontroly nad tím, co se děje, na ose y je úroveň nativního prostředí Kubernetes. Helm verze 2 spadá někde uprostřed. Ve verzi 3 ne nějak enormně, ale zlepšilo se jak ovládání, tak úroveň nativnosti. Řešení na úrovni Ksonnet jsou stále horší než Helm 2. Nicméně stojí za to se na ně podívat, abyste věděli, co dalšího je na tomto světě. Správce konfigurace bude samozřejmě pod vaší kontrolou, ale absolutně není nativní pro Kubernetes.
Operator Framework je naprosto nativní pro Kubernetes a umožňuje vám jej spravovat mnohem elegantněji a pečlivěji (ale nezapomeňte na vstupní úroveň). To je vhodné spíše pro specializovanou aplikaci a tvorbu managementu pro ni, než pro hromadný kombajn pro balení velkého množství aplikací pomocí Helm.
Extendery jednoduše trochu zlepšují ovládání, doplňují pracovní tok nebo ořezávají rohy CI/CD potrubí.
Budoucnost Helma
Dobrou zprávou je, že přichází Helm 3. Alfa verze Helm 3.0.0-alpha.2 již byla vydána, můžete si ji vyzkoušet. Je poměrně stabilní, ale funkčnost je stále omezená.
Proč potřebujete Helm 3? Za prvé, toto je příběh o zmizení Tillera, jako součást. To, jak jste již pochopili, je obrovský krok vpřed, protože z hlediska bezpečnosti architektury je vše zjednodušeno.
Když byl vytvořen Helm 2, což bylo přibližně v době Kubernetes 1.8 nebo ještě dříve, mnoho konceptů bylo nezralých. Například koncept CRD je nyní aktivně implementován a Helm bude používat CRDk uložení konstrukcí. Bude možné používat pouze klienta a neudržovat serverovou část. V souladu s tím používejte k práci se strukturami a prostředky nativní příkazy Kubernetes. To je obrovský krok vpřed.
Objeví se podpora nativních úložišť OCI (Iniciativa pro otevření kontejneru). Jde o obrovskou iniciativu a Helm se zajímá především o zveřejnění svých žebříčků. Dochází k tomu, že například Docker Hub podporuje mnoho standardů OCI. Nehádám, ale možná vám klasičtí poskytovatelé úložišť Docker začnou dávat příležitost hostovat vaše grafy Helm.
Kontroverzní příběh pro mě je Podpora Lua, jako šablonovací engine pro psaní skriptů. Nejsem velkým fanouškem Lua, ale toto by byla zcela volitelná funkce. Zkontroloval jsem to 3krát - použití Lua nebude nutné. Proto ti, kteří chtějí mít možnost používat Lua, ti, kteří mají rádi Go, se připojte k našemu obrovskému táboru a použijte k tomu go-tmpl.
Konečně, co mi rozhodně chybělo vznik schématu a ověření datového typu. Už nebudou žádné problémy s int nebo řetězcem, není třeba zabalovat nulu do dvojitých uvozovek. Zobrazí se schéma JSONS, které vám umožní explicitně popsat toto pro hodnoty.
Bude silně přepracován událostmi řízený model. Už to bylo koncepčně popsáno. Podívejte se na větev Helm 3 a uvidíte, kolik událostí a háčků a dalších věcí přibylo, což značně zjednoduší a na druhou stranu přidá kontrolu nad procesy nasazení a reakcemi na ně.
Helm 3 bude jednodušší, bezpečnější a zábavnější, ne proto, že bychom neměli rádi Helm 2, ale protože Kubernetes je stále pokročilejší. V souladu s tím může Helm využít vývoj Kubernetes a vytvořit na něm vynikající manažery pro Kubernetes.
Další dobrou zprávou je, že Alexander Khayorov vám řekne, Připomeňme, že konference o integraci vývojových, testovacích a provozních procesů se bude konat v Moskvě 30. září a 1. října. Stále to můžete udělat do 20. srpna a řekněte nám o své zkušenosti s řešením úkoly přístupu DevOps.
Sledujte kontrolní body konference a novinky na и .
Zdroj: www.habr.com