Podstatu príbehu o najpopulárnejšom správcovi balíkov pre Kubernetes možno znázorniť pomocou emotikonu:
- krabica je Helm (čo je najbližšie k najnovšiemu vydaniu Emoji);
- zámok - bezpečnosť;
- malý človiečik je riešením problému.
V skutočnosti bude všetko trochu komplikovanejšie a príbeh je plný technických detailov Ako zaistiť bezpečnosť Helmu.
- Stručne, čo je Helm pre prípad, že by ste to nevedeli alebo zabudli. Aké problémy rieši a kde sa v ekosystéme nachádza.
- Pozrime sa na architektúru Helm. Žiadna konverzácia o bezpečnosti a o tom, ako urobiť nástroj alebo riešenie bezpečnejším, sa nezaobíde bez pochopenia architektúry komponentu.
- Poďme diskutovať o komponentoch Helm.
- Najpálčivejšou otázkou je budúcnosť – nová verzia Helm 3.
Všetko v tomto článku sa vzťahuje na Helm 2. Táto verzia je momentálne vo výrobe a s najväčšou pravdepodobnosťou je to tá, ktorú práve používate, a je to verzia, ktorá obsahuje bezpečnostné riziká.
O rečníkovi: Alexander Khayorov () sa vyvíja už 10 rokov a pomáha zlepšovať obsah a vstúpil do výboru . Teraz pracuje v Chainstacku ako vedúci vývoja – ide o hybrid medzi manažérom vývoja a osobou, ktorá je zodpovedná za dodávanie finálnych verzií. To znamená, že sa nachádza na bojisku, kde sa deje všetko od vytvorenia produktu až po jeho fungovanie.
Chainstack je malý, aktívne rastúci startup, ktorého poslaním je umožniť klientom zabudnúť na infraštruktúru a zložitosť prevádzky decentralizovaných aplikácií, vývojový tím sídli v Singapure. Nežiadajte Chainstack, aby predal alebo kúpil kryptomenu, ale ponúknite sa, že sa porozprávate o podnikových blockchain frameworkoch, a oni vám s radosťou odpovedia.
kormidlo
Toto je správca balíkov (grafov) pre Kubernetes. Najintuitívnejší a najuniverzálnejší spôsob, ako priniesť aplikácie do klastra Kubernetes.
Hovoríme samozrejme o štrukturálnejšom a priemyselnejšom prístupe, ako je vytváranie vlastných YAML manifestov a písanie malých utilít.
Helma je to najlepšie, čo je momentálne dostupné a obľúbené.
Prečo Helm? Predovšetkým preto, že je podporovaný CNCF. Cloud Native je veľká organizácia a je materskou spoločnosťou projektov Kubernetes, etcd, Fluentd a ďalších.
Ďalším dôležitým faktom je, že Helm je veľmi populárny projekt. Keď som v januári 2019 začal hovoriť o tom, ako zabezpečiť Helm, projekt mal na GitHub tisíc hviezdičiek. V máji ich bolo 12 tisíc.
Mnoho ľudí sa zaujíma o Helm, takže aj keď ho ešte nepoužívate, budete mať prospech z toho, že viete o jeho bezpečnosti. Bezpečnosť je dôležitá.
Hlavný tím Helm je podporovaný Microsoft Azure a ide teda o pomerne stabilný projekt, na rozdiel od mnohých iných. Vydanie Helm 3 Alpha 2 v polovici júla naznačuje, že na projekte pracuje pomerne veľa ľudí, ktorí majú chuť a energiu Helm vyvíjať a zlepšovať.
Helm rieši niekoľko koreňových problémov správy aplikácií v Kubernetes.
- Balenie aplikácie. Dokonca aj aplikácia ako „Hello, World“ na WordPress už pozostáva z niekoľkých služieb a chcete ich zbaliť.
- Riadenie zložitosti, ktorá je spojená so správou týchto aplikácií.
- Životný cyklus, ktorý nekončí po inštalácii alebo nasadení aplikácie. Naďalej žije, je potrebné ho aktualizovať a Helm s tým pomáha a snaží sa na to priniesť správne opatrenia a politiky.
Vrecovanie je usporiadaný prehľadne: existujú metadáta plne v súlade s prácou bežného správcu balíkov pre Linux, Windows alebo MacOS. Teda úložisko, závislosti na rôznych balíkoch, meta informácie pre aplikácie, nastavenia, konfiguračné funkcie, indexovanie informácií atď. Helm vám toto všetko umožňuje získať a použiť pre aplikácie.
Manažment zložitosti. Ak máte veľa aplikácií rovnakého typu, potom je potrebná parametrizácia. Šablóny pochádzajú z toho, ale aby ste nemuseli vymýšľať svoj vlastný spôsob vytvárania šablón, môžete použiť to, čo Helm ponúka hneď po vybalení.
Správa životného cyklu aplikácie - toto je podľa mňa najzaujímavejšia a nevyriešená otázka. Preto som v ten deň prišiel do Helmu. Potrebovali sme dohliadať na životný cyklus aplikácie a chceli sme posunúť naše CI/CD a aplikačné cykly do tejto paradigmy.
Helm vám umožňuje:
- riadiť nasadenia, zavádza koncepciu konfigurácie a revízie;
- úspešne vykonať rollback;
- používať háčiky na rôzne udalosti;
- pridať ďalšie kontroly aplikácií a reagovať na ich výsledky.
Naviac Helma má „batérie“ - obrovské množstvo chutných vecí, ktoré môžu byť zahrnuté vo forme pluginov, ktoré vám zjednodušia život. Pluginy môžu byť napísané nezávisle, sú dosť izolované a nevyžadujú harmonickú architektúru. Ak chcete niečo implementovať, odporúčam to urobiť ako plugin a potom to prípadne zaradiť do upstreamu.
Helma je založená na troch hlavných konceptoch:
- Graf Repo — popis a pole možných parametrov pre váš manifest.
- Config —to znamená hodnoty, ktoré sa použijú (text, číselné hodnoty atď.).
- Verzia zhromažďuje dve horné zložky a spolu sa premenia na uvoľnenie. Vydania môžu byť verzované, čím sa dosiahne organizovaný životný cyklus: malý v čase inštalácie a veľký v čase upgradu, downgradu alebo rollbacku.
Architektúra kormidla
Diagram koncepčne zobrazuje architektúru Helmu na vysokej úrovni.
Pripomínam, že Helm je niečo, čo súvisí s Kubernetes. Preto sa bez Kubernetes klastra (obdĺžnika) nezaobídeme. Komponent kube-apiserver sa nachádza na hlavnom serveri. Bez Helma máme Kubeconfig. Helm prináša jednu malú binárku, ak sa to tak dá nazvať, utilitu Helm CLI, ktorá sa inštaluje na počítač, notebook, mainframe – na čokoľvek.
To však nestačí. Helm má serverový komponent s názvom Tiller. Zastupuje záujmy Helmu v rámci klastra, je to aplikácia v rámci klastra Kubernetes, ako každá iná.
Ďalšou súčasťou Chart Repo je úložisko s grafmi. Existuje oficiálny repozitár a môže existovať súkromný repozitár spoločnosti alebo projektu.
Interakcie
Pozrime sa na interakciu komponentov architektúry, keď chceme nainštalovať aplikáciu pomocou Helm.
- hovoríme
Helm install, vstúpte do úložiska (Chart Repo) a získajte Helmovu schému.
- Nástroj Helm (Helm CLI) spolupracuje s Kubeconfigom, aby zistil, ktorý klaster kontaktovať.
- Po obdržaní týchto informácií nástroj odkazuje na Tiller, ktorý sa nachádza v našom klastri, ako na aplikáciu.
- Tiller volá Kube-apiserver, aby vykonal akcie v Kubernetes, vytvoril nejaké objekty (služby, moduly, repliky, tajomstvá atď.).
Ďalej diagram skomplikujeme, aby sme videli vektor útoku, ktorému môže byť vystavená celá architektúra Helm ako celok. A potom sa ju pokúsime ochrániť.
Vektor útoku
Prvá potenciálna slabá stránka je privilegované API-užívateľ. V rámci schémy ide o hackera, ktorý získal administrátorský prístup do Helm CLI.
Neprivilegovaný používateľ rozhrania API môže tiež predstavovať nebezpečenstvo, ak je niekde v blízkosti. Takýto používateľ bude mať iný kontext, môže byť napríklad zafixovaný v jednom mennom priestore klastra v nastaveniach Kubeconfig.
Najzaujímavejším vektorom útoku môže byť proces, ktorý sa nachádza v klastri niekde blízko Tillera a má k nemu prístup. Môže to byť webový server alebo mikroslužba, ktorá vidí sieťové prostredie klastra.
Exotický, ale čoraz obľúbenejší variant útoku zahŕňa Chart Repo. Tabuľka vytvorená bezohľadným autorom môže obsahovať nebezpečné zdroje a vy ju dokončíte tak, že ju prevezmete. Alebo môže nahradiť graf, ktorý si stiahnete z oficiálneho úložiska a napríklad vytvoríte zdroj vo forme politík a eskalujete jeho prístup.
Pokúsme sa odraziť útoky zo všetkých týchto štyroch strán a zistiť, kde sú problémy v architektúre Helmu a kde možno žiadne nie sú.
Zväčšíme schému, pridáme ďalšie prvky, ale ponechajme všetky základné komponenty.
Helm CLI komunikuje s Chart Repo, interaguje s Kubeconfigom a práca sa prenáša do klastra na komponent Tiller.
Tiller je reprezentovaný dvoma objektmi:
- Tiller-deploy svc, ktorý odhaľuje určitú službu;
- Tiller-deploy pod (v diagrame v jednej kópii v jednej replike), na ktorom beží celá záťaž, ktorá pristupuje ku klastru.
Na interakciu sa používajú rôzne protokoly a schémy. Z bezpečnostného hľadiska nás najviac zaujíma:
- Mechanizmus, ktorým Helm CLI pristupuje k repo grafu: aký protokol, existuje autentifikácia a čo sa s tým dá robiť.
- Protokol, ktorým Helm CLI pomocou kubectl komunikuje s Tillerom. Toto je server RPC nainštalovaný vo vnútri klastra.
- Samotný Tiller je prístupný mikroslužbám, ktoré sa nachádzajú v klastri a interaguje s Kube-apiserverom.
Poďme diskutovať o všetkých týchto oblastiach v poradí.
RBAC
Nemá zmysel hovoriť o akomkoľvek zabezpečení pre Helm alebo akúkoľvek inú službu v rámci klastra, pokiaľ nie je povolené RBAC.
Zdá sa, že to nie je najnovšie odporúčanie, ale som si istý, že veľa ľudí ešte stále nepovolilo RBAC ani vo výrobe, pretože je to veľa zmätku a veľa vecí je potrebné nakonfigurovať. Odporúčam vám to však urobiť.
— právnik webových stránok pre RBAC. Obsahuje obrovské množstvo zaujímavých materiálov, ktoré vám pomôžu nastaviť RBAC, ukážu, prečo je dobrý a ako sa s ním v podstate vo výrobe dá žiť.
Pokúsim sa vysvetliť, ako fungujú Tiller a RBAC. Tiller pracuje vo vnútri klastra pod určitým účtom služby. Ak RBAC nie je nakonfigurovaný, zvyčajne to bude superužívateľ. V základnej konfigurácii bude Tiller správcom. To je dôvod, prečo sa často hovorí, že Tiller je tunel SSH do vášho klastra. V skutočnosti je to pravda, takže namiesto predvoleného účtu služby v diagrame vyššie môžete použiť samostatný vyhradený účet služby.
Keď inicializujete Helm a nainštalujete ho na server prvýkrát, môžete nastaviť účet služby pomocou --service-account. To vám umožní používať používateľa s minimálnou požadovanou sadou práv. Je pravda, že budete musieť vytvoriť taký „veniec“: Role a RoleBinding.
Bohužiaľ, Helm to za vás neurobí. Aby ste mohli prejsť Helm, musíte vy alebo váš správca klastra Kubernetes vopred pripraviť sadu rolí a väzieb rolí pre účet služby.
Vynára sa otázka – aký je rozdiel medzi Role a ClusterRole? Rozdiel je v tom, že ClusterRole funguje pre všetky menné priestory, na rozdiel od bežných Roles a RoleBindings, ktoré fungujú len pre špecializovaný menný priestor. Môžete nakonfigurovať politiky pre celý klaster a všetky priestory názvov alebo ich môžete prispôsobiť pre každý priestor názvov jednotlivo.
Stojí za zmienku, že RBAC rieši ďalší veľký problém. Mnoho ľudí sa sťažuje, že Helm, žiaľ, nie je multitenancy (nepodporuje multitenancy). Ak niekoľko tímov konzumuje klaster a používa Helm, je v podstate nemožné nastaviť politiky a obmedziť ich prístup v rámci tohto klastra, pretože existuje určitý servisný účet, pod ktorým Helm beží a z neho vytvára všetky prostriedky v klastri. , čo je niekedy veľmi nepohodlné. To je pravda - ako samotný binárny súbor, ako proces, Helm Tiller nemá žiadnu koncepciu multiprenájmu.
Existuje však skvelý spôsob, ktorý vám umožní spustiť Tiller viackrát v klastri. S tým nie je problém, Tiller je možné spustiť v každom mennom priestore. Môžete teda použiť RBAC, Kubeconfig ako kontext a obmedziť prístup k špeciálnemu Helmu.
Bude to vyzerať takto.
Napríklad existujú dva Kubeconfigy s kontextom pre rôzne tímy (dva menné priestory): X Team pre vývojový tím a klaster správcov. Administrátorský klaster má svoj vlastný široký Tiller, ktorý sa nachádza v mennom priestore systému Kube, čo je zodpovedajúci pokročilý servisný účet. A samostatný menný priestor pre vývojový tím, budú môcť nasadiť svoje služby do špeciálneho menného priestoru.
Toto je funkčný prístup, Tiller nie je taký hladný po sile, aby to výrazne ovplyvnilo váš rozpočet. Toto je jedno z rýchlych riešení.
Neváhajte nakonfigurovať Tiller samostatne a poskytnúť Kubeconfig kontext pre tím, pre konkrétneho vývojára alebo pre prostredie: Dev, Staging, Production (je pochybné, že všetko bude na rovnakom klastri, dá sa to však urobiť).
Pokračujeme v našom príbehu, prepnime z RBAC a porozprávajme sa o ConfigMaps.
ConfigMaps
Helm používa ConfigMaps ako úložisko údajov. Keď sme hovorili o architektúre, nikde neexistovala databáza, ktorá by uchovávala informácie o vydaniach, konfiguráciách, rollbackoch atď. Na to slúži ConfigMaps.
Hlavný problém s ConfigMaps je známy – v princípe nie sú bezpečné; nie je možné uchovávať citlivé údaje. Hovoríme o všetkom, čo by nemalo ísť nad rámec služby, napríklad o heslách. Najprirodzenejším spôsobom pre Helm je v súčasnosti prejsť z používania ConfigMaps na tajomstvá.
Toto sa robí veľmi jednoducho. Prepíšte nastavenie Tiller a zadajte, že úložisko bude tajné. Potom pre každé nasadenie nedostanete ConfigMap, ale tajomstvo.
Môžete namietať, že samotné tajomstvá sú zvláštny pojem a nie sú príliš bezpečné. Je však potrebné pochopiť, že to robia samotní vývojári Kubernetes. Počnúc verziou 1.10, t.j. Už pomerne dlho je možné, aspoň vo verejných cloudoch, pripojiť správne úložisko na ukladanie tajomstiev. Tím teraz pracuje na spôsoboch, ako lepšie distribuovať prístup k tajomstvám, jednotlivým modulom alebo iným entitám.
Je lepšie preniesť Storage Helm na tajomstvá a tie sú zase centrálne zabezpečené.
Samozrejme, že zostane limit ukladania dát 1 MB. Helm tu používa etcd ako distribuované úložisko pre ConfigMaps. A tam usúdili, že toto je vhodný dátový blok na replikáciu atď. Na Reddite je o tom zaujímavá diskusia, odporúčam nájsť si toto vtipné čítanie na víkend alebo si prečítať úryvok .
Graf Repos
Grafy sú sociálne najzraniteľnejšie a môžu sa stať zdrojom „Muž uprostred“, najmä ak používate akciové riešenie. V prvom rade hovoríme o úložiskách, ktoré sú vystavené cez HTTP.
Určite musíte vystaviť Helm Repo cez HTTPS - toto je najlepšia možnosť a je lacná.
Venujte pozornosť mechanizmus podpisu grafu. Technológia je jednoduchá ako peklo. Je to to isté, čo používate na GitHub, bežnom počítači PGP s verejnými a súkromnými kľúčmi. Nastavte a uistite sa, že máte potrebné kľúče a všetko podpíšte, že toto je skutočne váš graf.
Okrem toho, Klient Helm podporuje TLS (nie v zmysle HTTP na strane servera, ale vzájomného TLS). Na komunikáciu môžete použiť kľúče servera a klienta. Aby som bol úprimný, nepoužívam takýto mechanizmus, pretože nemám rád vzájomné certifikáty. v podstate - hlavný nástroj na nastavenie Helm Repo pre Helm 2 - podporuje aj základné overenie. Ak je to pohodlnejšie a tichšie, môžete použiť základné overenie.
Existuje aj plugin , ktorá vám umožňuje hostiť úložiská grafov v službe Google Cloud Storage. Je to celkom pohodlné, funguje to skvele a je to celkom bezpečné, pretože všetky opísané mechanizmy sú recyklované.
Ak povolíte HTTPS alebo TLS, použijete mTLS a povolíte základné overenie na ďalšie zníženie rizík, získate bezpečný komunikačný kanál s Helm CLI a Chart Repo.
gRPC API
Ďalší krok je veľmi dôležitý – zabezpečiť Tiller, ktorý sa nachádza v klastri a je na jednej strane serverom, na druhej strane sám pristupuje k ostatným komponentom a snaží sa za niekoho vydávať.
Ako som už povedal, Tiller je služba, ktorá odhaľuje gRPC, klient Helm k nej prichádza cez gRPC. Štandardne je TLS samozrejme vypnuté. Prečo sa to urobilo, je diskutabilná otázka, zdá sa mi, že to zjednodušuje nastavenie na začiatku.
Pre produkciu a rovnomerné staging odporúčam povoliť TLS na gRPC.
Podľa môjho názoru, na rozdiel od mTLS pre grafy, je to tu vhodné a robí sa to veľmi jednoducho - vygenerujte infraštruktúru PQI, vytvorte certifikát, spustite Tiller, preneste certifikát počas inicializácie. Potom môžete vykonať všetky príkazy Helm, pričom sa predstavíte s vygenerovaným certifikátom a súkromným kľúčom.
Týmto spôsobom sa budete chrániť pred všetkými požiadavkami na Tiller zvonku klastra.
Zabezpečili sme teda pripojovací kanál k Tillerovi, už sme diskutovali o RBAC a upravili práva apiserveru Kubernetes, čím sme zredukovali doménu, s ktorou môže interagovať.
Chránená prilba
Pozrime sa na konečný diagram. Je to rovnaká architektúra s rovnakými šípkami.
Všetky pripojenia je teraz možné bezpečne nakresliť zelenou farbou:
- pre Chart Repo používame TLS alebo mTLS a základné overenie;
- mTLS pre Tiller a je vystavený ako služba gRPC s TLS, používame certifikáty;
- klaster používa špeciálne konto služby s Role a RoleBinding.
Výrazne sme zabezpečili klaster, ale niekto inteligentný povedal:
"Existuje len jedno absolútne bezpečné riešenie - vypnutý počítač, ktorý je umiestnený v betónovej krabici a strážia ho vojaci."
Existujú rôzne spôsoby, ako manipulovať s údajmi a nájsť nové vektory útoku. Som však presvedčený, že tieto odporúčania dosiahnu základný priemyselný štandard pre bezpečnosť.
Prémie
Táto časť priamo nesúvisí s bezpečnosťou, ale bude tiež užitočná. Ukážem vám niekoľko zaujímavostí, o ktorých vie len málokto. Napríklad ako vyhľadávať grafy – oficiálne a neoficiálne.
V úložisku Teraz existuje asi 300 grafov a dva prúdy: stabilný a inkubátorový. Každý, kto prispieva, veľmi dobre vie, aké ťažké je dostať sa z inkubátora do stajne a aké ľahké je vyletieť zo stajne. Nie je to však najlepší nástroj na vyhľadávanie grafov pre Prometheus a čokoľvek iné, čo sa vám páči, a to z jedného jednoduchého dôvodu – nejde o portál, kde by ste mohli pohodlne vyhľadávať balíčky.
Ale je tu služba , vďaka čomu je vyhľadávanie grafov oveľa pohodlnejšie. Najdôležitejšie je, že je k dispozícii oveľa viac externých úložísk a takmer 800 kúziel. Navyše môžete pripojiť svoje úložisko, ak z nejakého dôvodu nechcete posielať svoje grafy do stajne.
Vyskúšajte hub.helm.sh a poďme ho spoločne rozvíjať. Táto služba je pod projektom Helm a môžete dokonca prispieť k jej používateľskému rozhraniu, ak ste front-end vývojár a chcete len vylepšiť vzhľad.
Chcel by som tiež upozorniť na Otvorená integrácia Service Broker API. Znie to ťažkopádne a nejasne, no rieši to problémy, s ktorými sa stretávajú všetci. Vysvetlím to na jednoduchom príklade.
Existuje klaster Kubernetes, v ktorom chceme spustiť klasickú aplikáciu – WordPress. Vo všeobecnosti je pre plnú funkčnosť potrebná databáza. Existuje mnoho rôznych riešení, napríklad môžete spustiť vlastnú štátnu službu. Nie je to veľmi pohodlné, ale veľa ľudí to robí.
Iní, ako my v Chainstack, používajú pre svoje servery spravované databázy ako MySQL alebo PostgreSQL. Preto sú naše databázy umiestnené niekde v cloude.
Nastáva však problém: potrebujeme prepojiť našu službu s databázou, vytvoriť databázovú príchuť, preniesť poverenie a nejako to spravovať. Toto všetko zvyčajne robí manuálne správca systému alebo vývojár. A nie je problém, keď je málo aplikácií. Keď je ich veľa, potrebujete kombajn. Existuje taký kombajn - to je Service Broker. Umožňuje použiť špeciálny plugin pre verejný cloudový klaster a objednávať zdroje od poskytovateľa cez Broker, ako keby to bolo API. Na tento účel môžete použiť natívne nástroje Kubernetes.
Je to veľmi jednoduché. Môžete sa napríklad dotazovať na Managed MySQL v Azure so základnou vrstvou (dá sa nakonfigurovať). Pomocou Azure API bude databáza vytvorená a pripravená na použitie. Do toho nemusíte zasahovať, je za to zodpovedný plugin. Napríklad OSBA (Azure plugin) vráti poverenie do služby a odovzdá ho Helm. Budete môcť používať WordPress s cloud MySQL, vôbec sa nezaoberať spravovanými databázami a nestarať sa o stavové služby vo vnútri.
Dá sa povedať, že Helm pôsobí ako lepidlo, ktoré na jednej strane umožňuje nasadzovať služby a na druhej strane spotrebováva zdroje cloudových poskytovateľov.
Môžete si napísať svoj vlastný plugin a použiť celý tento príbeh na mieste. Potom budete mať jednoducho svoj vlastný plugin pre firemného poskytovateľa cloudu. Odporúčam vyskúšať tento prístup, najmä ak máte veľký rozsah a chcete rýchlo nasadiť vývoj, staging alebo celú infraštruktúru pre funkciu. To uľahčí život vašim operáciám alebo DevOps.
Ďalší nález, ktorý som už spomínal, je doplnok helm-gcs, ktorý vám umožňuje používať Google-buckety (ukladanie objektov) na ukladanie Helmových máp.
Na to, aby ste ho mohli začať používať, potrebujete iba štyri príkazy:
- nainštalujte doplnok;
- iniciovať to;
- nastavte cestu do vedra, ktorý sa nachádza v gcp;
- publikovať grafy štandardným spôsobom.
Krása je v tom, že na autorizáciu sa použije natívna metóda gcp. Môžete použiť servisný účet, účet vývojára, čokoľvek chcete. Je veľmi pohodlný a jeho prevádzka nestojí nič. Ak ako ja propagujete filozofiu opsless, bude to veľmi výhodné, najmä pre malé tímy.
alternatívy
Helm nie je jediným riešením správy služieb. Je okolo nej veľa otázok, zrejme aj preto sa tak rýchlo objavila tretia verzia. Samozrejme, že existujú alternatívy.
Môžu to byť špecializované riešenia, napríklad Ksonnet alebo Metaparticle. Na rovnaké účely, o ktorých som hovoril, môžete použiť svoje klasické nástroje na správu infraštruktúry (Ansible, Terraform, Chef atď.).
Konečne existuje riešenie , ktorej popularita rastie.
Operator Framework je najvyššou alternatívou Helm, ktorú treba zvážiť.
Je natívnejší pre CNCF a Kubernetes, ale bariéra vstupu je oveľa vyššia, musíte viac programovať a menej popisovať prejavy.
Existujú rôzne doplnky, ako napríklad Draft, Scaffold. Veľmi uľahčujú život, napríklad zjednodušujú cyklus odosielania a spúšťania Helmu pre vývojárov na nasadenie testovacieho prostredia. Nazval by som ich posilňovačmi.
Tu je vizuálna tabuľka, kde sa všetko nachádza.
Na osi x je úroveň vašej osobnej kontroly nad tým, čo sa deje, na osi y je úroveň natívnosti Kubernetes. Verzia prilby 2 spadá niekde uprostred. Vo verzii 3 nie enormne, ale zlepšilo sa ovládanie aj úroveň natívnosti. Riešenia na úrovni Ksonnet sú stále horšie ako Helm 2. Avšak stojí za to si ich pozrieť, aby ste vedeli, čo ešte je na tomto svete. Samozrejme, že váš konfiguračný manažér bude pod vašou kontrolou, ale absolútne nie je pôvodný pre Kubernetes.
Operator Framework je úplne pôvodný pre Kubernetes a umožňuje vám ho spravovať oveľa elegantnejšie a dôkladnejšie (ale nezabudnite na vstupnú úroveň). Je to vhodné skôr pre špecializovanú aplikáciu a vytvorenie manažmentu pre ňu, ako hromadný kombajn na balenie veľkého množstva aplikácií pomocou Helm.
Extendery jednoducho trochu zlepšujú ovládanie, dopĺňajú pracovný tok alebo obmedzujú rohy CI/CD potrubí.
Budúcnosť Helma
Dobrou správou je, že prichádza Helm 3. Alfa verzia Helm 3.0.0-alpha.2 už vyšla, môžete si ju vyskúšať. Je pomerne stabilný, ale funkčnosť je stále obmedzená.
Prečo Helm 3? V prvom rade je to príbeh o zmiznutie Tillera, ako komponent. Ako ste už pochopili, je to obrovský krok vpred, pretože z hľadiska bezpečnosti architektúry je všetko zjednodušené.
Keď bol vytvorený Helm 2, čo bolo približne v čase Kubernetes 1.8 alebo ešte skôr, mnohé z konceptov boli nezrelé. Napríklad koncept CRD sa teraz aktívne implementuje a Helm bude používať CRDna uloženie štruktúr. Bude možné používať iba klienta a neudržiavať serverovú časť. Preto na prácu so štruktúrami a zdrojmi používajte natívne príkazy Kubernetes. Je to obrovský krok vpred.
Objaví sa podpora natívnych repozitárov OCI (Iniciatíva za otvorený kontajner). Ide o obrovskú iniciatívu a Helm sa zaujíma predovšetkým o to, aby zverejnil svoje grafy. Ide o to, že napríklad Docker Hub podporuje mnoho štandardov OCI. Nemyslím si, ale možno vám klasickí poskytovatelia úložísk Docker začnú dávať príležitosť hostiť vaše grafy Helm.
Kontroverzný príbeh pre mňa je Podpora Lua, ako nástroj na vytváranie šablón na písanie skriptov. Nie som veľkým fanúšikom Lua, ale toto by bola úplne voliteľná funkcia. Skontroloval som to 3-krát - používanie Lua nebude potrebné. Preto tí, ktorí chcú mať možnosť používať Lua, tí, ktorí majú radi Go, sa pripájajú k nášmu obrovskému táboru a používajú na to go-tmpl.
Nakoniec, čo mi určite chýbalo vznik schémy a overenie typu údajov. Už nebudú žiadne problémy s int alebo reťazcom, nie je potrebné zabaliť nulu do dvojitých úvodzoviek. Zobrazí sa schéma JSONS, ktorá vám umožní explicitne to opísať pre hodnoty.
Bude silne prepracovaná model riadený udalosťami. Koncepčne to už bolo popísané. Pozrite sa na vetvu Helm 3 a uvidíte, koľko udalostí a háčikov a iných vecí pribudlo, čo výrazne zjednoduší a na druhej strane pridá kontrolu nad procesmi nasadzovania a reakcií na ne.
Helm 3 bude jednoduchší, bezpečnejší a zábavnejší, nie preto, že by sa nám nepáčil Helm 2, ale preto, že Kubernetes je stále pokročilejší. V súlade s tým môže Helm využiť vývoj Kubernetes a vytvoriť na ňom vynikajúcich manažérov pre Kubernetes.
Ďalšou dobrou správou je, že Alexander Khayorov vám povie, Pripomeňme, že konferencia o integrácii procesov vývoja, testovania a prevádzky sa bude konať v Moskve 30. septembra a 1. októbra. Môžete tak urobiť ešte do 20. augusta a povedzte nám o svojich skúsenostiach s riešením úlohy prístupu DevOps.
Sledujte kontrolné body konferencie a novinky na и .
Zdroj: hab.com