Safety Helms

Suština priče o najpopularnijem menadžeru paketa za Kubernetes mogla bi se dočarati pomoću emotikona:

• kutija je Helm (ovo je najprikladnija stvar u najnovijem izdanju Emojija);
• brava - sigurnost;
• čovjek je rješenje problema.

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

• Ukratko, šta je Helm, ako niste znali ili zaboravili. Koje probleme rješava i gdje se nalazi u ekosistemu.
• Razmotrite arhitekturu Helma. Nijedan razgovor o sigurnosti i tome kako učiniti alat ili rješenje sigurnijim nije potpun bez razumijevanja arhitekture komponente.
• Hajde da razgovaramo o komponentama Helm-a.
• Najgoruće pitanje je budućnost - nova verzija Helm 3. 

Sve u ovom članku se odnosi na Helm 2. Ova verzija je trenutno u produkciji i najvjerovatnije je ona koju trenutno koristite, a ona je ona sa sigurnosnim rizicima.

O govorniku: Aleksandar Hajorov (allexx) se razvija već 10 godina, pomažući u poboljšanju sadržaja Moskva Python Conf++ i pridružio se komitetu Helm Summit. Sada radi u Chainstacku kao voditelj razvoja - ovo je hibrid između menadžera razvoja i osobe koja je odgovorna za isporuku konačnih izdanja. Odnosno, nalazi se na mjestu neprijateljstava, gdje se sve događa od stvaranja proizvoda do njegovog rada.

Chainstack je mali, aktivno rastući startup čija je misija omogućiti korisnicima da zaborave na infrastrukturu i složenost rada decentraliziranih aplikacija, razvojni tim se nalazi u Singapuru. Ne tražite od Chainstack-a da prodaje ili kupuje kriptovalute, već ponudite razgovor o poslovnim blokčein okvirima i oni će vam rado odgovoriti.

kormilo

Ovo je menadžer paketa (grafikona) za Kubernetes. Najjasniji i najsvestraniji način dovođenja aplikacija u Kubernetes klaster.

Ovdje se, naravno, radi o više strukturnom i industrijskom pristupu od kreiranja vlastitih YAML manifesta i pisanja malih uslužnih programa.

Helm je najbolje što je sada dostupno i popularno.

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

Još jedna važna činjenica je da je Helm veoma popularan projekat. Kada sam u januaru 2019. prvi put pomislio da razgovaram o tome kako da Helm bude siguran, projekat je imao hiljadu zvezdica na GitHubu. Do maja ih je bilo 12.

Mnogi ljudi su zainteresovani za Helm, pa čak i ako ga još ne koristite, poznavanje njegove sigurnosti će vam biti od koristi. Sigurnost je važna.

Helmov osnovni tim podržava Microsoft Azure, i kao takav je prilično stabilan projekat, za razliku od mnogih drugih. Izlazak Helm 3 Alpha 2 sredinom jula ukazuje da dosta ljudi radi na projektu, i da imaju želju i snagu da razvijaju i unapređuju Helm.

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

• Pakovanje aplikacije. Čak se i aplikacija kao što je "Hello, World" u WordPress-u već sastoji od nekoliko servisa, i oni žele da budu upakovani zajedno.
• Upravljanje složenošću koja dolazi s upravljanjem ovim aplikacijama.
• Životni ciklus koji se ne završava nakon što se aplikacija instalira ili implementira. I dalje živi, ​​treba ga ažurirati, a Helm u tome pomaže i pokušava donijeti prave mjere i politike za to.

Pakovanje raspoređeno na razumljiv način: postoje metapodaci u potpunosti u skladu sa radom konvencionalnog menadžera paketa za Linux, Windows ili MacOS. To jest, spremište, zavisnosti od raznih paketa, meta-informacije za aplikacije, podešavanja, konfiguracione karakteristike, informacije o indeksiranju, itd. Sve ovo Helm vam omogućava da dobijete i koristite za aplikacije.

Upravljanje kompleksnošću. Ako imate mnogo aplikacija istog tipa, tada je potrebna parametrizacija. Iz ovoga proizlaze predlošci, ali kako ne biste smislili svoj način kreiranja šablona, ​​možete koristiti ono što Helm nudi iz kutije.

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

Helm vam omogućava da:

• upravlja implementacijama, uvodi koncept konfiguracije i revizije;
• uspješno izvršiti rollback;
• koristiti kuke za različite događaje;
• dodajte dodatne provjere aplikacija i odgovorite na njihove rezultate.

Pored toga Kormilo ima "baterije" - ogroman broj ukusnih stvari koje se mogu uključiti u obliku dodataka, pojednostavljujući vaš život. Dodaci se mogu pisati nezavisno, prilično su izolirani i ne zahtijevaju koherentnu arhitekturu. Ako želite nešto implementirati, preporučujem da to učinite kao dodatak, a zatim ga eventualno uključite u uzvodno.

Helm se zasniva na tri glavna koncepta:

• Chart Repos — opis i niz parametrizacija mogućih za vaš manifest. 
• config —odnosno, vrijednosti koje treba primijeniti (tekst, numeričke vrijednosti, itd.).
• puštanje prikuplja dvije gornje komponente i zajedno se pretvaraju u Release. Izdanja mogu biti verzionirana, čime se postiže organizacija životnog ciklusa: mala u vrijeme instalacije i velika u vrijeme nadogradnje, nadogradnje ili vraćanja.

Arhitektura kormila

Dijagram konceptualno prikazuje Helmovu arhitekturu visokog nivoa.

Da vas podsjetim da je Helm nešto povezano sa Kubernetesom. Stoga ne možemo bez Kubernetes klastera (pravougaonika). Komponenta kube-apiserver je na masteru. Bez Helma, imamo Kubeconfig. Helm donosi jedan mali binarni program, ako ga tako možete nazvati, Helm CLI uslužni program, koji se instalira na računar, laptop, mainframe - bilo šta.

Ali ovo nije dovoljno. Helm ima serversku komponentu koja se zove Tiller. On predstavlja Helm unutar klastera, i aplikacija je unutar Kubernetes klastera kao i svaka druga.

Sljedeća komponenta Chart Repo je spremište sa grafikonima. Postoji službeni repozitorij, a može postojati i privatni repozitorij kompanije ili projekta.

Interakcija

Pogledajmo kako komponente arhitekture komuniciraju kada želimo da instaliramo aplikaciju koristeći Helm.

• Govorimo Helm install, pristupite spremištu (Chart Repo) i nabavite Helm grafikon.

• Uslužni program Helm (Helm CLI) stupa u interakciju sa Kubeconfigom kako bi otkrio na koji klaster treba da se odnosi. 
• Nakon što je primio ove informacije, uslužni program se već kao aplikacija obraća Tilleru, koji se nalazi u našem klasteru. 
• Tiller poziva Kube-apiserver da izvrši radnje u Kubernetesu, kreira neke objekte (servise, podove, replike, tajne, itd.).

Zatim ćemo zakomplikovati šemu kako bismo vidjeli vektor napada kojem Helm arhitektura u cjelini može biti izložena. A onda ćemo pokušati da je zaštitimo.

Vektor napada

Prva potencijalna slabost je privilegirani API-korisnik. Kao dio šeme, ovo je haker koji je dobio administratorski pristup Helm CLI.

Neprivilegirani korisnik API-ja takođe može predstavljati opasnost ako je negdje u blizini. Takav korisnik će imati drugačiji kontekst, na primjer, može se popraviti u jednom imenskom prostoru klastera u postavkama Kubeconfig.

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

Egzotična, ali sve popularnija, varijanta napada vezana je za Chart Repo. Tabela koju je napravio beskrupulozni autor može sadržavati nesigurni izvor, a vi ćete ga slijediti s vjerom. Ili može zamijeniti grafikon koji preuzmete iz službenog spremišta i, na primjer, stvoriti resurs u obliku politika i eskalirati pristup sebi.

Pokušajmo odbiti napade sa sve ove četiri strane i otkriti gdje postoje problemi u Helm arhitekturi, a gdje, možda, nisu.

Povećajmo šemu, dodajmo još elemenata, ali zadržimo sve osnovne komponente.

Helm CLI komunicira sa Chart Repo-om, komunicira sa Kubeconfigom, posao se prenosi u klaster na komponentu Tiller.

Tiller je predstavljen sa dva objekta:

• Tiller-deploy svc, koji otkriva određenu uslugu;
• Tiller-deploy pod (na dijagramu u jednoj instanci u jednoj replici), na kojoj se pokreće cijelo opterećenje, koje pristupa klasteru.

Za interakciju se koriste različiti protokoli i šeme. Sa sigurnosne tačke gledišta, najviše nas zanima:

• Mehanizam pomoću kojeg Helm CLI pristupa repou grafikona: šta je protokol, postoji li autentifikacija i šta se može učiniti u vezi s tim.
• Protokol kojim Helm CLI, koristeći kubectl, komunicira sa Tillerom. Ovo je RPC server instaliran unutar klastera.
• Sam Tiller je dostupan mikroservisima koji su u klasteru i komunicira sa Kube-apiserverom.

Razgovarajmo redom o svakoj od ovih oblasti.

RBAC

Beskorisno je govoriti o bilo kakvoj sigurnosti za Helm ili bilo koju drugu uslugu unutar klastera osim ako RBAC nije omogućen.

Čini se da ovo nije najnovija preporuka, ali siguran sam da mnogi još uvijek nisu omogućili RBAC čak ni u produkciji, jer je puno frke i ima dosta toga za konfigurirati. Međutim, pozivam vas da to učinite.

https://rbac.dev/ — pravnik sajta za RBAC. Tamo je sakupljena ogromna količina zanimljivog materijala koji će vam pomoći da postavite RBAC, pokažete zašto je dobar i kako s njim u principu živjeti u proizvodnji.

Pokušaću da objasnim kako rade Tiller i RBAC. Tiller radi unutar klastera pod određenim servisnim računom. Obično, ako RBAC nije konfigurisan, ovo će biti superkorisnik. U osnovnoj konfiguraciji, Tiller će biti administrator. Zbog toga se često kaže da je Tiller SSH tunel za vaš klaster. U stvari, to je slučaj, tako da možete koristiti poseban specijalizirani račun usluge umjesto zadanog računa usluge na dijagramu iznad.

Kada inicijalizirate Helm prvi put kada ga instalirate na server, možete podesiti servisni nalog sa --service-account. Ovo će vam omogućiti da koristite korisnika sa 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 Kubernetes klastera morate unaprijed pripremiti skup uloga, vezanja uloga za servisni račun kako biste mogli proći upravljanje.

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 regularnih Role i RoleBinding, koji rade samo za specijalizovane prostore imena. Možete konfigurirati politike za cijeli klaster i sve imenske prostore, kao i personalizirane za svaki prostor imena pojedinačno.

Vrijedi napomenuti da RBAC rješava još jedan veliki problem. Mnogi se žale da Helm, nažalost, nije multitenancy (ne podržava multitenancy). Ako više timova koristi klaster i koristi Helm, u principu je nemoguće postaviti politike i razgraničiti njihov pristup unutar ovog klastera, jer postoji određeni servisni nalog sa kojeg se pokreće Helm, a on stvara sve resurse u klasteru ispod. što je ponekad veoma neprijatno. To je tačno - kao sama binarna datoteka, kao proces, Helm Tiller nema pojma o višestanarstvu.

Međutim, postoji odličan način koji vam omogućava da pokrenete Tiller više puta u klasteru. Nema problema s tim, Tiller se može pokrenuti u svakom imenskom prostoru. Dakle, možete koristiti RBAC, Kubeconfig kao kontekst i ograničiti pristup posebnom Helm-u.

To će izgledati ovako.

Na primjer, postoje dva Kubeconfiga sa kontekstom za različite timove (dva prostora imena): X tim za razvojni tim i admin klaster. Admin klaster ima svoj široki Tiller, koji se nalazi u prostoru imena Kube-sistema, odnosno naprednom servisnom nalogu. I poseban imenski prostor za razvojni tim, oni će moći da implementiraju svoje usluge u poseban prostor imena.

Ovo je radni pristup, Tiller nije toliko proždrljiv da može u velikoj mjeri utjecati na vaš budžet. Ovo je jedno od brzih rješenja.

Slobodno konfigurišite Tiller zasebno 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, prebacimo se sa RBAC-a i pričamo o ConfigMaps-u.

ConfigMaps

Helm koristi ConfigMaps kao skladište 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 sa ConfigMaps-om je poznat - oni u principu nisu sigurni ne mogu pohraniti osjetljive podatke. Govorimo o svemu što ne bi trebalo da ide dalje od usluge, na primjer, lozinke. Najprirodniji način za Helm trenutno je da pređe sa korišćenja ConfigMaps na tajne.

Ovo se radi vrlo jednostavno. Zaobiđite postavku Tiller i odredite da će skladište biti tajne. Tada za svaku implementaciju nećete dobiti ConfigMap, već tajnu.

Mogli biste tvrditi da su same tajne čudan koncept i da nisu baš sigurni. Međutim, treba shvatiti da sami programeri Kubernetesa to rade. Počevši od verzije 1.10, tj. dugo vremena je moguće, barem u javnim oblacima, povezati ispravan prostor za skladištenje tajni. Sada tim radi na tome kako još bolje distribuirati pristup tajnama, pojedinačnim podovima ili drugim entitetima.

Bolje je prevesti Storage Helm u tajne, a zauzvrat ih osigurati centralno.

Naravno da će ostati Ograničenje skladištenja podataka od 1 MB. Helm ovdje koristi etcd kao distribuirano spremište za ConfigMaps. I tamo su smatrali da je ovo prikladan komad podataka za replikacije itd. Postoji zanimljiva rasprava na Redditu o tome, preporučujem da pronađete ovo smiješno štivo za vikend ili pročitate squeeze ovdje.

Chart Repos

Grafikoni su socijalno najranjiviji i mogu postati izvor "Čovjeka u sredini", posebno ako koristite dioničko rješenje. Prije svega, govorimo o spremištima koja su izložena preko HTTP-a.

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

Obrati paćnju mehanizam potpisivanja grafikona. Tehnologija je jednostavna za sramotu. To je isto kao i ono što koristite na GitHubu, normalnoj PGP mašini sa javnim i privatnim ključevima. Postavite i budite sigurni, da imate prave ključeve i da sve potpišete, da je ovo zaista vaš grafikon.

Osim toga, Helm klijent podržava TLS (ne u smislu HTTP-a sa strane servera, već uzajamnog TLS-a). Za komunikaciju možete koristiti serverske i klijentske ključeve. Da budem iskren, ne koristim takav mehanizam zbog nesklonosti prema međusobnim certifikatima. u osnovi, chartmuseum - glavni alat za postavljanje Helm Repo za Helm 2 - također podržava osnovnu auth. Možete koristiti osnovni auth ako je praktičniji i tiši.

Tu je i dodatak helm-gcs, što vam omogućava da ugostite Chart Repos na Google Cloud Storage. Ovo je prilično zgodno, odlično radi i dovoljno je sigurno, jer se koriste svi opisani mehanizmi.

Ako omogućite HTTPS ili TLS, koristite mTLS, omogućite osnovnu auth za dodatno smanjenje rizika, dobićete siguran kanal komunikacije za Helm CLI i Chart Repo.

gRPC API

Sljedeći korak je vrlo odgovoran - osigurati Tiller, koji se nalazi u klasteru i koji je s jedne strane server, s druge strane pristupa ostalim komponentama i pokušava se pretvarati da je neko.

Kao što sam rekao, Tiller je servis koji izlaže gRPC, Helm klijent dolazi do njega preko gRPC-a. Podrazumevano, naravno, TLS je onemogućen. Zašto se to radi je diskutabilno pitanje, čini mi se, da bi se u startu pojednostavilo podešavanje.

Za produkciju, pa čak i za 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 tokom inicijalizacije. Nakon toga, možete izvršiti sve Helm komande, pretvarajući se da ste generirani certifikat i privatni ključ.

Tako ćete se zaštititi od svih zahtjeva Tiller-u izvan klastera.

Dakle, osigurali smo kanal za vezu sa Tiller-om, već smo razgovarali o RBAC-u i prilagodili prava Kubernetes apiservera, smanjili domen sa kojim može da komunicira.

Protected Helm

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

Sve veze se sada mogu sigurno nacrtati zelenom bojom:

• za Chart Repo koristimo TLS ili mTLS i osnovni auth;
• mTLS za Tiller, a izložen je kao gRPC servis sa TLS-om, koristimo certifikate;
• klaster koristi poseban servisni nalog sa Role i RoleBindingom. 

Primetno smo obezbedili klaster, ali neko pametan je rekao:

“Može postojati samo jedno apsolutno sigurno rješenje – isključeni kompjuter, koji se nalazi u betonskoj kutiji i čuvaju ga vojnici.”

Postoje različiti načini za manipulaciju podacima i pronalaženje novih vektora napada. Međutim, uvjeren sam da će vam ove preporuke omogućiti da implementirate osnovni industrijski standard za sigurnost.

bonus

Ovaj dio nije direktno vezan za sigurnost, ali će također biti koristan. Pokazat ću vam neke zanimljive stvari za koje malo ljudi zna. Na primjer, kako pretraživati ​​karte - službene i nezvanične.

U spremištu github.com/helm/charts sada postoji oko 300 karata i dva toka: stabilan i inkubator. Svako ko da svoj doprinos dobro zna koliko je teško doći od inkubatora do štale, a koliko je lako izletjeti iz štale. Međutim, to nije najbolji alat za pronalaženje grafikona za Prometheus i šta god želite, iz jednog jednostavnog razloga - nije zgodan portal za traženje paketa.

Ali postoji usluga hub.helm.sh, s kojim je mnogo praktičnije pronaći grafikone. Što je najvažnije, postoji mnogo više vanjskih spremišta i gotovo 800 dostupnih privjesaka. Plus, možete povezati svoje spremište ako iz nekog razloga ne želite da pošaljete svoje grafikone u stabilnu.

Isprobajte hub.helm.sh i hajde da ga razvijemo zajedno. Ova usluga je u okviru Helm projekta i čak možete doprinijeti njenom korisničkom sučelju ako ste frontend i samo želite poboljšati izgled.

Takođe želim da vam skrenem pažnju Otvorite Service Broker API integraciju. Zvuči glomazno i ​​neshvatljivo, ali rješava probleme sa kojima se svi suočavaju. Dozvolite mi da objasnim na jednostavnom primjeru.

Imamo Kubernetes klaster u kojem želimo pokrenuti klasičnu WordPress aplikaciju. Za punu funkcionalnost je u pravilu potrebna baza podataka. Postoji mnogo različitih rješenja, na primjer, možete pokrenuti vlastitu uslugu punu stanja. Ovo nije baš zgodno, ali mnogi ljudi to rade.

Drugi, poput nas u Chainstacku, koriste upravljane baze podataka poput MySQL ili PostgreSQL za servere. Stoga se naše baze podataka nalaze negdje u oblaku.

Ali javlja se problem: moramo povezati naš servis sa bazom podataka, kreirati aromu baze podataka, prenijeti vjerodajnice i nekako upravljati njome. Sve ovo obično radi ručno administrator sistema ili programer. I nema problema kada ima malo aplikacija. Kada ih ima puno, potreban vam je kombajn. Postoji takav kombinat - to je Service Broker. Omogućava vam da koristite poseban dodatak za javni klaster u oblaku i naručite resurse od provajdera preko Brokera, kao da je API. Da biste to učinili, možete koristiti izvorne Kubernetes alate.

Vrlo je jednostavno. Možete zatražiti, na primjer, Managed MySQL na Azureu s osnovnim nivoom (ovo se može konfigurirati). Koristeći Azure API, baza podataka će biti kreirana i spremna za upotrebu. Ne morate se miješati u ovo, dodatak je odgovoran za to. Na primjer, OSBA (Azure dodatak) će vratiti vjerodajnice servisu, proslijediti ih Helmu. Moći ćete koristiti WordPress sa MySQL u oblaku, uopće se nećete baviti upravljanim bazama podataka i nećete brinuti o uslugama koje ispunjavaju stanje unutar njih.

Možemo reći da Helm djeluje kao ljepilo koje vam, s jedne strane, omogućava implementaciju usluga, a s druge strane troši resurse cloud provajdera.

Možete napisati svoj vlastiti dodatak i koristiti svu ovu historiju na licu mjesta. Tada ćete jednostavno imati vlastiti dodatak za korporativnog Cloud provajdera. Savjetujem vam da isprobate ovaj pristup, posebno ako imate veliku skalu i želite brzo implementirati dev, staging ili cijelu infrastrukturu za funkciju. Ovo će olakšati život vašim operacijama ili DevOps-u.

Još jedno otkriće koje sam već spomenuo je helm-gcs dodatak, koji vam omogućava da koristite Google-buckets (skladištenje objekata) za pohranjivanje Helm grafikona.

Potrebne su vam samo četiri komande da ga počnete koristiti:

1. instalirajte dodatak;
2. pokrenuti ga;
3. postavite putanju do bucketa, koji je u gcp-u;
4. objavite grafikone na standardni način.

Ljepota je u tome što će se koristiti nativni gcp metod za autorizaciju. Možete koristiti račun usluge, račun programera, bilo što. Veoma je zgodan i ne košta ništa za rad. Ako i vi, poput mene, promovirate filozofiju bez opsa, onda će ovo biti vrlo zgodno, posebno za male timove.

Alternative

Helm nije jedino rješenje za upravljanje uslugama. Mnogo je pitanja za njega, zbog čega se vjerovatno tako brzo pojavila treća verzija. Naravno da postoje alternative.

To mogu biti ili specijalizirana rješenja kao što su Ksonnet ili Metaparticle. Možete koristiti svoje klasične alate za upravljanje infrastrukturom (Ansible, Terraform, Chef, itd.) za iste svrhe koje sam spomenuo.

Konačno postoji rješenje okvir operaterakojoj raste popularnost.

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

Više je izvorni za CNCF i Kubernetes, ali je barijera za ulazak mnogo veća, trebate više kodirati, a manje opisivati ​​manifeste.

Postoje razni dodaci, kao što su Draft, Scaffold. Oni umnogome olakšavaju život, na primjer, pojednostavljuju ciklus za programere da pošalju i pokreću Helm za implementaciju testnog okruženja. Ja bih ih nazvao osnaživačima.

Evo vizuelnog grafikona gde se sve nalazi.

Apscisa je nivo vaše lične kontrole nad onim što se dešava, ordinata je nivo nativnosti Kubernetesa. Helm verzija 2 je negdje između. U verziji 3, nije ogroman, ali su poboljšani i kontrola i nivo nativnosti. Rešenja na nivou Ksonneta su i dalje inferiorna čak i u odnosu na Helm 2. Međutim, vredi ih pogledati da biste saznali šta još postoji na ovom svetu. Naravno, vaš menadžer konfiguracije će biti pod vašom kontrolom, ali apsolutno nije izvorni za Kubernetes.

Operator Framework je apsolutno izvorni za Kubernetes i omogućava vam da njime upravljate mnogo elegantnije i skrupuloznije (ali imajte na umu nivo unosa). Umjesto toga, pogodan je za specijaliziranu aplikaciju i kreiranje upravljanja za nju, a ne za masovni kombinat za pakovanje ogromnog broja aplikacija koristeći Helm.

Ekstenderi samo malo poboljšavaju kontrolu, dopunjuju radni tok ili smanjuju uglove na CI/CD cjevovodima.

Future Helms

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

Zašto vam treba Helm 3? Prije svega, ovo je priča o Tillerov nestanak, kao komponenta. Ovo je, kao što ste već shvatili, ogroman korak naprijed, jer je sa stanovišta sigurnosti arhitekture sve pojednostavljeno.

Kada je Helm 2 kreiran, što je bilo tokom Kubernetesa 1.8 dana ili čak ranije, mnogi koncepti su bili nezreli. Na primjer, koncept CRD se sada aktivno implementira, a Helm će koristite CRDza skladištenje struktura. Biće moguće koristiti samo klijent, a ne zadržati serverski dio. Shodno tome, koristite izvorne Kubernetes komande za rad sa strukturama i resursima. Ovo je ogroman korak naprijed.

Pojavit će se podrška za izvorna OCI spremišta (Inicijativa za otvorene kontejnere). Ovo je ogromna inicijativa, a Helm je zainteresiran prvenstveno da objavi svoje karte. Dolazi do toga da, na primjer, Docker Hub podržava mnoge OCI standarde. Ne nagađam, ali možda će vam klasični dobavljači Docker spremišta početi dopuštati da ugošćujete njihove Helm karte.

Za mene je kontroverzna priča Lua podrška, kao šablonski mehanizam za pisanje skripti. Nisam veliki obožavatelj Lue, ali će biti potpuno opciono. Provjerio sam to 3 puta - korištenje Lua-e neće biti potrebno. Dakle, ko želi da može koristiti Lua, ko voli Go, pridruži se našem ogromnom kampu i za to koristi go-tmpl.

Konačno, ono što mi je definitivno nedostajalo je izgled sheme i validacija tipova podataka. Neće više biti problema sa int ili stringom, nema potrebe za umotavanjem nule u dvostruke navodnike. Pojavit će se JSONS šema koja će vam omogućiti da to eksplicitno opišete za vrijednosti.

Biće jako prerađen model vođen događajima. To je već koncipirano. Pogledajte granu Helm 3 i vidjet ćete koliko je događaja i hookova i drugih stvari dodano, što uvelike pojednostavljuje, a s druge strane dodaje kontrolu nad procesima implementacije i reakcijama na njih.

Helm 3 će biti lakši, sigurniji i zanimljiviji, ne zato što nam se ne sviđa Helm 2, već zato što je Kubernetes sve napredniji. U skladu s tim, Helm može koristiti Kubernetes razvoj i kreirati odlične menadžere za Kubernetes na njemu.

Još jedna dobra vijest je to DevOpsConf Aleksandar Hajorov će reći mogu li kontejneri biti sigurni? Podsjetimo, konferencija o integraciji procesa razvoja, testiranja i rada bit će održana u Moskvi 30. septembra i 1. oktobra. Još možete do 20. avgusta predati izvještaj i reci o svom iskustvu jedan od mnogih zadaci DevOps pristupa.

Pratite kontrolne tačke konferencije i vijesti spisak adresa и telegram kanal.

izvor: www.habr.com