Helm Security

Suština priče o najpopularnijem paketnom menadžeru za Kubernetes mogla bi se dočarati emojijem:

• kutija je Helm (što je najbliže posljednjem Emoji izdanju);
• brava - sigurnost;
• mali čovjek je rješenje problema.

Zapravo, sve će biti malo kompliciranije, a priča je puna tehničkih detalja o tome Kako Helm učiniti sigurnim.

• Ukratko što je Helm ako niste znali ili ste zaboravili. Koje probleme rješava i gdje se nalazi u ekosustavu.
• Pogledajmo arhitekturu Helma. Nijedan razgovor o sigurnosti i kako alat ili rješenje učiniti sigurnijim nije potpun bez razumijevanja arhitekture komponente.
• Razgovarajmo o komponentama Helma.
• Najgoruće pitanje je budućnost - nova verzija Helma 3. 

Sve u ovom članku odnosi se na Helm 2. Ova verzija je trenutno u proizvodnji i najvjerojatnije je ona koju trenutno koristite, a to je verzija koja sadrži sigurnosne rizike.

O govorniku: Alexander Khayorov (allexx) razvija se 10 godina, pomažući u poboljšanju sadržaja Moskva Python Conf++ i pridružio se odboru Helmski vrh. Sada radi u Chainstacku kao voditelj razvoja - ovo je hibrid između voditelja razvoja i osobe koja je odgovorna za isporuku finalnih izdanja. Odnosno, nalazi se na bojnom polju, gdje se događa sve od stvaranja proizvoda do njegovog rada.

Chainstack je mali, aktivno rastući startup čija je misija omogućiti klijentima da zaborave na infrastrukturu i složenost rada decentraliziranih aplikacija; razvojni tim nalazi se u Singapuru. Ne tražite od Chainstacka da proda ili kupi kriptovalutu, već ponudite razgovor o okvirima blockchaina za poduzeća i oni će vam rado odgovoriti.

Kormilo

Ovo je upravitelj paketa (grafikona) za Kubernetes. Najintuitivniji i najuniverzalniji način za dovođenje aplikacija u Kubernetes klaster.

Mi, naravno, govorimo o više strukturnom i industrijskom pristupu od stvaranja vlastitih YAML manifesta i pisanja malih pomoćnih programa.

Helm je najbolje što je trenutno dostupno i popularno.

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

Još jedna važna činjenica je da je Helm vrlo popularan projekt. Kad sam počeo govoriti o tome kako Helm učiniti sigurnim u siječnju 2019., projekt je imao tisuću zvjezdica na GitHubu. Do svibnja ih je bilo 12 tisuća.

Mnogi su ljudi zainteresirani za Helm, pa čak i ako ga još ne koristite, dobro će vam biti saznanje o njegovoj sigurnosti. Sigurnost je važna.

Glavni Helm tim podržava Microsoft Azure i stoga je prilično stabilan projekt, za razliku od mnogih drugih. Izlazak Helm 3 Alpha 2 sredinom srpnja ukazuje na to da dosta ljudi radi na projektu i da imaju želju i energiju razvijati i poboljšavati Helm.

Helm rješava nekoliko temeljnih problema upravljanja aplikacijama u Kubernetesu.

• Pakiranje aplikacije. Čak se i aplikacija poput “Hello, World” na WordPressu već sastoji od nekoliko usluga, a vi ih želite spakirati zajedno.
• Upravljanje složenošću koja dolazi s upravljanjem ovim aplikacijama.
• Životni ciklus koji ne završava nakon instalacije ili implementacije aplikacije. On nastavlja živjeti, treba ga ažurirati, a Helm u tome pomaže i nastoji donijeti prave mjere i politike za to.

Pakiranje organiziran je na jasan način: postoje metapodaci u potpunom skladu s radom običnog upravitelja paketa za Linux, Windows ili MacOS. To jest, repozitorij, ovisnosti o različitim paketima, meta informacije za aplikacije, postavke, značajke konfiguracije, indeksiranje informacija itd. Helm vam omogućuje da sve to dobijete i koristite za aplikacije.

Upravljanje složenošću. Ako imate mnogo aplikacija iste vrste, tada je potrebna parametrizacija. Odatle proizlaze predlošci, ali kako ne biste morali smišljati vlastiti način stvaranja predložaka, možete koristiti ono što Helm nudi odmah.

Upravljanje životnim ciklusom aplikacije - po mom mišljenju, ovo je najzanimljivije i neriješeno pitanje. Zbog toga sam svojevremeno došao u Helm. Morali smo paziti na životni ciklus aplikacije i htjeli smo premjestiti naše CI/CD i cikluse aplikacija na ovu paradigmu.

Helm vam omogućuje da:

• upravljati implementacijama, uvodi koncept konfiguracije i revizije;
• uspješno provesti vraćanje;
• koristiti kuke za različite događaje;
• dodati dodatne provjere zahtjeva i odgovoriti na njihove rezultate.

Štaviše Helm ima "baterije" - ogroman broj ukusnih stvari koje se mogu uključiti u obliku dodataka, pojednostavljujući vam život. Dodaci se mogu pisati neovisno, prilično su izolirani i ne zahtijevaju skladnu arhitekturu. Ako želite nešto implementirati, preporučam da to učinite kao dodatak, a zatim ga eventualno uključite uzvodno.

Helm se temelji na tri glavna koncepta:

• Repo grafikona — opis i niz parametara mogućih za vaš manifest. 
• config — odnosno vrijednosti koje će se primijeniti (tekst, numeričke vrijednosti itd.).
• Pustite skuplja dvije gornje komponente, i zajedno se pretvaraju u Release. Izdanjima se može upravljati verzijama, čime se postiže organizirani životni ciklus: mali u vrijeme instalacije i veliki u vrijeme nadogradnje, vraćanja na stariju verziju ili vraćanja.

Helmova arhitektura

Dijagram konceptualno prikazuje arhitekturu visoke razine Helma.

Da podsjetim da je Helm nešto vezano uz Kubernetes. Stoga ne možemo bez Kubernetes klastera (pravokutnika). Komponenta kube-apiserver nalazi se na masteru. Bez Helma imamo Kubeconfig. Helm donosi jedan mali binarni, ako se tako može nazvati, Helm CLI uslužni program koji se instalira na računalo, laptop, mainframe - na bilo što.

Ali ovo nije dovoljno. Helm ima komponentu poslužitelja koja se zove Tiller. Zastupa interese Helma unutar klastera, to je aplikacija unutar Kubernetes klastera, kao i svaka druga.

Sljedeća komponenta Chart Repo je repozitorij s grafikonima. Postoji službeni repozitorij, a može postojati i privatni repozitorij tvrtke ili projekta.

Interakcija

Pogledajmo kako komponente arhitekture međusobno djeluju kada želimo instalirati aplikaciju koristeći Helm.

• Mi govorimo Helm install, pristupite repozitoriju (Chart Repo) i nabavite Helm grafikon.

• Pomoćni program Helm (Helm CLI) komunicira s Kubeconfigom kako bi otkrio koji klaster kontaktirati. 
• Nakon što je dobio ovu informaciju, uslužni program kao aplikaciju upućuje na Tiller koji se nalazi u našem klasteru. 
• Tiller poziva Kube-apiserver da izvrši radnje u Kubernetesu, stvori neke objekte (usluge, podove, replike, tajne itd.).

Zatim ćemo zakomplicirati dijagram kako bismo vidjeli vektor napada kojem cijela Helmova arhitektura kao cjelina može biti izložena. A onda ćemo je pokušati zaštititi.

Vektor napada

Prva potencijalna slaba točka je privilegirani API-korisnik. Kao dio sheme, ovo je haker koji je dobio administratorski pristup Helm CLI-ju.

Neovlašteni API korisnik također može predstavljati opasnost ako je negdje u blizini. Takav će korisnik imati drugačiji kontekst, na primjer, može biti fiksiran u jednom prostoru imena klastera u Kubeconfig postavkama.

Najzanimljiviji vektor napada mogao bi biti proces koji se nalazi unutar klastera negdje blizu Tillera i može mu pristupiti. To može biti web poslužitelj ili mikroservis koji vidi mrežno okruženje klastera.

Egzotična, ali sve popularnija varijanta napada uključuje Chart Repo. Grafikon koji je izradio beskrupulozni autor može sadržavati nesigurne resurse, a vi ćete ga dovršiti ako ga prihvatite s vjerom. Ili može zamijeniti grafikon koji ste preuzeli sa službenog repozitorija i, na primjer, stvoriti resurs u obliku pravila i eskalirati njegov pristup.

Pokušajmo obraniti napade sa sve ove četiri strane i shvatiti gdje ima problema u arhitekturi Helma, a gdje ih možda nema.

Povećajmo dijagram, dodajmo više elemenata, ali zadržimo sve osnovne komponente.

Helm CLI komunicira s Chart Repo, komunicira s Kubeconfigom, a rad se prenosi u klaster na Tiller komponentu.

Tiller je predstavljen s dva objekta:

• Tiller-deploy svc, koji izlaže određenu uslugu;
• Tiller-deploy pod (na dijagramu u jednom primjerku u jednoj replici), na kojem se pokreće cijelo opterećenje, koje pristupa klasteru.

Za interakciju se koriste različiti protokoli i sheme. Sa sigurnosnog gledišta najviše nas zanima:

• Mehanizam kojim Helm CLI pristupa repou grafikona: koji protokol, postoji li autentifikacija i što se s njom može učiniti.
• Protokol kojim Helm CLI, koristeći kubectl, komunicira s Tillerom. Ovo je RPC poslužitelj instaliran unutar klastera.
• Sam Tiller je dostupan mikroservisima koji se nalaze u klasteru i komunicira s Kube-apiserverom.

Raspravljajmo redom o svim ovim područjima.

RBAC

Nema smisla govoriti o bilo kakvoj sigurnosti za Helm ili bilo koji drugi servis unutar klastera osim ako je RBAC omogućen.

Čini se da ovo nije najnovija preporuka, ali siguran sam da mnogi ljudi još uvijek nisu uključili RBAC čak ni u produkciji, jer je to puno frke i puno stvari treba konfigurirati. Međutim, potičem vas da to učinite.

https://rbac.dev/ — web odvjetnik za RBAC. Sadrži ogromnu količinu zanimljivih materijala koji će vam pomoći u postavljanju RBAC-a, pokazati zašto je dobar i kako zapravo živjeti s njim u proizvodnji.

Pokušat ću objasniti kako Tiller i RBAC rade. Tiller radi unutar klastera pod određenim računom usluge. Obično, ako RBAC nije konfiguriran, to će biti superkorisnik. U osnovnoj konfiguraciji, Tiller će biti admin. Zbog toga se često kaže da je Tiller SSH tunel do vašeg klastera. Zapravo, to je istina, tako da možete koristiti zasebni namjenski račun usluge umjesto zadanog računa usluge u gornjem dijagramu.

Kada inicijalizirate Helm i instalirate ga na poslužitelj po prvi put, možete postaviti račun usluge pomoću --service-account. To će vam omogućiti korištenje korisnika s minimalnim potrebnim skupom prava. Istina, morat ćete stvoriti takav "vijenac": Role i RoleBinding.

Nažalost, Helm to neće učiniti umjesto vas. Vi ili vaš administrator klastera Kubernetes morate unaprijed pripremiti skup uloga i povezivanja uloga za servisni račun kako biste prošli Helm.

Postavlja se pitanje – koja je razlika između Role i ClusterRole? Razlika je u tome što ClusterRole radi za sve prostore imena, za razliku od uobičajenih uloga i povezivanja uloga, koji rade samo za specijalizirani prostor imena. Možete konfigurirati pravila za cijeli klaster i sve prostore imena ili personalizirati za svaki prostor imena pojedinačno.

Vrijedno je spomenuti da RBAC rješava još jedan veliki problem. Mnogi se ljudi žale da Helm, nažalost, nije multitenancy (ne podržava multitenancy). Ako nekoliko timova konzumira klaster i koristi Helm, u osnovi je nemoguće postaviti politike i ograničiti im pristup unutar ovog klastera, jer postoji određeni servisni račun pod kojim se Helm pokreće, a iz njega stvara sve resurse u klasteru , što je ponekad vrlo nezgodno. To je istina - kao i sama binarna datoteka, kao i proces, Helm Tiller nema pojma višestanarstva.

Međutim, postoji sjajan način koji vam omogućuje pokretanje Tillera više puta u klasteru. S tim nema problema, Tiller se može pokrenuti u svakom imenskom prostoru. Dakle, možete koristiti RBAC, Kubeconfig kao kontekst i ograničiti pristup posebnom Helmu.

Izgledat će ovako.

Na primjer, postoje dva Kubeconfiga s kontekstom za različite timove (dva prostora imena): X Team za razvojni tim i administratorski klaster. Administratorski klaster ima vlastiti široki Tiller, koji se nalazi u prostoru imena sustava Kube, odgovarajući napredni servisni račun. I zasebni prostor imena za razvojni tim, oni će moći implementirati svoje usluge u poseban prostor imena.

Ovo je izvediv pristup, Tiller nije toliko gladan energije da bi to uvelike utjecalo na vaš proračun. Ovo je jedno od brzih rješenja.

Slobodno zasebno konfigurirajte Tiller i pružite Kubeconfigu kontekst za tim, za određenog programera ili za okruženje: Dev, Staging, Production (sumnjivo je da će sve biti na istom klasteru, međutim, to se može učiniti).

Nastavljajući našu priču, prijeđimo s RBAC-a i razgovarajmo o ConfigMaps.

ConfigMaps

Helm koristi ConfigMaps kao svoju pohranu podataka. Kada smo pričali o arhitekturi, nigdje nije postojala baza podataka koja bi pohranjivala informacije o izdanjima, konfiguracijama, vraćanjima itd. Za to se koristi ConfigMaps.

Glavni problem s ConfigMaps je poznat - u principu nisu sigurni; nemoguće je pohraniti osjetljive podatke. Govorimo o svemu što ne bi trebalo izlaziti iz okvira usluge, primjerice o lozinkama. Najprirodniji način za Helm trenutno je prebacivanje s korištenja ConfigMaps na tajne.

To se radi vrlo jednostavno. Zaobiđite postavku Tillera i navedite da će pohrana biti tajna. Zatim za svaku implementaciju nećete dobiti ConfigMap, već tajnu.

Mogli biste tvrditi da su tajne same po sebi čudan koncept i ne baš siguran. Međutim, vrijedno je razumjeti da to rade sami programeri Kubernetesa. Počevši od verzije 1.10, tj. Već neko vrijeme moguće je, barem u javnim oblacima, povezati ispravnu pohranu za pohranu tajni. Tim sada radi na načinima za bolju distribuciju pristupa tajnama, pojedinačnim podovima ili drugim entitetima.

Bolje je prenijeti Storage Helm na tajne, a one su zauzvrat osigurane centralno.

Naravno da će ostati ograničenje pohrane podataka od 1 MB. Helm ovdje koristi etcd kao distribuiranu pohranu za ConfigMaps. I tamo su smatrali da je to prikladan dio podataka za replikaciju, itd. Postoji zanimljiva rasprava o tome na Redditu, preporučujem da pronađete ovo smiješno štivo za vikend ili pročitate odlomak ovdje.

Grafikon Repos

Grafikoni su socijalno najugroženiji i mogu postati izvor "Čovjeka u sredini", pogotovo ako koristite standardno rješenje. Prije svega, govorimo o spremištima koja su izložena putem HTTP-a.

Svakako trebate izložiti Helm Repo preko HTTPS-a - ovo je najbolja opcija i jeftina je.

Napomena mehanizam potpisivanja grafikona. Tehnologija je vraški jednostavna. To je ista stvar koju koristite na GitHubu, običnom PGP stroju s javnim i privatnim ključevima. Postavite i budite sigurni, imajući potrebne ključeve i sve potpisujući, da je ovo stvarno vaša karta.

Osim toga, Helm klijent podržava TLS (ne u HTTP smislu na strani poslužitelja, već međusobnom TLS-u). Za komunikaciju možete koristiti ključeve poslužitelja i klijenta. Da budem iskren, ne koristim takav mehanizam jer ne volim međusobne potvrde. U osnovi, chartmuseum - glavni alat za postavljanje Helm Repo za Helm 2 - također podržava osnovnu autentizaciju. Možete koristiti osnovnu autentifikaciju ako je praktičnija i tiša.

Tu je i dodatak kormilo-gcs, koji vam omogućuje hostiranje Chart Reposa na Google Cloud Storageu. Ovo je vrlo zgodno, radi odlično i prilično je sigurno, jer su svi opisani mehanizmi reciklirani.

Ako omogućite HTTPS ili TLS, koristite mTLS i omogućite osnovnu autentifikaciju za dodatno smanjenje rizika, dobit ćete siguran komunikacijski kanal s Helm CLI i Chart Repo.

gRPC API

Sljedeći korak je vrlo važan - osigurati Tiller koji se nalazi u klasteru i s jedne je strane poslužitelj, s druge strane sam pristupa drugim komponentama i pokušava se pretvarati da je netko.

Kao što sam već rekao, Tiller je servis koji izlaže gRPC, Helm klijent do njega dolazi preko gRPC-a. Prema zadanim postavkama, naravno, TLS je onemogućen. Zašto je to učinjeno je diskutabilno pitanje, čini mi se da se pojednostavi postavljanje u startu.

Za proizvodnju, pa čak i postavljanje, preporučujem da omogućite TLS na gRPC-u.

Po mom mišljenju, za razliku od mTLS-a za grafikone, ovo je ovdje prikladno i radi se vrlo jednostavno - generirajte PQI infrastrukturu, kreirajte certifikat, pokrenite Tiller, prenesite certifikat tijekom inicijalizacije. Nakon toga možete izvršiti sve Helm naredbe, predstavljajući se s generiranim certifikatom i privatnim ključem.

Na taj način ćete se zaštititi od svih zahtjeva Tilleru izvan klastera.

Dakle, osigurali smo kanal povezivanja s Tillerom, već smo razgovarali o RBAC-u i prilagodili prava Kubernetes apiservera, smanjujući domenu s kojom može komunicirati.

Zaštićena kaciga

Pogledajmo konačni dijagram. To je ista arhitektura s istim strelicama.

Sve veze sada se mogu sigurno nacrtati zelenom bojom:

• za Chart Repo koristimo TLS ili mTLS i osnovnu autorizaciju;
• mTLS za Tiller, a izložen je kao gRPC usluga s TLS-om, koristimo certifikate;
• klaster koristi poseban račun usluge s Role i RoleBinding. 

Klaster smo značajno osigurali, ali je netko pametan rekao:

“Može postojati samo jedno apsolutno sigurno rješenje – ugašeno računalo koje se nalazi u betonskoj kutiji i čuvaju ga vojnici.”

Postoje različiti načini manipuliranja podacima i pronalaženja novih vektora napada. Međutim, uvjeren sam da će ove preporuke postići osnovni industrijski standard za sigurnost.

bonus

Ovaj dio nije izravno povezan sa sigurnošću, ali će također biti koristan. Pokazat ću vam neke zanimljive stvari o kojima malo ljudi zna. Na primjer, kako pretraživati ​​karte - službene i neslužbene.

U spremištu github.com/helm/charts Sada postoji oko 300 karata i dva toka: stabilan i inkubator. Svatko tko doprinosi dobro zna koliko je teško doći iz inkubatora u štalu, a kako je lako izletjeti iz štale. Međutim, ovo nije najbolji alat za traženje karata za Prometheus i što god želite, iz jednog jednostavnog razloga - to nije portal na kojem možete zgodno pretraživati ​​pakete.

Ali postoji usluga glavčina.helm.sh, što olakšava pronalaženje grafikona. Što je najvažnije, postoji mnogo više vanjskih spremišta i gotovo 800 dostupnih privjesaka. Osim toga, možete povezati svoje spremište ako iz nekog razloga ne želite slati svoje grafikone u stable.

Isprobajte hub.helm.sh i razvijajmo ga zajedno. Ova je usluga dio projekta Helm, a možete čak i doprinijeti njenom korisničkom sučelju ako ste front-end programer i samo želite poboljšati izgled.

Također bih želio skrenuti vašu pozornost na Open Service Broker API integracija. Zvuči glomazno i ​​nejasno, ali rješava probleme s kojima se svi susreću. Dopustite mi da objasnim na jednostavnom primjeru.

Postoji Kubernetes klaster u kojem želimo pokrenuti klasičnu aplikaciju – WordPress. Općenito, baza podataka je potrebna za punu funkcionalnost. Postoji mnogo različitih rješenja, na primjer, možete pokrenuti vlastitu uslugu s punim statusom. Ovo nije baš zgodno, ali mnogi ljudi to rade.

Drugi, poput nas u Chainstacku, koriste upravljane baze podataka kao što su MySQL ili PostgreSQL za svoje poslužitelje. Zato su naše baze podataka smještene negdje u oblaku.

Ali javlja se problem: moramo povezati našu uslugu s bazom podataka, stvoriti aromu baze podataka, prenijeti vjerodajnicu i nekako upravljati njome. Sve to obično ručno radi administrator sustava ili programer. A nema problema kad ima malo prijava. Kad ih ima puno, treba kombajn. Postoji takav kombajn - to je Service Broker. Omogućuje vam korištenje posebnog dodatka za klaster javnog oblaka i naručivanje resursa od pružatelja putem brokera, kao da je to API. Da biste to učinili, možete koristiti izvorne Kubernetes alate.

Vrlo je jednostavno. Možete postavljati upite, na primjer, za Managed MySQL u Azureu s osnovnim slojem (ovo se može konfigurirati). Korištenjem Azure API-ja, baza podataka će biti kreirana i pripremljena za korištenje. Ne trebate se miješati u ovo, dodatak je odgovoran za to. Na primjer, OSBA (Azure plugin) će vratiti vjerodajnicu usluzi i proslijediti je Helmu. Moći ćete koristiti WordPress s MySQL-om u oblaku, uopće se nećete baviti upravljanim bazama podataka i nećete brinuti o uslugama s punim stanjem unutar njih.

Možemo reći da Helm djeluje kao ljepilo koje vam s jedne strane omogućuje implementaciju usluga, a s druge strane troši resurse pružatelja usluga oblaka.

Možete napisati vlastiti dodatak i koristiti cijelu ovu priču on-premise. Tada ćete jednostavno imati vlastiti dodatak za korporativnog pružatelja usluge Cloud. Preporučam da isprobate ovaj pristup, posebno ako imate veliki opseg i želite brzo implementirati razvojne programere, staging ili cijelu infrastrukturu za značajku. To će olakšati život vašim operacijama ili DevOps-u.

Drugi nalaz koji sam već spomenuo je helm-gcs dodatak, koji vam omogućuje korištenje Google-buckets (pohrana objekata) za pohranjivanje Helm karata.

Trebate samo četiri naredbe da ga počnete koristiti:

1. instalirajte dodatak;
2. inicirati ga;
3. postavite put do spremnika koji se nalazi u gcp-u;
4. objaviti grafikone na standardni način.

Ljepota je u tome što će se za autorizaciju koristiti izvorna gcp metoda. Možete koristiti račun usluge, račun razvojnog programera, što god želite. Vrlo je praktičan i ne košta ništa za rad. Ako vi, poput mene, promičete filozofiju bez opsa, onda će to biti vrlo zgodno, posebno za male timove.

Alternative

Helm nije jedino rješenje za upravljanje uslugama. Puno je pitanja o tome, vjerojatno se zato tako brzo pojavila treća verzija. Naravno da postoje alternative.

To mogu biti specijalizirana rješenja, na primjer, Ksonnet ili Metaparticle. Možete koristiti svoje klasične alate za upravljanje infrastrukturom (Ansible, Terraform, Chef itd.) za iste svrhe o kojima sam govorio.

Napokon postoji rješenje Okvir operatora, čija popularnost raste.

Operator Framework najbolja je Helm alternativa koju treba razmotriti.

Izvorniji je za CNCF i Kubernetes, ali je prepreka ulasku mnogo veća, trebate više programirati i manje opisivati ​​manifeste.

Postoje razni dodaci, kao što su Draft, Scaffold. Čine život puno lakšim, na primjer, pojednostavljuju ciklus slanja i pokretanja Helma programerima za implementaciju testnog okruženja. Ja bih ih nazvao osnaživačima.

Evo vizualnog grafikona gdje se sve nalazi.

Na x-osi je razina vaše osobne kontrole nad onim što se događa, na y-osi je razina izvornosti Kubernetesa. Helm verzija 2 nalazi se negdje u sredini. U verziji 3, ne enormno, ali i kontrola i razina izvornosti su poboljšani. Rješenja na razini Ksonneta još uvijek su inferiorna čak iu odnosu na Helm 2. Međutim, vrijedi ih pogledati da biste saznali što još postoji na ovom svijetu. Naravno, vaš upravitelj konfiguracije bit će pod vašom kontrolom, ali on apsolutno nije izvorni za Kubernetes.

Operator Framework je apsolutno izvorni za Kubernetes i omogućuje vam da njime upravljate mnogo elegantnije i skrupuloznije (ali zapamtite početnu razinu). Umjesto toga, ovo je prikladno za specijaliziranu primjenu i stvaranje upravljanja za nju, a ne masovni kombajn za pakiranje ogromnog broja aplikacija pomoću Helma.

Ekstenderi jednostavno malo poboljšavaju kontrolu, nadopunjuju tijek rada ili skraćuju kutove na CI/CD cjevovodima.

Budućnost Helma

Dobra vijest je da dolazi Helm 3. Alfa verzija Helma 3.0.0-alpha.2 je već objavljena, možete je isprobati. Prilično je stabilan, ali funkcionalnost je još uvijek ograničena.

Zašto vam treba Helm 3? Prije svega, ovo je priča o nestanak Tillera, kao komponenta. Ovo je, kao što već razumijete, veliki korak naprijed, jer je sa stajališta sigurnosti arhitekture sve pojednostavljeno.

Kad je Helm 2 stvoren, što je bilo otprilike u vrijeme Kubernetesa 1.8 ili čak i ranije, mnogi su koncepti bili nezreli. Primjerice, sada se aktivno provodi CRD koncept, a Helm će koristiti CRDza skladištenje struktura. Moći će se koristiti samo klijent, a ne održavati poslužiteljski dio. U skladu s tim, koristite izvorne Kubernetes naredbe za rad sa strukturama i resursima. Ovo je ogroman korak naprijed.

Pojavit će se podrška za izvorna OCI spremišta (Inicijativa za otvoreni kontejner). Ovo je golema inicijativa, a Helm je zainteresiran prije svega kako bi postavio svoje karte. Dolazi do toga da, primjerice, Docker Hub podržava mnoge OCI standarde. Ne nagađam, ali možda će vam pružatelji klasičnih Docker repozitorija početi davati priliku da udomite svoje Helm karte.

Za mene je kontroverzna priča Lua podrška, kao mehanizam za izradu predložaka za pisanje skripti. Nisam veliki obožavatelj Lue, ali ovo bi bila potpuno opcionalna značajka. Provjerio sam ovo 3 puta - korištenje Lua neće biti potrebno. Stoga, oni koji žele moći koristiti Lua, oni koji vole Go, pridružite se našem ogromnom kampu i koristite go-tmpl za ovo.

Konačno, ono što mi je definitivno nedostajalo je nastanak sheme i provjera valjanosti tipa podataka. Neće više biti problema s int ili stringom, nema potrebe stavljati nulu u dvostruke navodnike. Pojavit će se JSONS shema koja će vam omogućiti da to eksplicitno opišete za vrijednosti.

Bit će uvelike prerađen model vođen događajima. Već je konceptualno opisano. Pogledajte Helm 3 granu i vidjet ćete koliko je događaja i hookova i drugih stvari dodano, što će uvelike pojednostaviti, a s druge strane dodati kontrolu nad deployment procesima i reakcijama na njih.

Helm 3 će biti jednostavniji, sigurniji i zabavniji, ne zato što nam se ne sviđa Helm 2, već zato što Kubernetes postaje sve napredniji. U skladu s tim, Helm može koristiti razvoj Kubernetesa i na njemu stvoriti izvrsne upravitelje za Kubernetes.

Još jedna dobra vijest je da DevOpsConf Alexander Khayorov će vam reći, mogu li kontejneri biti sigurni? Podsjetimo, u Moskvi će se održati konferencija o integraciji procesa razvoja, testiranja i rada 30. rujna i 1. listopada. Još možete do 20. kolovoza podnijeti izvješće i recite nam svoje iskustvo s rješenjem jedan od mnogih zadaci DevOps pristupa.

Pratite kontrolne točke konferencije i vijesti na bilten и telegram kanal.

Izvor: www.habr.com