Podstata příběhu o nejoblíbenějším správci balíčků pro Kubernetes by mohla být znázorněna pomocí emoji:
- krabice — to je Helm (to je nejpřesnější, co je v poslední verzi Emoji);
- zámek — bezpečnost;
- človíček — řešení problému.
Ve skutečnosti to však bude o něco složitější a příběh je plný technických podrobností o tom, jak učinit Helm bezpečným.
- Stručně o tom, co je Helm, pokud jste to nevěděli nebo zapomněli. Jaké problémy řeší a kde se nachází v ekosystému.
- Podívejme se na architekturu Helmu. Žádná diskuse o bezpečnosti a o tom, jak učinit nástroj nebo řešení bezpečnější, se neobejde bez pochopení architektury komponentu.
- Probereme komponenty Helmu.
- Nejpalčivější otázka — budoucnost — nová verze Helmu 3.
Vše v tomto článku se vztahuje na Helm 2. Tato verze je nyní v produkci a pravděpodobně je to ta, kterou právě používáte, a právě v ní jsou bezpečnostní hrozby.
O řečníkovi: Alexander Chajjorov () se věnuje vývoji 10 let, pomáhá zlepšovat obsah a připojil se k výboru . Nyní pracuje v Chainstack jako vedoucí vývoje — což je hybrid mezi vedoucím vývoje a osobou, která odpovídá za doručování finálních verzí. To znamená být na frontové linii, kde se děje všechno od vytváření produktu až po jeho provoz.
Chainstack je malý, aktivně rostoucí startup, jehož úkolem je poskytnout zákazníkům možnost zapomenout na infrastrukturu a složitosti operování decentralizovaných aplikací, tým vývoje se nachází v Singapuru. Neptejte se Chainstacku, aby prodal nebo koupil kryptoměnu, ale nabídněte jim, že si promluvíte o podnikových blockchainových rámcích, a radostně vám odpoví.
Helm
Jedná se o správce balíčků (chartů) pro Kubernetes. Nejjednodušší a nejuniverzálnější způsob, jak dostat aplikace do Kubernetes clusteru.
Řeč je samozřejmě o strukturovanějším a průmyslovějším přístupu, než o vytváření vlastních YAML manifestů a psaní malých utilit.
Helm je to nejlepší, co je nyní k dispozici a populární.
Proč Helm? Především proto, že je podporován CNCF. Cloud Native je velká organizace, která je mateřskou společností projektů Kubernetes, etcd, Fluentd a dalších.
Jiný důležitý fakt je, že Helm je velmi populární projekt. Když jsem v lednu 2019 začal přemýšlet o tom, jak zefektivnit bezpečnost Helmu, měl projekt tisíc hvězdiček na GitHubu. Do května jich již bylo 12 tisíc.
Mnozí se zajímají o Helm, a proto, i když jej dosud nepoužíváte, vaše znalosti o jeho bezpečnosti se vám budou hodit. Bezpečnost je důležitá.
Hlavní tým Helmu podporuje Microsoft Azure, a proto je to poměrně stabilní projekt na rozdíl od mnoha jiných. Vydání Helm 3 Alpha 2 v polovině července svědčí o tom, že na projektu pracuje dostatek lidí, kteří mají chuť a sílu Helm rozvíjet a zlepšovat.
Helm řeší několik základních problémů správy aplikací v Kubernetes.
- Balení aplikací. I aplikace typu 'Hello, World' na WordPress představuje několik služeb, které je potřeba zabalit dohromady.
- Správa složitosti, která vzniká při managementu těchto aplikací.
- Životní cyklus, který nekončí po instalaci nebo nasazení aplikace. Ta pokračuje v životě, je třeba ji aktualizovat, a v tom pomáhá Helm a snaží se přinést správná opatření a politiky.
Balení je uspořádáno pochopitelným způsobem: existují metadata v plném souladu s prací běžného správce balíčků pro Linux, Windows nebo MacOS. To znamená repozitář, závislosti na různých balíčcích, metainformace pro aplikace, nastavení, konfigurace, indexování informací atd. To vše Helm umožňuje získat a používat pro aplikace.
Správa složitosti. Pokud máte hodně podobných aplikací, je potřeba parametrizace. Z toho vyplývají šablony, ale abyste nemuseli vymýšlet svůj vlastní způsob tvorby šablon, můžete využít to, co Helm nabízí již v základu.
Management životního cyklu aplikace — to je podle mého názoru nejzajímavější a nevyřešené téma. To je důvod, proč jsem se v té době dostal k Helmu. Potřebovali jsme sledovat životní cyklus aplikace, chtěli jsme přenést svůj CI/CD a cykly aplikací do této paradigmatu.
Helm umožňuje:
- spravovat nasazení, zavádí pojem konfigurace a revize;
- úspěšně provádět rollback;
- využívat hooky na různé události;
- přidávat další kontroly aplikací a reagovat na jejich výsledky.
Kromě toho Helm má 'baterky' — obrovské množství chutných věcí, které lze zahrnout jako pluginy, čímž si usnadníte život. Pluginy si můžete psát sami, jsou dostatečně izolované a nevyžadují složitou architekturu. Pokud chcete něco realizovat, doporučuji to udělat jako plugin a potom to možná zahrnout do upstreamu.
Helm se zakládá na třech základních konceptech:
- Chart Repo — popis a pole parametrizace, které jsou možné pro váš manifest.
- Nastavení — tedy hodnoty, které budou aplikovány (text, číselné hodnoty atd.).
- Release obsahuje dva vrcholné komponenty, a dohromady se promění v Release. Vydání lze verziovat, čímž se dosáhne organizace životního cyklu: malé při instalaci a velké při upgrade, downgrade nebo rollbacku.
Architektura Helm
Na schématu je konceptuálně zobrazená vysoce úrovňová architektura Helm.
Připomínám, že Helm je něco, co souvisí s Kubernetes. Proto se bez Kubernetes clusteru neobejdeme (obdélník). Komponent kube-apiserver se nachází na masteru. Bez Helmu máme Kubeconfig. Helm přináší jeden malý binární, pokud to lze tak nazvat, nástroj Helm CLI, který se instaluje na počítač, notebook, mainframe — na cokoliv.
Ale to nestačí. Helm má serverovou komponentu Tiller. Ta zastupuje zájmy Helmu uvnitř clusteru, je to stejné aplikace uvnitř clusteru Kubernetes jako jakákoli jiná.
Další komponent Chart Repo — repozitář s chartami. Existuje oficiální repozitář, a může to být privátní repozitář společnosti nebo projektu.
Interakce
Podívejme se, jak spolu komunikují komponenty architektury, když chceme nainstalovat aplikaci pomocí Helmu.
- Říkáme
Helm install, obracíme se na repozitář (Chart Repo) a získáváme Helm chart.
- Helm nástroj (Helm CLI) interaguje s Kubeconfig, aby zjistil, ke kterému clusteru se připojit.
- Po získání těchto informací se nástroj obrací na Tiller, který se nachází v našem clusteru, již jako na aplikaci.
- Tiller se obrací na Kube-apiserver, aby provedl akce v Kubernetes, vytvořil nějaké objekty (služby, pody, repliky, tajné informace atd.).
Dále schéma zkomplikujeme, abychom viděli vektory útoků, kterými může být celá architektura Helmu vystavena. A pak se pokusíme ji ochránit.
Vektor útoků
První potenciálně slabé místo — privilegovaný API—uživateli. V rámci schématu je to hacker, který získal administrátorský přístup k Helm CLI.
Nepřidělený API uživatel může také představovat nebezpečí, pokud se nachází poblíž. Takový uživatel bude mít jiný kontext, například může být zafixován v jednom namespace clusteru v nastaveních Kubeconfig.
Nejzajímavějším vektorem útoku může být proces, který se nachází uvnitř clusteru někde poblíž Tiller a může k němu přistupovat. Může to být webový server nebo mikroslužba, která vidí síťové prostředí clusteru.
Exotická, ale stále více populární varianta útoku souvisí s Chart Repo. Graf, vytvořený nedbalým autorem, může obsahovat nebezpečný zdroj a vy ho vykonáte, aniž byste o tom pochybovali. Nebo může nahradit graf, který stahujete z oficiálního repozitáře, a například vytvořit zdroj ve formě politiky a eskalovat si přístup.
Pokud se pokusíme odrazit útoky ze všech těchto čtyř stran, zjistíme, kde jsou problémy v architektuře Helm a kde možná nejsou.
Zvětšíme schéma, přidáme více prvků, ale zachováme všechny základní součásti.
Helm CLI komunikuje s Chart Repo, interaguje s Kubeconfig, práce je předána do clusteru v komponentě Tiller.
Tiller je reprezentován dvěma objekty:
- Tiller-deploy svc, který vystavuje jakýsi servis;
- Tiller-deploy pod (na schématu v jediném exempláři v jedné replikaci), na kterém běží veškerá zátěž, který se obrací na cluster.
Pro interakci se používají různé protokoly a schémata. Z pohledu bezpečnosti nás nejvíce zajímají:
- Mechanismus, pomocí kterého se Helm CLI obrací na chart repo: jaký protokol, jestli existuje autentizace a co s tím lze udělat.
- Protokol, podle kterého Hel CLI, používající kubectl, komunikuje s Tiller. To je RPC server instalovaný uvnitř clusteru.
- Sám Tiller je dostupný pro mikroslužby, které se nacházejí v clusteru, a interaguje s Kube-apiserver.
Probereme všechny tyto směry postupně.
RBAC
Je zbytečné hovořit o jakékoli bezpečnosti Helm nebo jiných služeb uvnitř clusteru, pokud není zapnuto RBAC.
Zdá se, že to není úplně čerstvé doporučení, ale jsem si jistý, že mnozí stále nezapnuli RBAC ani v produkci, protože to vyžaduje spoustu úsilí a je potřeba mnoho co nastavit. Nicméně, vyzývám k tomu, abyste to udělali.
— právnická stránka pro RBAC. Obsahuje obrovské množství zajímavého materiálu, který pomůže nastavit RBAC, ukáže, proč je dobrý a jak s ním v podstatě žít v produkci.
Zkusím vysvětlit, jak funguje Tiller a RBAC. Tiller pracuje uvnitř clusteru pod určitým servisním účtem. Obvykle, pokud není RBAC nastaven, bude to superuživatel. V základní konfiguraci bude Tiller administrátorem. Právě proto se často říká, že Tiller je SSH tunel k vašemu clusteru. V praxi je to pravda, takže můžete použít oddělený specializovaný servisní účet místo výchozího servisního účtu na schématu výše.
Když inicializujete Helm, poprvé ho instalujete na server, můžete nastavit servisní účet pomocí --service-account. To umožní použít uživatele s minimálně nezbytnými oprávněními. Bohužel, budete muset vytvořit takovou "girlandu": Role a RoleBinding.
Bohužel, Helm to za vás neudělá. Vy nebo váš administrátor Kubernetes clusteru musíte předem připravit sady Role, RoleBinding pro servisní účet, aby byly předány Helmu.
Pojďme se zeptat — jaký je rozdíl mezi Role a ClusterRole? Rozdíl je v tom, že ClusterRole platí pro všechny namespaces, na rozdíl od běžných Role a RoleBinding, které fungují pouze pro specializovaný namespace. Můžete nastavit politiky jak pro celý cluster a všechny namespaces, tak individuálně pro každý namespace zvlášť.
Je třeba zmínit, že RBAC také řeší ještě jeden velký problém. Mnozí si stěžují, že Helm bohužel nepodporuje multitenancy. Pokud několik týmů využívá cluster a používá Helm, nelze v podstatě nastavit politiky a omezit jejich přístup v rámci tohoto clusteru, protože je tu určitý servisní účet, pod kterým Helm pracuje, a ten vytváří všechny prostředky v clusteru, což může být velmi nepohodlné. To je pravda — jak samotný binární soubor, tak proces, Helm Tiller nemá pojem o multitenancy..
Existuje však skvělý způsob, jak spustit Tiller v clusteru několikrát. S tím nejsou žádné problémy, Tiller lze spustit v každém namespace. Tímto způsobem můžete využít RBAC, Kubeconfig jako kontext a omezit přístup k specializovanému Helmu.
Bude to vypadat následovně.
Například existují dvě Kubeconfig s kontexty pro různé týmy (dvě namespace): tým X pro vývojáře a cluster administrátorů. Cluster administrátorů má svůj široký Tiller, který se nachází v prostoru namespace Kube-system, což odpovídá pokročilému service-account. A samostatný namespace pro tým vývojářů, kteří mohou nasazovat své služby do speciálního namespace.
To je funkční přístup, Tiller není tak náročný, aby to výrazně ovlivnilo váš rozpočet. To je jedno z rychlých řešení.
Nebojte se nastavit Tiller odděleně a poskytnout Kubeconfig s kontextem pro tým, pro konkrétního vývojáře nebo pro prostředí: Dev, Staging, Production (je pochybné, že vše bude na jednom clusteru, nicméně, udělat to lze).
Pokračujeme v našem příběhu, přepneme se od RBAC a budeme mluvit o ConfigMaps.
ConfigMaps
Helm používá ConfigMaps jako úložiště dat. Když jsme hovořili o architektuře, nikde tam nebyla databáze, která by uchovávala informace o relezech, konfiguracích, rollbacks atd. K tomu se používají ConfigMaps.
Hlavní problém s ConfigMaps je známý — nejsou bezpečné v principu, lze v nich uchovávat sensitive-údaje. Jde o vše, co by se nemělo dostat dál od služby, například hesla. Nejpřirozenějším způsobem pro Helm je nyní přejít od používání ConfigMaps k tajemstvím.
To se dělá velmi jednoduše. Předefinujete nastavení Tiller a uvedete, že úložištěm budou tajemství. Pak při každém nasazení dostanete místo ConfigMapu tajemství.
Můžete namítnout, že sama tajemství — podivný koncept, a to není příliš bezpečné. Nicméně, je třeba chápat, že tímto se zabývají sami vývojáři Kubernetes. Od verze 1.10, tedy už nějakou dobu, je možnost, minimálně v veřejných cloudech, připojit správné úložiště pro uchovávání tajemství. V současnosti tým pracuje na tom, jak lépe distribuovat přístup k tajemstvím, jednotlivým podům nebo jiným entitám.
Úložiště Helm by se mělo převést na tajemství, a ta zase zabezpečit centrálně.
Samozřejmě, zůstane limit pro uchovávání dat v 1 Mbyte. Helm zde používá etcd jako distribuované úložiště pro ConfigMaps. A tam zjistili, že je to vhodný chunk dat pro replikaci a podobně. K tomu je zajímavá diskuse na Redditu, doporučuji najít si tuto zábavnou četbu na víkend nebo si přečíst shrnutí. .
Repoziáře chartů
Charty jsou nejvíce sociálně zranitelné a mohou se stát zdrojem "Man in the middle", obzvlášť pokud se používá standardní řešení. Především se jedná o repozitáře, které jsou vystaveny přes HTTP.
Určitě je potřeba vystavovat Helm Repo přes HTTPS — to je nejlepší varianta a není drahá.
Vezměte na vědomí mechanismus podpisů chartů. Technologie je úžasně jednoduchá. Je to to samé, co používáte na GitHubu, obyčejná PGP mašinerie s veřejnými a soukromými klíči. Nastavte si to a budete si jisti, máte-li potřebné klíče a podepisujete vše, co je opravdu váš chart.
Kromě toho, Helm klient podporuje TLS (ne v smyslu HTTP ze strany serveru, ale vzájemný TLS). Můžete použít serverové a klientské klíče pro komunikaci. Přiznám se, že tuto metodu nepoužívám kvůli neochotě k vzájemným certifikátům. V zásadě, — hlavní nástroj pro vystavování Helm Repo pro Helm 2 — podporuje také basic auth. Můžete použít basic auth, pokud je to pohodlnější a bezpečnější.
Je tu také plugin , který umožňuje umísťovat Chart Repos do Google Cloud Storage. Je to docela pohodlné, skvěle to funguje a je to dost bezpečné, protože se používají všechny popsané mechanismy.
Pokud zapnete HTTPS nebo TLS, použijete mTLS, připojíte basic auth, abyste snížili rizika, vznikne bezpečný komunikační kanál mezi Helm CLI a Chart Repo.
gRPC API
Další krok je velmi odpovědný — zabezpečit Tiller, který se nachází v klastru a je na jedné straně serverem, na druhé straně se sám obrací na jiné komponenty a snaží se představit jako někdo jiný.
Jak jsem již řekl, Tiller je služba, která vystavuje gRPC, Helm klient k němu přichází přes gRPC. Ve výchozím nastavení je samozřejmě TLS vypnuto. Proč je to takto uděláno — to je diskutabilní otázka, připadá mi, že to má zjednodušit nastavení na začátku.
Pro produkci a dokonce i pro staging doporučuji zapnout TLS na gRPC.
Podle mého názoru, na rozdíl od mTLS pro chartové soubory, je zde to vhodné a velice jednoduché — generujete PQI infrastrukturu, vytváříte certifikát, spouštíte Tiller a předáváte certifikát během inicializace. Poté můžete provádět všechny Helm příkazy s použitím vygenerovaného certifikátu a privátního klíče.
Tímto se ochráníte před všemi požadavky na Tiller zvenčí klastru.
Takže jsme zabezpečili kanál připojení k Tiller, již jsme probrali RBAC a nastavili práva Kubernetes apiserveru, zúžili jsme doménu, se kterou může komunikovat.
Zabezpečený Helm
Podívejme se na finální schéma. To je stejná architektura se stejnými šipkami.
Všechny připojení nyní lze bez obav kreslit zeleně:
- pro Chart Repo používáme TLS nebo mTLS a základní autentizaci;
- mTLS pro Tiller, který je vystaven jako gRPC služba s TLS, používáme certifikáty;
- ve klastru používáme speciální servisní účet s Role a RoleBinding.
Výrazně jsme zabezpečili klastr, ale někdo chytrý řekl:
„Absolutně bezpečné řešení může být pouze jedno — vypnutý počítač, který se nachází v betonové krabičce a hlídají ho vojáci.“
Existují různé způsoby manipulací s daty a nalezení nových vektorů útoku. Jsem však přesvědčen, že tato doporučení umožní implementovat základní průmyslový standard bezpečnosti.
Bonus
Tato část se přímo netýká bezpečnosti, ale také bude užitečná. Ukážu některé zajímavé věci, o kterých mnoho lidí neví. Například, jak hledat chartové soubory — oficiální i neoficiální.
V repozitáři v současnosti je k dispozici přibližně 300 chartů a dva streamy: stable a incubator. Ten, kdo přispívá, ví, jak obtížné je dostat se z incubator do stable a jak snadno lze ze stable vypadnout. Nicméně, to není nejlepší nástroj pro vyhledávání chartů pro Prometheus a pro všechno, co se vám líbí, z jednoho prostého důvodu — není to portál, kde by se pohodlně hledaly balíčky.
Ale existuje služba , pomocí které je hledání chartů mnohem pohodlnější. Hlavní je, že tam je mnohem více externích repozitářů a dostupných téměř 800 chartů. Navíc, můžete připojit svůj repozitář, pokud z nějakého důvodu nechcete posílat své chartové soubory do stable.
Vyzkoušejte hub.helm.sh a pojďme ho společně rozvíjet. Tato služba je pod projektem Helm a můžete přispět i do jeho UI, pokud jste front-end vývojář a chcete jen zlepšit vzhled.
Chci ještě upozornit na integraci Open Service Broker API. Zní to složitě a nejasně, ale řeší úkoly, s nimiž se každý potýká. Vysvětlím to na jednoduchém příkladu.
Máme Kubernetes cluster, ve kterém chceme spustit klasickou aplikaci — WordPress. Obvykle pro plnou funkčnost potřebujeme databázi. Existuje mnoho různých řešení, například můžeme spustit svůj stateful servis. To není příliš pohodlné, ale mnoho lidí to tak dělá.
Jiní, například my v Chainstack, používají spravované databáze, jako je MySQL nebo PostgreSQL, pro servery. Proto máme databázi někde v cloudu.
Ale vzniká problém: musíme propojit naši službu s databází, vytvořit flavor databáze, předat přihlašovací údaje a nějak s nimi spravovat. To vše se obvykle dělá ručně systémovým administrátorem nebo vývojářem. A není žádný problém, když je aplikací málo. Když jich je hodně, potřebujete kombinátor. Takový kombinátor existuje — to je Service Broker. Umožňuje použít speciální plugin na klastru veřejného cloudu a objednávat zdroje u poskytovatele prostřednictvím Brokeru, jako by to bylo API. Pro to lze použít nativní prostředky Kubernetes.
Je to velmi jednoduché. Můžete například požádat o Managed MySQL v Azure s základním tierem (to lze nastavit). S použitím Azure API bude databáze vytvořena a připravena k použití. Nebudete do toho muset zasahovat, za to odpovídá plugin. Například, OSBA (plugin Azure) vrátí přihlašovací údaje do služby a předá je Helm. Budete moci používat WordPress s cloudovým MySQL, aniž byste se museli zabývat spravovanými databázemi a starat se o stateful služby uvnitř.
Můžeme říci, že Helm funguje jako lepidlo, které na jedné straně umožňuje nasazovat služby a na druhé straně spotřebovávat zdroje cloudových poskytovatelů.
Můžete napsat svůj vlastní plugin a využít celou tuto historii on-premise. Pak budete mít zkrátka svůj plugin pro podnikového cloudového poskytovatele. Doporučuji vyzkoušet takový přístup, zejména pokud máte velký rozsah a chcete rychle nasadit dev, staging nebo celou infrastrukturu pro funkci. To zjednoduší život vašim operacím nebo DevOps.
Další objev, který jsem již zmínil, je plugin helm-gcs, který vám umožňuje používat Google buckets (objektové úložiště) k ukládání Helm chartů.
Potřebujete pouze čtyři příkazy k jeho použití:
- nainstalovat plugin;
- spustit jeho inicializaci;
- nastavit cestu k bucketu, který se nachází v gcp;
- publikovat grafy standardním způsobem.
Kouzlo spočívá v tom, že se použije nativní metoda gcp pro autorizaci. Můžete použít servisní účet, účet vývojáře — cokoliv. Je to velmi pohodlné a nevyžaduje to žádné náklady na provoz. Pokud jako já propagujete filozofii opsless, tak to bude velmi pohodlné, zejména pro malé týmy.
Alternativy
Helm není jediným řešením pro správu služeb. Mnoho lidí má k tomu otázky, pravděpodobně proto rychle vznikla třetí verze. Samozřejmě existují alternativy.
Mohou to být specializovaná řešení jako Ksonnet nebo Metaparticle. Můžete použít své klasické nástroje pro správu infrastruktury (Ansible, Terraform, Chef atd.) pro stejné účely, o kterých jsem mluvil.
Nakonec existuje řešení , jehož popularita roste.
Operator Framework je hlavní alternativou k Helmu, na kterou byste se měli zaměřit.
Je více nativní pro CNCF a Kubernetes, ale vstupní prah je mnohem vyšší, je potřeba více programovat a méně popisovat manifesty.
Existují různé doplňky, jako je Draft, Scaffold. Tyto nástroje výrazně usnadňují život, například vývojářům zjednodušují cyklus odesílání a spuštění Helmu pro nasazení testovacího prostředí. Nazval bych je rozšiřovači možností.
Tady je názorný graf o tom, kde co leží.
Na ose x je úroveň vaší osobní kontroly nad děním, na ose y — úroveň nativnosti Kubernetes. Helm verze 2 je někde uprostřed. Verze 3 nepřináší dramatické změny, ale zlepšuje jak kontrolu, tak i úroveň nativnosti. K řešením typu Ksonnet se doporučuje podívat, i když zaostávají za Helm 2. Samozřejmě, váš konfigurační manažer bude pod vaší kontrolou, ale není zcela nativní pro Kubernetes.
Operator Framework je zcela nativní pro Kubernetes a umožňuje spravovat ho mnohem elegantněji a důkladněji (ale nezapomínejme na vstupní úroveň). Spíše to vyhovuje specializované aplikaci a vytvoření jejího managementu, než masovému stroji pro balení velkého množství aplikací pomocí Helmu.
Rozšiřovače prostě mírně zlepšují kontrolu, doplňují workflow nebo zjednodušují CI/CD pipelines.
Budoucnost Helmu
Dobrá zpráva je, že se objevuje Helm 3. Již vyšla alfa verze 3.0.0-alpha.2, kterou si můžete vyzkoušet. Je dostatečně stabilní, ale funkčnost je zatím omezená.
K čemu je Helm 3? V první řadě se jedná o vymizení Tillera, jakožto komponentu. To je, jak už chápete, obrovský krok vpřed, protože z pohledu bezpečnosti architektury se vše zjednodušuje.
Když se vytvářel Helm 2, a to bylo za dob Kubernetes 1.8 nebo dokonce dříve, mnoho koncepcí bylo nezralých. Například koncept CRD se nyní aktivně implementuje a Helm bude používat CRD, aby uchovával struktury. Bude možné používat pouze klienta a nemusíte mít serverovou část. Odpovídajícím způsobem můžete používat nativní příkazy Kubernetes pro práci se strukturami a zdroji. To je obrovský krok vpřed.
Objeví se podpora nativních repozitářů OCI (Open Container Initiative). To je obrovská iniciativa a pro Helm je zajímavá především pro umísťování vlastních chartů. Dokonce i Docker Hub podporuje mnoho standardů OCI. Nemohu předpovědět, ale je možné, že klasické poskytovatele Docker repozitářů začnou nabízet možnost umístit své Helm chart.
Sporná otázka pro mě je podpora Lua, jako šablonovacího engine pro psaní skriptů. Nejsem velkým fanouškem Lua, ale to bude zcela volitelná možnost. Ověřil jsem to třikrát — použití Lua nebude povinné. Takže kdo chce, může použít Lua, kdo má rád Go — připojte se k našemu obrovskému táboru a použijte go-tmpl pro to.
Nakonec to, co mi určitě chybělo, je existence schématu a validace datových typů. Už nebudou problémy s int nebo string, nebude potřeba obalovat nula do dvojitých uvozovek. Objeví se JSON schema, které umožní jasně to popsat pro values.
Bude velmi silně přepracována model z pohledu událostí. Již byla konceptuálně popsána. Podívejte se do větve Helm 3 a uvidíte, kolik událostí, hooků a jiného bylo přidáno, co velmi zjednoduší a na druhou stranu přidá kontrolu nad průběhem nasazování a reakcemi na ně.
Helm 3 bude jednodušší, bezpečnější a zajímavější ne proto, že bychom neměli rádi Helm 2, ale protože Kubernetes se stává pokročilejším. Odpovídajícím způsobem může Helm využívat poznatky Kubernetes a vytvářet na něm vynikající správce pro Kubernetes.
Další dobrou zprávou je, že na Alexandr Chajerov poví, Připomínáme, že konference o integraci procesů vývoje, testování a provozu se koná v Moskvě 30. září a 1. října. Do 20. srpna je ještě možné a podělit se o své zkušenosti s řešením úloh DevOps přístupu.
Sledujte novinky a dění konference na a .
Zdroj: habr.com
