Varnost Helm

Osnovna tema priču o najpopularnijem menadžeru paketa za Kubernetes može se prikazati emodžijem:

• kutija — to je Helm (to je najprikladnije u poslednjoj verziji emodžija);
• ključa — sigurnost;
• čovek — rešenje problema.

U stvarnosti, sve će biti malo složenije, i priča je puna tehničkih detalja o tome, kako učiniti Helm sigurnim.

• Kratko o tome šta je Helm, ako niste znali ili ste zaboravili. Koje probleme rešava i gde se nalazi u ekosistemu.
• Razmotrićemo arhitekturu Helma. Nijedan razgovor o sigurnosti i o tome kako učiniti alat ili rešenje bezbednijim ne može proći bez razumevanja arhitekture komponenti.
• Razgovaraćemo o komponentama Helma.
• Najvažnije pitanje — budućnost — nova verzija Helma 3. 

Sve u ovom članku odnosi se na Helm 2. Ova verzija je trenutno u produkciji i verovatno je to što trenutno koristite, i u njoj postoje bezbednosni rizici.

O predavaču: Aleksandar Hajorov (allexx) se bavi razvojem već 10 godina, pomaže u unapređenju sadržaja Moscow Python Conf++ i pridružio se odboru Helm Summit. Trenutno radi u Chainstack-u kao voditelj razvoja — to je hibrid između vođe razvoja i osobe zadužene za isporuku finalnih izdanja. Dakle, nalazi se na liniji fronta, gde se sve dešava od stvaranja proizvoda do njegove eksploatacije.

Chainstack je mali, aktivno rastući startap, čija je misija da omogući klijentima da zaborave na infrastrukturu i komplikacije upravljanja decentralizovanim aplikacijama, tim za razvoj se nalazi u Singapuru. Ne pitajte Chainstack da proda ili kupi kriptovalutu, ali predložite razgovor o enterprise blockchain okvirima, i rado će vam odgovoriti.

Helm

To je menadžer paketa (chartova) za Kubernetes. Najjasniji i najuniverzalniji način za dovođenje aplikacija u Kubernetes klaster.

Naravno, reč je o strukturiranijem i industrijskom pristupu, nego o pravljenju sopstvenih YAML manifestacija i pisanju malih alata.

Helm je najbolje što trenutno imamo od dostupnih i popularnih.

Zašto Helm? Pre svega zato što ga podržava CNCF. Cloud Native je velika organizacija, matična kompanija za projekte Kubernetes, etcd, Fluentd i druge.

Še en pomemben podatek: Helm je zelo priljubljen projekt. Ko sem januarja 2019 le razmišljal o tem, kako narediti Helm varen, je imel projekt tisoč zvezdic na GitHubu. Do maja jih je bilo že 12 tisoč.

Veliko ljudi se zanima za Helm, zato vam bodo, tudi če ga še ne uporabljate, znanja o njegovi varnosti prišla prav. Varnost je pomembna.

Glavno ekipo Helma podpira Microsoft Azure, zato je to razmeroma stabilen projekt v primerjavi z mnogimi drugimi. Izdaja Helm 3 Alpha 2 sredi julija kaže, da na projektu dela precejšnje število ljudi, ki imajo voljo in moč, da razvijajo ter izboljšujejo Helm.

Helm rešuje več temeljnih težav pri upravljanju aplikacij v Kubernetesu.

• Pakiranje aplikacije. Tudi aplikacija tipa „Hello, World“ na WordPressu že predstavlja več storitev, ki jih želimo skupaj pakirati.
• Upravljanje zapletenosti, ki nastane pri upravljanju teh aplikacij.
• Življenjski ciklus, ki se ne konča z namestitvijo ali uvajanjem aplikacije. Aplikacija živi naprej, potrebno jo je posodobiti, pri čemer Helm pomaga in se trudi prinesti prave ukrepe in politike.

Pakiranje je zasnovano na razumljiv način: obstajajo metapodatki, ki so v popolnem skladu z delovanjem običajnega upravitelja paketov za Linux, Windows ali MacOS. To pomeni repozitorij, odvisnosti od različnih paketov, meta informacije za aplikacije, nastavitve, posebnosti konfiguracije, indeksiranje informacij in tako naprej. Vse to Helm omogoča za pridobitev in uporabo pri aplikacijah.

Upravljanje zapletenosti. Če imate veliko enakih aplikacij, potrebujete parametrizacijo. Iz tega izhajajo predloge, vendar da ne bi izumljali svojega načina ustvarjanja predlog, lahko uporabite tisto, kar Helm ponuja iz škatle.

Upravljanje življenjskega cikla aplikacije — po mojem mnenju je to najzanimivejša in še nerešena vprašanja. To je razlog, zakaj sem se nekoč odločil za Helm. Potrebovali smo slediti življenjskemu ciklu aplikacije, želeli smo prenesti naš CI/CD in cikle aplikacij v to paradigmo.

Helm omogoča:

• upravljanje uvajanj, uvaja koncept konfiguracije in revizije;
• uspešno izvajati rollback;
• uporabljati hooke za različne dogodke;
• dodajati dodatne preglede aplikacij in se odzivati na njihove rezultate.

Poleg tega Helm ima 'baterije' — veliko število okusnih stvari, ki jih je mogoče vključiti kot vtičnike, s čimer si poenostavite življenje. Vtičnike lahko napišete sami, so dovolj izolirani in ne zahtevajo kompleksne arhitekture. Če želite nekaj uresničiti, priporočam, da to storite kot vtičnik, nato pa ga morda vključite v upstream.

Helm temelji na treh osnovnih konceptih:

• Chart Repo — opis in niz parametrizacije, možne za vaš manifest. 
• Konfiguracija — torej vrednosti, ki se bodo uporabile (besedilo, številčne vrednosti itd.).
• Release združuje dva zgornja komponenta, ki se skupaj spremenita v Release. Izdaje je mogoče verzionirati, s tem pa doseči organizacijo življenjskega cikla: majhno ob namestitvi in veliko ob nadgradnji, znižanju ali povratku.

Arhitektura Helm

Na shemi je konceptualno prikazana visoka raven arhitekture Helm.

Opominjam, da je Helm nekaj, kar je povezano s Kubernetesom. Zato brez klasterja Kubernetes ne gre (pravokotnik). Komponenta kube-apiserver je na masterju. Brez Helma imamo Kubeconfig. Helm prinaša eno majhno binarno, če tako lahko rečemo, orodje Helm CLI, ki se namesti na računalnik, prenosnik, glavno napravo — na karkoli.

Toda to ni dovolj. Helm ima strežni komponent Tiller. Ta zastopa interese Helma znotraj klasterja, je podobna aplikacija znotraj klasterja Kubernetes, kot vsaka druga.

Naslednji komponent Chart Repo — repozitorij s charti. Obstaja uradni repozitorij in lahko obstaja zasebni repozitorij podjetja ali projekta.

Interakcija

Poglejmo, kako komponente arhitekture sodelujejo, ko želimo namestiti aplikacijo s pomočjo Helma.

• Rečemo Helm install, se obrnejo na repozitorij (Chart Repo) in pridobimo Helm chart.

• Helm orodje (Helm CLI) interactira s Kubeconfig, da izve, kateri klaster naj pokliče. 
• Ko pridobi te informacije, orodje pokliče Tillerja, ki se nahaja v našem klasterju, kot aplikacijo. 
• Tiller pokliče Kube-apiserver, da izvede dejanja v Kubernetesu, ustvari nekateri objekti (storitev, pod, replik, skrivnosti itd.).

Nato bomo zapletli shemo, da vidimo vektor napadov, katerim je lahko izpostavljena celotna arhitektura Helma. Nato jo bomo poskušali zaščititi.

Vektor napadov

Prvo potencialno šibko mesto — privilegiran API—uporabnikV okviru sheme je to heker, ki je pridobil admin dostop do Helm CLI.

Nepreprivilegiran API uporabnik prav tako lahko predstavlja nevarnost, če je kje blizu. Tak uporabnik bo imel drug kontekst, na primer, lahko bo zabeležen v enem namespace-u klustra v nastavitvah Kubeconfig.

Najbolj zanimiva vektorska napada je lahko proces, ki se nahaja znotraj klustra nekje blizu Tillerja in ga lahko pokliče. To je lahko spletni strežnik ali mikroservis, ki vidi omrežno okolje klustra.

Ekzotična, a naraščajoče priljubljena, možnost napada je povezana s Chart Repo. Čart, ki ga je ustvaril zlonamerni avtor, lahko vsebuje nezanesljive vire in ga boste izvedli, ker ste mu zaupali. Lahko pa tudi zamenja čart, ki ga prenašate z uradnega repozitorija, in na primer ustvari vir v obliki politik in si tako escalira dostop.

Poskusimo se obraniti pred napadi s vseh teh štirih strani in ugotoviti, kje so tu težave v arhitekturi Helma, in kje morda niso.

Povečajmo shemo, dodajmo več elementov, a ohranimo vse osnovne sestavine.

Helm CLI komunicira s Chart Repo, sodeluje s Kubeconfig, delo se prenese v kluster v komponento Tiller.

Tiller je predstavljen z dvema objektoma:

• Tiller-deploy svc, ki določa nek servis;
• Tiller-deploy pod (na shemi v enem samem primeru v eni repliki), na katerem deluje celotna obremenitev, ki se obrača na kluster.

Za interakcijo se uporabljajo različni protokoli in sheme. Z vidika varnosti so nam najbolj zanimivi:

• Mehanizem, s pomočjo katerega Helm CLI dostopa do chart repo: kateri protokol, ali obstaja avtentikacija in kaj lahko s tem storimo.
• Protokol, po katerem Helm CLI, ob uporabi kubectl, komunicira s Tillerjem. Gre za RPC strežnik, nameščen znotraj klustra.
• Sam Tiller je dostopen mikroservisom, ki se nahajajo v klstru, in komunicira s Kube-apiserverjem.

Obravnavali bomo vsa ta področja po vrsti.

RBAC

Brezplodno je govoriti o kakršni koli varnosti Helma ali drugega servisa znotraj klustra, če RBAC ni vklopljen.

Zdi se, da to ni najnovejša priporočila, a sem prepričan, da še vedno mnogi niso vklopili RBAC niti v produkciji, ker je to velika težava in je potrebno veliko nastaviti. Kljub temu pozivam, da to storite.

https://rbac.dev/ — pravni sajt za RBAC. Tu se okuplja ogroman broj zanimljivih materijala koji će pomoći u podešavanju RBAC-a, prikazati zašto je dobar i kako uopšte živeti s njim u produkciji.

Pokušaću objasniti kako funkcionišu Tiller i RBAC. Tiller radi unutar klastera pod nekim servisnim nalogom. Obično, ako RBAC nije podešen, to će biti superkorisnik. U osnovnoj konfiguraciji, Tiller će biti administrator. Zato se često kaže da je Tiller — SSH tunel za vaš klaster. U stvarnosti je to tako, pa se može koristiti poseban specijalizovani servisni nalog umesto Default Service Account na gornjem dijagramu.

Kada inicijalizujete Helm, prvi put ga instalirate na server, možete postaviti servisni nalog pomoću --service-account. To će omogućiti korišćenje korisnika sa minimalnim potrebnim skupom prava. Ipak, moraćete da kreirate takvu "nizu": Role i RoleBinding.

Nažalost, Helm to neće učiniti umesto vas. Vama ili vašem administratoru Kubernetes klastera potrebno je unapred pripremiti skup Role i RoleBinding za servisni nalog, kako bi se prosledili Helmu.

Postavlja se pitanje — koja je razlika između Role i ClusterRole? Razlika je u tome što ClusterRole deluje za sve namespaces, za razliku od običnih Role i RoleBinding, koji rade samo za specijalizovani namespace. Možete postaviti politike i za ceo klaster i sve namespaces, kao i personalizovano za svaki namespace posebno.

Vredno je pomenuti da RBAC takođe rešava još jedan veliki problem. Mnogi se žale da Helm, nažalost, nije multitenancy (ne podržava više stanara). Ako više timova koristi klaster i koristi Helm, nije moguće postaviti politike i razdvojiti njihov pristup u okviru ovog klastera, jer postoji neki servisni nalog pod kojim radi Helm, i on stvara resurse u klasteru, što ponekad može biti vrlo neprikladno. To je istina — kao sam izvršni fajl, kao proces, Helm Tiller nema koncept multitenancy..

Međutim, postoji odličan način koji omogućava pokretanje Tillera u klasteru više puta. Sa tim nema nikakvih problema, Tiller se može pokrenuti u svakom namespace-u. Na taj način možete iskoristiti RBAC, Kubeconfig kao kontekst, i ograničiti pristup specijalnom Helmu.

To će izgledati ovako.

Na primjer, postoje dvije Kubeconfig datoteke s kontekstom za različite timove (dva namespace): X Team za tim programera i klaster admina. Klaster admina ima svoj široki Tiller, koji se nalazi u prostoru Kube-system namespace, a samim tim i napredni service-account. I odvojen namespace za tim programera, koji će moći implementirati svoje usluge u posebni namespace.

To je funkcionalan pristup, Tiller nije toliko prožderan da bi to značajno utjecalo na vaš budžet. To je jedno od brzih rješenja.

Ne ustručavajte se zasebno konfigurirati Tiller i osigurati Kubeconfig s kontekstom za tim, za određenog programera ili za okruženje: Dev, Staging, Production (doubtful that everything will be on the same cluster, however, this can be done).

Nastavljajući našu priču, prebacit ćemo se s RBAC-a i razgovarati o ConfigMaps.

ConfigMaps

Helm koristi ConfigMaps kao skladište podataka. Kada smo govorili o arhitekturi, nigdje nije bila baza podataka u kojoj bi se nalazile informacije o izdanjima, konfiguracijama, povratcima itd. Za to se koristi ConfigMaps.

Glavni problem s ConfigMaps je poznat — oni nisu sigurni u načelu, u njima nije moguće pohranjivati sensitive podatke. To se odnosi na sve što ne bi smjelo izaći iz servisa, poput lozinki. Najnativniji način za Helm trenutno je prijeći s korištenja ConfigMaps na tajne.

To se radi vrlo lako. Override-ate postavku Tiller-a i navodite da će skladište biti tajne. Tada ćete pri svakoj implementaciji dobiti ne ConfigMap, nego tajnu.

Možete prigovoriti da su same tajne — neobična koncepcija, i to ne izgleda previše sigurno. Međutim, treba razumjeti da se time bave sami programeri Kubernetes-a. Počevši od verzije 1.10, tj. već dosta vremena, postoji mogućnost, barem u javnim oblačnim uslugama, povezivanja ispravnog skladišta za pohranu tajni. Trenutno tim radi na tome da još bolje kontrolira pristup tajnama, pojedinačnim podovima ili drugim entitetima.

Skladište Helm je bolje prebaciti na tajne, a njih zauzvrat centralizirano osigurati.

Naravno, ostat će limit za pohranu podataka od 1 MB. Helm tukaj uporablja etcd kot porazdeljeno shrambo za ConfigMaps. In tam so se odločili, da je to primeren kos podatkov za replikacije itd. Na to temo je zanimiva razprava na Redditu, priporočam, da najdete to zabavno branje za konec tedna ali preberete povzetek. tukaj.

Chart Repos

Charte so najbolj družbeno ranljive in lahko postanejo vir "Man in the middle", še posebej, če uporabite privzeto rešitev. V prvi vrsti gre za repozitorije, ki so dostopni preko HTTP.

Definitivno je potrebno nastaviti Helm Repo preko HTTPS — to je najboljša možnost in ni draga.

Upoštevajte mehanizem podpisovanja chartov. Tehnologija je enostavna do grozljivosti. To je isto, kar uporabljate na GitHubu, običajna PGP mehanizacija z javnimi in privatnimi ključi. Nastavite in prepričani boste, saj imate potrebne ključe in podpisujete vse, kar je res vaš chart.

Pored toga, Helm odjemalec podpira TLS (ne v smislu HTTP s strani strežnika, temveč mutual TLS). Uporabite lahko strežniške in odjemalske ključe za komunikacijo. Moram biti iskren, tega mehanizma ne uporabljam zaradi neprednosti do mutual certifikatov. Na splošno, chartmuseum — glavno orodje za postavitev Helm Repo za Helm 2 — podpira tudi basic auth. Lahko uporabite basic auth, če je to bolj priročno in umirjujoče.

Še obstaja plugin helm-gcs, ki omogoča gostovanje Chart Repos v Google Cloud Storage. To je precej priročno, odlično deluje in je dovolj varno, saj se uničijo vsi opisani mehanizmi.

Če omogočite HTTPS ali TLS, uporabite mTLS, povežite basic auth, da še dodatno zmanjšate tveganja, dobite varen komunikacijski kanal med Helm CLI in Chart Repo.

gRPC API

Naslednji korak je zelo odgovoren — zaščititi Tiller, ki se nahaja v klastru in je, po eni strani, strežnik, po drugi strani — se sam obrača na druge komponente in se poskuša predstavljati kot nekdo drug.

Kot sem že rekel, Tiller je storitev, ki ponuja gRPC, Helm odjemalec se povezuje z njim preko gRPC. Po privzetih nastavitvah je TLS seveda izklopljen. Zakaj je to narejeno — vprašanje je diskuzijsko, zdi se mi, da je to za poenostavitev nastavitve na začetku.

Za produkcijo in celo za staging priporočam, da omogočite TLS na gRPC.

Po mojem mnenju, v nasprotju z mTLS za grafične karte, je to tukaj primerno in enostavno za izvedbo — generirate infrastrukturo PQI, ustvarite certifikat, zaženete Tiller in predate certifikat med inicializacijo. Po tem lahko izvajate vse Helm ukaze, identificirate se z generiranim certifikatom in zasebnim ključem.

S tem se zaščitite pred vsemi zahtevki do Tillerja izven klasterja.

Torej, zaščitili smo povezovalni kanal do Tillerja, že razpravljali o RBAC in prilagodili pravice Kubernetes apiserverja ter zmanjšali domeno, s katero lahko komunicira.

Zavarovan Helm

Poglejmo končno shemo. To je enaka arhitektura s istimi puščicami.

Vse povezave zdaj lahko brez skrbi označimo z zeleno:

• za Chart Repo uporabljamo TLS ali mTLS in osnovno avtentifikacijo;
• mTLS za Tiller, ki je nastavljen kot gRPC storitev s TLS, uporabljamo certifikate;
• v klasterju se uporablja posebna servisna računala s pravicami in RoleBinding-om. 

Znatno smo zaščitili klaster, vendar je nekdo pameten dejal:

„Popolnoma varna rešitev je lahko samo ena — izklopljen računalnik, ki je v betonski škatli in ga varujejo vojaki.“

Obstajajo različni načini manipulacije s podatki in iskanja novih vektorjev napadov. Vendar sem prepričan, da vam te priporočitve omogočajo uresničitev osnovnega industrijskega standarda varnosti.

Bonusp

Ta del se neposredno ne nanaša na varnost, vendar bo tudi koristen. Prikazal bom nekatere zanimive stvari, o katerih malo ljudi ve. Na primer, kako iskati grafe — uradne in neuradne.

U repozitorijumu github.com/helm/charts trenutno je okoli 300 grafov in dva toka: stable in incubator. Tisti, ki prispevajo, se dobro zavedajo, kako težko je priti iz incubatorja v stable in kako lahko iz stable hitro izpadeš. Vendar to ni najboljše orodje za iskanje grafov za Prometheus in vse, kar vam je ljubše, iz enega preprostega razloga — to ni portal, kjer bi bilo enostavno iskati pakete.

Obstaja pa storitev hub.helm.sh, s pomočjo katere je iskanje grafov bistveno bolj udobno. Najpomembneje je, da tam obstaja veliko več zunanjih repozitorijev in na voljo je skoraj 800 grafov. Poleg tega lahko priključite svoj repozitorij, če iz kakršnegakoli razloga ne želite poslati svojih grafov v stable.

Preizkusite hub.helm.sh in razvijajmo ga skupaj. Ta storitev je pod Helm projektom, in lahko prispevate celo v njegov UI, če ste frontend razvijalec in želite preprosto izboljšati videz.

Še posebej bi rad opozoril na integracijo Open Service Broker API. Zveni zapleteno in nejasno, vendar rešuje težave, s katerimi se srečujemo vsi. Pojasnil bom na preprostem primeru.

Imamo Kubernetes-kluster, v katerem želimo zagnati klasično aplikacijo — WordPress. Običajno potrebujemo podatkovno bazo za popolno funkcionalnost. Obstaja veliko različnih rešitev; na primer, lahko zaženemo svoj stateful servis. To ni ravno priročno, a mnogi to počnejo.

Drugi, na primer mi v Chainstack, uporabljajo upravljane podatkovne baze, kot sta MySQL ali PostgreSQL, za strežnike. Tako so naše baze podatkov nekje v oblaku.

Toda nastane težava: naš servis moramo povezati s podatkovno bazo, ustvariti flavor podatkovne baze, prenesti poverilnice in nekako jih upravljati. Vse to običajno opravi sistemski administrator ali razvijalec ročno. In ni nobene težave, ko je aplikacij malo. Ko jih je veliko, potrebujemo kombajn. Tak kombajn je — to je Service Broker. Omogoča uporabo posebnega vtičnika za kluster javnega oblaka in naročanje virov pri ponudniku prek Brokerja, kot da gre za API. Za to lahko uporabimo nativna orodja Kubernetes.

To je zelo preprosto. Lahko zahtevamo na primer Managed MySQL v Azure z osnovnim tierjem (to je mogoče nastaviti). Z uporabo API-ja Azure bo baza ustvarjena in pripravljena za uporabo. Ni vam treba posegati v to, za to skrbi vtičnik. Na primer, OSBA (vtičnik Azure) vrne poverilnice v servis in jih prenese nazaj na Helm. Tako boste lahko uporabljali WordPress z oblakom MySQL, brez skrbi o upravljanih podatkovnih bazah in brez težav s stateful servisi znotraj.

Lahko rečemo, da Helm deluje kot lepilo, ki na eni strani omogoča uvedbo servisov, na drugi pa porabo virov oblaku.

Lahko napišete svoj vtičnik in uporabite to zgodbo on-premise. Tako boste imeli svoj vtičnik za korporativnega Cloud ponudnika. Priporočam, da preizkusite tak pristop, zlasti če imate veliko obseg in želite hitro razporediti dev, staging ali celo celotno infrastrukturo za funkcijo. To bo olajšalo življenje vašemu operativnemu timu ali DevOps.

Še en odkritje, ki sem ga že omenjal — to je vtičnik helm-gcs, ki omogoča uporabo Google-bucketov (objektno shranjevanje), da shranite Helm grafe.

Potrebne so le štiri ukaze, da ga začnete uporabljati:

1. namestite vtičnik;
2. inisirajte ga;
3. nastaviti pot na bucket koji se nalazi u gcp;
4. objaviti grafikone standardnim načinom.

Lijepo je to što će se koristiti nativni način gcp za autorizaciju. Možete koristiti servisni račun, račun programera — sve što želite. To je vrlo zgodno i ne košta ništa u operativnom smislu. Ako, kao i ja, propagirate opsless filozofiju, ovo će biti veoma zgodno, posebno za male timove.

Alternatives

Helm nije jedino rješenje za upravljanje servisima. Ima mnogo pitanja, možda zbog toga je treća verzija tako brzo došla. Naravno, postoje alternative.

To mogu biti specijalizovana rješenja, kao što su Ksonnet ili Metaparticle. Možete koristiti svoja klasična sredstva za upravljanje infrastrukturom (Ansible, Terraform, Chef itd.) za iste ciljeve o kojima sam govorio.

Na kraju, postoji rješenje Operator Framework, čija popularnost raste.

Operator Framework je glavna alternativa Helmu, na koju treba obratiti pažnju.

Ono je više nativno za CNCF i Kubernetes, ali je prag ulaska mnogo viši, potrebno je više programirati i manje opisivati manifeste.

Postoje razni dodaci, poput Draft, Scaffold. Ovi dodaci jako olakšavaju život, na primjer, olakšavaju ciklus slanja i pokretanja Helma za deployment testnog okruženja. Nazvao bih ih povećivačima mogućnosti.

Evo vizualne obrade o tome gdje šta stoji.

Na horizontalnoj osi je nivo vaše lične kontrole nad dešavanjima, a na vertikalnoj osi — nivo nativnosti Kubernetesa. Helm verzija 2 je negdje na sredini. U verziji 3 nije ogromna razlika, ali su poboljšani i kontrola i nivo nativnosti. Rješenja poput Ksonnet ipak zaostaju čak i za Helm 2. Međutim, vrijedi ih pogledati kako biste znali što sve još postoji u ovom svijetu. Naravno, vaš menadžer konfiguracija će biti pod vašom kontrolom, ali nije apsolutno nativan za Kubernetes.

Operator Framework je apsolutno nativan za Kubernetes i omogućava elegantnije i pažljivije upravljanje (ali ne zaboravite na prag ulaska). Radije bi ovo odgovaralo specijalizovanoj aplikaciji i stvaranju menadžmenta za nju, nego masovnoj mašini za pakovanje velikog broja aplikacija putem Helma.

Povećivači samo malo poboljšavaju kontrolu, dopunjuju radne tokove ili skraćuju uglove CI/CD pipelina.

Budućnost Helma

Dobra novica je, da se pojavlja Helm 3. Že je izšla alfa različica Helm 3.0.0-alpha.2, ki jo lahko preizkusite. Je dovolj stabilna, vendar je funkcionalnost zaenkrat omejena.

Zakaj je Helm 3 potreben? Predvsem gre za izginotje Tillerja, kot komponente. To je, kot verjetno razumete, ogromen korak naprej, saj se s stališča varnosti arhitekture vse poenostavi.

Ko je bil ustvarjen Helm 2, kar se je zgodilo v časih Kubernetes 1.8 ali celo prej, so bile številne koncepcije nezrele. Na primer, koncept CRD se danes aktivno uvaja in Helm bo uporabljal CRD, da hrani strukture. Postalo bo mogoče uporabljati le stranko in ne obdržati strežniškega dela. Tako bo mogoče uporabljati nativne ukaze Kubernetes za delo s strukturami in viri. To je ogromen korak naprej.

Pojavila se bo podpora nativnim OCI repozitorijem ({Open Container Initiative}). To je ogromna pobuda in Helm je zanjo zanimiv predvsem zato, da bi lahko gostili svoje grafične pakete. Pride do tega, da na primer Docker Hub podpira številne standarde OCI. Ne napovedujem, a morda bodo klasični ponudniki Docker repozitorijev začeli omogočati gostovanje vaših Helm grafičnih paketov.

Sporna zgodba zame je podpora Lua, kot templating engine za pisanje skript. Nisem velik oboževalec Lua, a to bo povsem opcijska možnost. To sem preveril trikrat – uporaba Lua ne bo obvezna. Zato, tisti, ki želite uporabiti Lua, lahko to storite, tisti, ki imate raje Go – pridružite se našemu velikemu taboru in uporabite go-tmpl za to.

Končno tisto, česar mi je zagotovo primanjkovalo, je pojavitev sheme in validacija tipov podatkov. Nič več ne bo težav s int ali string, ne bo treba ovijati ničle v dvojne narekovaje. Uvedena bo JSON schema, ki bo omogočila jasno opisovanje za values.

Zelo močno bo predelana model, ki temelji na dogodkih. Že je konceptualno opisano. Poglejte v vejo Helm 3 in videli boste, koliko dogodkov, hookov in drugih stvari je bilo dodanih, kar bo močno poenostavilo in hkrati dodalo nadzor nad procesi namestitve in njihovimi reakcijami.

Helm 3 bo preprostejši, varnejši in zanimivejši ne zato, ker ne maramo Helma 2, ampak ker Kubernetes postaja bolj napreden. Tako lahko Helm izkorišča dosežke Kubernetes in ustvarja odlične upravljavce za Kubernetes.

Še ena dobra novica je, da DevOpsConf Aleksander Chajerov bo spregovoril, ali so lahko kontejnerji varni? Spomnimo, da bo konferenca o integraciji procesov razvoja, testiranja in delovanja potekala v Moskvi 30. septembra in 1. oktobra. Do 20. avgusta je še mogoče predložiti referat in predstaviti svoje izkušnje pri reševanju ene iz mnogih nalog DevOps pristopa.

Sledite konferenčnim mejnim toškam in novicam na novičkah in telegram kanal.

Izvor: habr.com