Podstata príbehu o najpopulárnejšom balíčkovom správcovi pre Kubernetes by sa dala znázorniť pomocou emoji:
- krabica — to je Helm (to je najvhodnejšie, čo máme v najnovšej verzii Emoji);
- zámok — bezpečnosť;
- človek — riešenie problému.
V skutočnosti to však bude o čosi zložitejšie a príbeh je plný technických podrobností o tom, ako zabezpečiť Helm..
- Stručne, čo je Helm, ak ste to nevedeli alebo ste zabudli. Aké problémy rieši a kde sa nachádza v ekosystéme.
- Pozrime sa na architektúru Helmu. Žiadna diskusia o bezpečnosti a o tom, ako urobiť nástroj alebo riešenie bezpečnejším, sa nezaobíde bez pochopenia architektúry komponentu.
- Prediskutujme komponenty Helmu.
- Najpalčivejšia otázka — budúcnosť — nová verzia Helmu 3.
Všetko v tomto článku sa týka Helmu 2. Táto verzia je teraz v produkcii a pravdepodobne ju práve používate, a práve v nej sú bezpečnostné hrozby.
O prednášajúcom: Alexander Chajov () sa vyvíjaním zaoberá 10 rokov, pomáha zlepšovať obsah a pripojil sa k výboru . Teraz pracuje v Chainstack na pozícii vedúceho vývoja — to je hybrid medzi riaditeľom vývoja a osobou zodpovednou za dodávku konečných vydaní. To znamená, že sa nachádza na bojisku, kde sa deje všetko od vytvorenia produktu až po jeho prevádzku.
Chainstack je malý, aktívne rastúci startup, ktorého úlohou je umožniť klientom zabudnúť na infraštruktúru a zložitosti prevádzkovania decentralizovaných aplikácií, tím vývoja sa nachádza v Singapure. Nepýtajte sa Chainstack na predaj alebo nákup kryptomien, ale ponúknite sa, že sa porozprávate o podnikových blockchainových rámcoch, a oni vám s radosťou odpovedia.
Helm
Je to balíčkový správca (graf) pre Kubernetes. Najzrozumiteľnejší a najuniverzálnejší spôsob, ako priniesť aplikácie do Kubernetes klastra.
Samozrejme, ide o štruktúrnejší a priemyselný prístup, než je vytváranie vlastných YAML manifestov a písanie malých utilít.
Helm je to najlepšie, čo teraz máme z dostupných a populárnych možností.
Prečo Helm? Predovšetkým preto, že je podporovaný CNCF. Cloud Native — veľká organizácia, materská spoločnosť pre projekty Kubernetes, etcd, Fluentd a ďalšie.
Ďalší dôležitý fakt, Helm je veľmi populárny projekt. Keď som v januári 2019 začal premýšľať o tom, ako urobiť Helm bezpečným, projekt mal tisíc hviezdičiek na GitHub. Do mája ich bolo 12 tisíc.
Mnohí sa zaujímajú o Helm, takže aj keď ho zatiaľ nepoužívate, poznatky o jeho bezpečnosti sa vám zídu. Bezpečnosť je dôležitá.
Hlavný tím Helm podporuje Microsoft Azure, a preto je projekt celkom stabilný na rozdiel od mnohých iných. Vydanie Helm 3 Alpha 2 v polovici júla naznačuje, že na projekte pracuje dosť ľudí a majú chuť a silu vyvíjať a zlepšovať Helm.
Helm rieši niekoľko základných problémov správy aplikácií v Kubernetes.
- Balenie aplikácie. Aj aplikácia typu „Hello, World“ na WordPress už predstavuje niekoľko služieb, a tie by sme chceli zabalit dokopy.
- Riadenie zložitosti, ktorá vzniká pri správe týchto aplikácií.
- Životný cyklus, ktorý sa nekončí po inštalácii alebo nasadení aplikácie. Pokračuje v živote, je potrebné ho aktualizovať, a v tom mu pomáha Helm, snaží sa priniesť správne opatrenia a politiky.
Balenie je zorganizované zrozumiteľným spôsobom: existujú metadáta v úplnom súlade s fungovaním bežného správcu balíkov pre Linux, Windows alebo MacOS. Teda repozitár, závislosti od rôznych balíkov, metainformácie pre aplikácie, nastavenia, špecifiká konfigurácie, indexovanie informácií a podobne. To všetko Helm umožňuje získať a využiť pre aplikácie.
Riadenie zložitosti. Ak máte veľa rovnakých aplikácií, potrebujete parametrazáciu. Z toho vyplývajú šablóny, no aby ste nevymýšľali svoj spôsob vytvárania šablón, môžete využiť to, čo Helm ponúka priamo.
Správa životného cyklu aplikácie — podľa môjho názoru je to najzaujímavejšia a nevyriešená otázka. To je dôvod, prečo som sa v minulosti dostal k Helmu. Museli sme sledovať životný cyklus aplikácie, chceli sme presunúť svoj CI/CD a cykly aplikácií do tejto paradigmy.
Helm umožňuje:
- spravovať nasadenia, zavádza pojem konfigurácie a revízií;
- úspešne vykonávať rollback;
- používať hooky na rôzne udalosti;
- pridávať dodatočné kontroly aplikácií a reagovať na ich výsledky.
Okrem toho V Helm sú "batérie" — obrovské množstvo skvelých vecí, ktoré môžete zahrnúť ako pluginy a uľahčiť si život. Pluginy si môžete napísať sami, sú dostatočne izolované a nevyžadujú zložitú architektúru. Ak chcete niečo implementovať, odporúčam to urobiť ako plugin a neskôr to možno zahrnúť do upstream.
Helm je založený na troch základných konceptoch:
- Chart Repo — popis a súbor parametrov, ktoré sú možné pre váš manifest.
- Konfigurácia — to znamená hodnoty, ktoré budú aplikované (text, číselné hodnoty a pod.).
- Verzia zhromažďuje dva horné komponenty, ktoré sa spolu premenia na Release. Vydania môžeme verziovať, čím organizujeme životný cyklus: menšie pri inštalácii a väčšie pri upgrade, downgrade alebo rollback.
Architektúra Helm
Na schéme konceptuálne zobrazená vysoká úroveň architektúry Helm.
Pripomínam, že Helm je niečo, čo súvisí s Kubernetes. Preto sa nezaobídeme bez Kubernetes klastrov (obdĺžnik). Komponent kube-apiserver sa nachádza na master uzle. Bez Helmu máme Kubeconfig. Helm prináša jednu malú binárku, ak to môžem tak nazvať, nástroj Helm CLI, ktorý je nainštalovaný na počítači, notebooku, mainframe — na čomkoľvek.
Ale to nestačí. Helm má serverový komponent Tiller. Ten zastupuje záujmy Helmu vnútri klastrov, je to aplikácia vo vnútri klastrov Kubernetes, ako ktorákoľvek iná.
Ďalší komponent Chart Repo — repozitár s chartami. Existuje oficiálny repozitár, a môže existovať aj súkromný repozitár spoločnosti alebo projektu.
Interakcia
Pozrime sa, ako interagujú komponenty architektúry, keď chceme nainštalovať aplikáciu pomocou Helmu.
- Hovoríme
Helm install, obraciame sa na repozitár (Chart Repo) a získame Helm chart.
- Nástroj Helm (Helm CLI) interaguje s Kubeconfig, aby zistil, na ktorý klaster sa obrátiť.
- Po získaní týchto informácií sa nástroj obracia na Tiller, ktorý sa nachádza v našom klastri, už ako na aplikáciu.
- Tiller sa obracia na Kube-apiserver, aby vykonal akcie v Kubernetes, vytvoril nejaké objekty (služby, pody, repliky, tajomstvá atď.).
Následne zložíme schému, aby sme videli vektory útokov, ktorým môže byť celá architektúra Helmu vystavená. A potom sa pokúsime ju ochrániť.
Vektor útokov
Prvé potenciálne slabé miesto — privilegovaný API—používateľ. V rámci schémy je to hacker, ktorý získal administrátorský prístup k Helm CLI.
Nepprivilegovaný API používateľ taktiež môže predstavovať nebezpečenstvo, ak je niekde nablízku. Tento používateľ bude mať iný kontext, napríklad môže byť zafixovaný v jednom namespace klastru v nastaveniach Kubeconfig.
Najzaujímavejším vektorom útoku môže byť proces, ktorý sa nachádza vo vnútri klastru niekde nablízku Tilleru a môže s ním komunikovať. Môže to byť webový server alebo mikroservis, ktorý vidí sieťové prostredie klastru.
Exotická, ale čoraz populárnejšia varianta útoku je spojená s Chart Repo. Chart vytvorený nepoctivým autorom môže obsahovať nebezpečný zdroj, a vy ho vykonáte, prijímajúc ho na vieru. Alebo môže zmeniť chart, ktorý sťahujete z oficiálneho repozitára, a napríklad vytvoriť zdroj vo forme politík a eskalovať si prístup.
Skúsime sa brániť proti útokom zo všetkých štyroch strán a zistiť, kde sú tu problémy v architektúre Helm a kde, možno, nie sú.
Rozšírime schému, pridáme viac prvkov, ale zachováme všetky základné zložky.
Helm CLI komunikuje s Chart Repo, interaguje s Kubeconfig, práca sa prenáša do klastru do komponentu Tiller.
Tiller je zastúpený dvoma objektmi:
- Tiller-deploy svc, ktorý vystavuje určitý službu;
- Tiller-deploy pod (na schéme v jedinom exemplári v jednej replikácii), na ktorom beží celá záťaž, ktorý sa obracia na klaster.
Na interakciu sa používajú rôzne protokoly a schémy. Z hľadiska bezpečnosti nás najviac zaujímajú:
- Mechanizmus, pomocou ktorého Helm CLI oslovuje chart repo: aký protokol, či existuje autentifikácia a čo s tým môžeme urobiť.
- Protokol, ktorým Helm CLI, pomocou kubectl, komunikuje s Tillerom. Je to RPC server, nainštalovaný vo vnútri klastru.
- Sám Tiller je dostupný pre mikroservisy, ktoré sa nachádzajú v klastru, a interaguje s Kube-apiserver.
Prejdeme všetky tieto smery postupne.
RBAC
Je bezpredmetné hovoriť o akejkoľvek bezpečnosti Helm alebo inej služby vo vnútri klastru, ak nie je zapnutý RBAC.
Zdá sa, že to nie je najnovšia odporúčanie, ale som si istý, že mnohí stále nezapli RBAC ani v produkcii, pretože je to veľa starostí a treba veľa nastaviť. Napriek tomu vyzývam na to, aby ste tak urobili.
— právny web pre RBAC. Obsahuje množstvo zaujímavých materiálov, ktoré pomôžu nastaviť RBAC, ukážu, prečo je dobrý a ako s ním žiť v produkcii.
Skúsim vysvetliť, ako funguje Tiller a RBAC. Tiller funguje vo vnútri klastera pod nejakým servisným účtom. Spravidla, ak nie je nastavené RBAC, bude to superužívateľ. V základnej konfigurácii bude Tiller administrátorom. Preto sa často hovorí, že Tiller je SSH tunel do vášho klastera. V skutočnosti je to pravda, takže môžete použiť samostatný špecializovaný servisný účet namiesto Predvoleného servisného účtu na schéme vyššie.
Keď inicializujete Helm, prvýkrát ho inštalujete na server, môžete zadať servisný účet pomocou --service-account. To umožní používať užívateľa s minimálnym potrebným súborom práv. Pravda, budete musieť vytvoriť takú "girlandu": Role a RoleBinding.
Bohužiaľ, Helm to za vás neurobí. Vy alebo váš správca Kubernetes klastera musíte vopred pripraviť súbor Role, RoleBinding pre servisný účet, aby ste ho mohli odovzdať Helmu.
Objavuje sa otázka — aký je rozdiel medzi Role a ClusterRole? Rozdiel spočíva v tom, že ClusterRole sa uplatňuje pre všetky namespaces, na rozdiel od obyčajných Role a RoleBinding, ktoré fungujú iba pre špecializovaný namespace. Môžete nastaviť politiky pre celý klaster a všetky namespaces, ako aj personalizovane pre každý namespace osobitne.
Stojí za zmienku, že RBAC umožňuje vyriešiť ešte jeden veľký problém. Mnohí si sťažujú, že Helm, bohužiaľ, nie je multitenancy (nepodporuje viacnájomnúst). Ak viacero tímov konzumuje klaster a používa Helm, nie je možné v zásade nastaviť politiky a ohraničiť ich prístup v rámci tohto klastera, pretože existuje nejaký servisný účet, pod ktorým funguje Helm, a on vytvorí pod ním všetky zdroje v klasteri, čo je občas veľmi nepríjemné. To je pravda — ako samotný binárny súbor, ako proces, Helm Tiller nemá pojem o multitenancy.
Avšak existuje skvelý spôsob, ktorý umožňuje spustiť Tiller v klasteri viackrát. S tým nie sú žiadne problémy, Tiller možno spustiť v každom namespace. Týmto spôsobom môžete využiť RBAC, Kubeconfig ako kontext a obmedziť prístup k špeciálnemu Helmu.
Bude to vyzerať nasledovne.
Napríklad existujú dva Kubeconfig s kontextom pre rôzne tímy (dve namespaces): X Team pre tím vývojárov a cluster admina. Cluster admina má svoj široký Tiller, ktorý sa nachádza v namespace Kube-system, pričom má pokročilý service-account. A samostatný namespace pre tím vývojárov, ktorí môžu nasadzovať svoje služby do špeciálneho namespace.
Toto je efektívny prístup, Tiller nie je taký náročný, aby to mohlo výrazne ovplyvniť váš rozpočet. Je to jedno z rýchlych riešení.
Neváhajte samostatne nastaviť Tiller a poskytnúť Kubeconfig s kontextom pre tím, pre konkrétneho vývojára alebo pre prostredie: Dev, Staging, Production (je nepravdepodobné, že všetko bude na jednom clustri, avšak je to možné).
Pokračujúc v našom príbehu, prepneme sa z RBAC a porozprávame sa o ConfigMaps.
ConfigMaps
Helm používa ConfigMaps ako úložisko údajov. Keď sme hovorili o architektúre, nikde tam neexistovala databáza, v ktorej by boli uložené informácie o relezoch, konfiguráciách, rollbacks atď. Na to slúži ConfigMaps.
Hlavný problém s ConfigMaps je známy — nie sú bezpečné v zásade, v nich nie je možné uchovávať sensitive-údaje. Hovoríme o všetkom, čo by nemalo uniknúť za službu, napríklad heslá. Najnativnejším spôsobom pre Helm teraz je prechod od používania ConfigMaps k tajomstvám.
Robí sa to veľmi jednoducho. Predefinujete nastavenie Tiller a určíte, že úložiskom budú tajomstvá. Potom pri každom nasadení dostanete nie ConfigMap, ale tajomstvo.
Môžete namietať, že samotné tajomstvá sú zvláštna koncepcia a nie sú veľmi bezpečné. Avšak, je treba si uvedomiť, že týmto sa zaoberajú samotní vývojári Kubernetes. Od verzie 1.10, t.j. už dosť dávno, je možnosť, aspoň v verejných cloudových službách, pripojiť správne úložisko na uchovávanie tajomstiev. V súčasnosti tím pracuje na ešte lepšom sprístupnení tajomstiev, jednotlivým podom alebo iným entitám.
Úložisko Helm je lepšie preložiť na tajomstvá, a tie následne zabezpečiť centralizovane.
Samozrejme, zostane limit na uchovávanie údajov vo veľkosti 1 MB. Helm používa etcd ako distribuované úložisko pre ConfigMaps. Považujú to za vhodný chunk dát pre replikácie a podobne. O tejto téme sa vedie zaujímavá diskusia na Reddite, odporúčam nájsť si tento zábavný článok na víkend alebo si prečítať zhrnutie. .
Chart Repos
Čarty sú najviac sociálne zraniteľné a môžu sa stať zdrojom "Man in the middle", obzvlášť ak používate štandardné riešenie. Ide najmä o repozitáre, ktoré sú vystavené cez HTTP.
Rozhodne je potrebné vystaviť Helm Repo cez HTTPS – to je najlepší variant a nie je to drahé.
Venujte pozornosť mechanizmu podpisov čartov. Technológia je neuveriteľne jednoduchá. Je to to isté, čo používate na GitHub-e, bežná PGP mašinéria s verejnými a súkromnými kľúčmi. Nastavte si to a budete si istí, že máte potrebné kľúče a podpisujete všetko, čo je skutočne váš chart.
Okrem toho, Helm klient podporuje TLS (nie v zmysle HTTP zo strany servera, ale vzájomný TLS). Môžete použiť serverové a klientské kľúče na komunikáciu. Poviem úprimne, ja tento mechanizmus nepoužívam kvôli neochote voči vzájomným certifikátom. V podstate, – hlavný nástroj na vystavovanie Helm Repos pre Helm 2 – podporuje aj základné autentifikácie. Môžete použiť základnú autentifikáciu, ak je to pohodlnejšie a pokojnejšie.
Existuje aj plugin , ktorý umožňuje umiestňovať Chart Repos do Google Cloud Storage. Je to veľmi pohodlné, skvele funguje a je dostatočne bezpečné, pretože sa realizujú všetky popísané mechanizmy.
Ak zapnete HTTPS alebo TLS, použijete mTLS, zapnete základnú autentifikáciu na zníženie rizík, získate bezpečný komunikačný kanál medzi Helm CLI a Chart Repo.
gRPC API
Ďalší krok je veľmi zodpovedný – zabezpečiť Tiller, ktorý je v klastre a na jednej strane je serverom, na druhej strane sa sám obracia na iné komponenty a snaží sa predstaviť ako niekto iný.
Ako som už povedal, Tiller je služba, ktorá vystavuje gRPC, Helm klient sa ku nemu dostáva cez gRPC. Predvolene je samozrejme TLS vypnuté. Prečo je to takto nastavené – otázka na diskusiu, myslím, že ide o zjednodušenie nastavenia na začiatku.
Pre produkciu a dokonca aj pre staging odporúčam zapnúť TLS na gRPC.
Podľa môjho názoru, na rozdiel od mTLS pre chart, je tu toto vhodné a veľmi jednoduché — vytvoríte PQI infraštruktúru, vytvoríte certifikát, spustíte Tiller a odovzdáte certifikát počas inicializácie. Potom môžete vykonávať všetky Helm príkazy s generovaným certifikátom a súkromným kľúčom.
Týmto sa ochránite pred všetkými požiadavkami na Tiller zvonka klastrom.
Takže sme zabezpečili pripojovací kanál k Tilleru, už sme prediskutovali RBAC a nastavili práva Kubernetes apiserver, zmenšili doménu, s ktorou môže interagovať.
Zabezpečený Helm
Pozrime sa na finálnu schému. Toto je tá istá architektúra s tými istými šípkami.
Všetky pripojenia teraz pokojne môžeme znázorniť zelenou farbou:
- pre Chart Repo používame TLS alebo mTLS a základnú autentifikáciu;
- mTLS pre Tiller, a je vystavený ako gRPC služba s TLS, používame certifikáty;
- v klastre sa používa špeciálny servisný účet s rolou a RoleBindingom.
Výrazne sme zabezpečili klaster, ale niekto múdry povedal:
„Absolútne bezpečné riešenie môže byť len jedno — vypnutý počítač, ktorý sa nachádza v betónovej krabici a strážia ho vojaci“.
Existujú rôzne spôsoby manipulácie s dátami a nachádzania nových vektorov útokov. Som si však istý, že tieto odporúčania umožnia realizovať základný priemyselný štandard bezpečnosti.
Bonus
Táto časť nesúvisí priamo s bezpečnosťou, ale bude tiež užitočná. Ukážem niektoré zaujímavé veci, o ktorých málo ľudí vie. Napríklad, ako hľadať charty — oficiálne a neoficiálne.
V repozitári teraz je asi 300 chartov a dva prúdy: stable a incubator. Ten, kto prispieva, dokonale vie, ako ťažké je dostať sa z incubator do stable, a ako ľahké je z stable vypadnúť. Avšak, nie je to najlepší nástroj na hľadanie chartov pre Prometheus a všetko, čo sa vám páči, z jedného jednoduchého dôvodu — nie je to portál, kde je pohodlné hľadať balíky.
Ale existuje služba , s pomocou ktorej je hľadanie chartov oveľa pohodlnejšie. Najdôležitejšie je, že tam je oveľa viac externých repozitárov a je dostupných takmer 800 chartov. Navyše, môžete pripojiť svoj repozitár, ak z nejakého dôvodu nechcete odosielať svoje charty do stable.
Vyskúšajte hub.helm.sh a poďme ho spolu rozvíjať. Táto služba je pod Helm projektom a môžete prispieť aj do jeho UI, ak ste frontendový vývojár a chcete jednoducho vylepšiť jeho vzhľad.
Ešte chcem upriamiť vašu pozornosť na Integráciu Open Service Broker API. Znie to ťažkopádne a nejasne, ale rieši úlohy, s ktorými sa všetci stretávajú. Vysvetlím na jednoduchom príklade.
Existuje Kubernetes klaster, v ktorom chceme spustiť klasickú aplikáciu — WordPress. Zvyčajne je potrebná databáza na plnú funkčnosť. Existuje mnoho rôznych riešení, napríklad, môžeme spustiť svoj stateful service. To nie je veľmi pohodlné, ale mnohí to tak robia.
Iní, napríklad my v Chainstack, používajú spravované databázy, ako MySQL alebo PostgreSQL, pre servery. Preto máme DB niekde v oblaku.
Ale vzniká problém: musíme prepojiť náš service s databázou, vytvoriť flavor databázy, odovzdať credential a nejako nimi spravovať. To všetko sa zvyčajne robí ručne systémovým administrátorom alebo vývojárom. A nie je s tým žiadny problém, keď je málo aplikácií. Keď ich je veľa, potrebujete kombajn. Taký kombajn existuje — to je Service Broker. Umožňuje používať špeciálny plugin ku klasteru verejného oblakového poskytovateľa a objednávať zdroje od poskytovateľa cez Broker, akoby to bolo API. Na to môžete použiť natívne prostriedky Kubernetes.
Je to veľmi jednoduché. Môžete požiadať napríklad o Managed MySQL v Azure s základným tier (to si môžete nastaviť). S použitím API Azure bude databáza vytvorená a pripravená na používanie. Nemusíte do toho zasahovať, o to sa stará plugin. Napríklad, OSBA (plugin Azure) vráti credential do service, odovzdá to Helm. Môžete používať WordPress s cloudovým MySQL, úplne sa nezamýšľať o spravovaných databázach a netrápiť sa o stateful services vo vnútri.
Môžeme povedať, že Helm je lepidlo, ktoré z jednej strany umožňuje nasadzovať služby, a z druhej strany — využívať zdroje oblakových poskytovateľov.
Môžete napísať svoj plugin a využiť celú túto históriu on-premise. Potom budete mať len svoj plugin ku korporátnemu Cloud poskytovateľovi. Odporúčam vyskúšať taký prístup, najmä ak máte veľký rozsah a chcete rýchlo nasadiť dev, staging alebo celú infraštruktúru pod funkciu. To uľahčí život vašim operations alebo DevOps.
Ešte jeden nález, ktorý som už spomínal — to je plugin helm-gcs, ktorý umožňuje používať Google-buckets (objektové úložisko) na ukladanie Helm chartov.
Na začiatok potrebujete iba štyri príkazy:
- nainštalovať plugin;
- iniciovať ho;
- nastaviť cestu k bucketu, ktorý sa nachádza v gcp;
- publikovať grafy štandardným spôsobom.
Krása spočíva v tom, že sa bude používať natívny spôsob gcp na autorizáciu. Môžete použiť služobný účet, účet vývojára – čokoľvek. Je to veľmi pohodlné a nič to nestojí na prevádzku. Ak, ako ja, propagujete filozofiu bez ops, bude to veľmi pohodlné, najmä pre malé tímy.
Alternatívy
Helm nie je jediné riešenie na správu služieb. K nemu je veľa otázok, pravdepodobne preto sa tak rýchlo objavila tretia verzia. Samozrejme, existujú alternatívy.
Môžu to byť ako špecializované riešenia, napríklad Ksonnet alebo Metaparticle. Môžete použiť svoje klasické prostriedky správy infraštruktúry (Ansible, Terraform, Chef a pod.) na rovnaké účely, o ktorých som hovoril.
Nakoniec existuje riešenie , ktorého popularita rastie.
Operator Framework je hlavná alternatíva k Helmu, na ktorú by ste sa mali zamerať.
Je to viac natívne pre CNCF a Kubernetes, ale vstupný prah je oveľa vyšší, je potrebné viac programovať a menej opisovať manifiesty.
Existujú rôzne doplnky, ako Draft, Scaffold. Tie veľmi uľahčujú život, napríklad vývojárom zjednodušujú cyklus odosielania a spúšťania Helmu na nasadenie testovacieho prostredia. Nazval by som ich rozšíreniami možností.
Tu je názorný graf o tom, kde sa čo nachádza.
Na osi x je úroveň vašej osobnej kontroly nad udalosťami, na osi y – úroveň natívnosti Kubernetes. Helm verzia 2 sa nachádza niekde uprostred. V verzii 3 nie je obrovský skok, ale zlepšil sa aj kontrola aj úroveň natívnosti. Riešenia úrovne Ksonnet sú predsa len slabšie ako Helm 2. Avšak stojí za to sa na ne pozrieť, aby ste vedeli, čo všetko existuje vo svete. Samozrejme, váš konfiguračný manažér bude vo vašej kontrole, ale nie je úplne natívny pre Kubernetes.
Operator Framework je úplne natívny pre Kubernetes a umožňuje elegantnejšie a precíznejšie spravovať (ale pamätajme na úroveň vstupu). Skôr to vhodné pre špecializovanú aplikáciu a jej manažovanie, než pre hromadného kombajna na balenie veľkého množstva aplikácií pomocou Helmu.
Rozšírenia len troška zlepšujú kontrolu, dopĺňajú workflow alebo šetria kroky v CI/CD pipeline.
Budúcnosť Helmu
Dobrá správa je, že prichádza Helm 3. Už bol vydaný alpha-release verzie Helm 3.0.0-alpha.2, môžete si ho vyskúšať. Je dosť stabilný, ale funkčnosť je zatiaľ obmedzená.
Prečo je potrebný Helm 3? Predovšetkým ide o zrušenie Tilleru, ako komponentu. To je, ako už rozumiete, obrovský krok dopredu, pretože z pohľadu bezpečnosti architektúry sa všetko zjednodušuje.
Keď sa vytváral Helm 2, a to bolo v časoch Kubernetes 1.8 alebo dokonca skôr, mnohé koncepty boli nezrelé. Napríklad koncept CRD sa teraz aktívne implementuje a Helm bude používať CRD, aby uchovával štruktúry. Bude možné používať iba klienta a nemusíte mať serverovú časť. Tým pádom, využívať natívne príkazy Kubernetes na prácu so štruktúrami a zdrojmi. To je obrovský krok dopredu.
Objaví sa podpora natívnych OCI repozitárov (Open Container Initiative). Toto je obrovská iniciatíva, a pre Helm je zaujímavá predovšetkým pre umiestňovanie vlastných chartov. Až do takej miery, že napríklad Docker Hub podporuje mnoho štandardov OCI. Nechcem predpovedať, ale je možné, že klasickí poskytovatelia Docker-repozitárov začnú ponúkať možnosť umiestnenia vašich Helm chartov.
Sporná pre mňa je podpora Lua, ako templating engine na písanie skriptov. Nie som veľký fanúšik Luu, ale táto možnosť bude úplne voliteľná. Trikrát som to overil — použitie Luu nebude povinné. Preto, kto chce môcť použiť Lua, ten, komu sa páči Go — pridajte sa k nášmu veľkému táboru a používajte go-tmpl na to.
Konečne to, čo mi určite chýbalo — zavedenie schémy a validácia dátových typov. Už nebudú problémy s int alebo string, nebude potrebné obklopovať nulu dvojitými úvodzovkami. Objaví sa JSON schema, ktorá to umožní jasne popísať pre values.
Bude veľmi silno prepracovaná event-driven model.Už je konceptuálne opísaná. Pozrite sa do vetvy Helm 3 a uvidíte, koľko bolo pridaných udalostí a hookov a iného, čo výrazne zjednoduší a na druhej strane pridá kontrolu nad procesmi nasadenia a ich reakciami.
Helm 3 bude jednoduchší, bezpečnejší a zaujímavejší nie preto, že nemáme radi Helm 2, ale preto, že Kubernetes sa stáva pokrokovejším. Tým pádom, Helm môže využiť schopnosti Kubernetes a vytvárať na ňom skvelé manažéry pre Kubernetes.
Ešte jedna dobrá správa je, že na Alexandr Chajov rozpráva, Pripomíname, že konferencia o integrácii procesov vývoja, testovania a prevádzky sa uskutoční v Moskve 30. septembra a 1. októbra. Do 20. augusta ešte môžete a podeliť sa o svoje skúsenosti s riešením úloh prístupu DevOps.
Sledujte najnovšie správy a checkpointy konferencie v a .
Zdroj: habr.com
