Predstavljamo Helm 3

Bilješka. prev.: 16. svibnja ove godine obilježava se značajna prekretnica u razvoju upravitelja paketa za Kubernetes - Helm. Na današnji dan predstavljeno je prvo alfa izdanje buduće glavne verzije projekta - 3.0. Njegovo izdanje donijet će značajne i dugo očekivane promjene u Helmu, u koje mnogi u Kubernetes zajednici polažu velike nade. Mi smo jedni od njih, budući da aktivno koristimo Helm za implementaciju aplikacija: integrirali smo ga u naš alat za implementaciju CI/CD werf a s vremena na vrijeme dajemo svoj doprinos razvoju uzvodno. Ovaj prijevod kombinira 7 bilješki sa službenog Helm bloga, koje su posvećene prvom alfa izdanju Helma 3 i govore o povijesti projekta i glavnim značajkama Helma 3. Njihov autor je Matt “bacongobbler” Fisher, zaposlenik Microsofta i jedan od ključnih održavatelja Helma.

Dana 15. listopada 2015. rođen je projekt sada poznat kao Helm. Samo godinu dana nakon osnutka, Helm zajednica pridružila se Kubernetesu, dok je aktivno radila na Helmu 2. Helm je u lipnju 2018. pridružio se CNCF-u kao razvojni (inkubacijski) projekt. Brzo naprijed u sadašnjost i prvo alfa izdanje novog Helma 3 je na putu. (ovo izdanje se već dogodio sredinom svibnja - cca. prev.).

U ovom ću članku govoriti o tome gdje je sve počelo, kako smo došli do ovoga gdje smo danas, predstavit ću neke od jedinstvenih značajki dostupnih u prvom alfa izdanju Helma 3 i objasniti kako planiramo ići naprijed.

Sažetak:

• povijest nastanka Helma;
• nježan oproštaj s Tillerom;
• spremišta grafikona;
• upravljanje izdanjem;
• promjene u ovisnostima grafikona;
• knjižnične karte;
• Što je sljedeće?

Povijest Helma

Rođenje

Helm 1 je započeo kao Open Source projekt koji je kreirao Deis. Bili smo mali startup apsorbiran Microsoft je u proljeće 2017. Naš drugi Open Source projekt, također nazvan Deis, imao je alat deisctl, koji je (između ostalog) korišten za instaliranje i rad platforme Deis u Grozd flote. U to je vrijeme Fleet bila jedna od prvih platformi za orkestraciju kontejnera.

Sredinom 2015. odlučili smo promijeniti kurs i premjestili Deis (u to vrijeme preimenovan u Deis Workflow) iz Fleeta u Kubernetes. Jedan od prvih koji je redizajniran bio je alat za instalaciju. deisctl. Koristili smo ga za instaliranje i upravljanje Deis Workflowom u klasteru Fleet.

Helm 1 je nastao po uzoru na poznate upravitelje paketima kao što su Homebrew, apt i yum. Njegov glavni cilj bio je pojednostaviti zadatke kao što su pakiranje i instaliranje aplikacija na Kubernetes. Helm je službeno predstavljen 2015. godine na KubeCon konferenciji u San Franciscu.

Naš prvi pokušaj s Helmom je uspio, ali nije bio bez ozbiljnih ograničenja. Uzeo je set Kubernetesovih manifesta, začinjenih generatorima kao uvodnim YAML blokovima (prednja stvar)*, i učitao rezultate u Kubernetes.

* Bilješka. prev.: Od prve verzije Helma, YAML sintaksa odabrana je za opisivanje Kubernetes resursa, a Jinja predlošci i Python skripte podržani su prilikom pisanja konfiguracija. Više o tome i općenito strukturi prve verzije Helma pisali smo u poglavlju “Kratka povijest Helma” ovaj materijal.

Na primjer, da biste zamijenili polje u YAML datoteci, morali ste dodati sljedeću konstrukciju u manifest:

#helm:generate sed -i -e s|ubuntu-debootstrap|fluffy-bunny| my/pod.yaml

Sjajno je što danas postoje predlošci, zar ne?

Iz mnogo razloga, ovaj rani instalacijski program za Kubernetes zahtijevao je tvrdo kodirani popis datoteka manifesta i izvršavao je samo mali, fiksni niz događaja. Bilo ga je toliko teško koristiti da je Deis Workflow R&D tim imao problema kada je pokušao prenijeti svoj proizvod na ovu platformu - međutim, sjeme ideje je već bilo posijano. Naš prvi pokušaj bio je sjajna prilika za učenje: shvatili smo da smo doista strastveni u stvaranju pragmatičnih alata koji rješavaju svakodnevne probleme za naše korisnike.

Na temelju iskustva prošlih pogrešaka, počeli smo razvijati Helm 2.

Izrada kacige 2

Krajem 2015. kontaktirao nas je Google tim. Radili su na sličnom alatu za Kubernetes. Deployment Manager za Kubernetes bio je priključak postojećeg alata koji se koristio za Google Cloud Platform. “Želimo li”, upitali su, “provesti nekoliko dana raspravljajući o sličnostima i razlikama?”

U siječnju 2016. timovi Helma i Deployment Managera sastali su se u Seattleu kako bi razmijenili ideje. Pregovori su završili ambicioznim planom: spojiti oba projekta u stvaranje Helma 2. Uz Deis i Google, dečki iz SkippBox (sada dio Bitnamija - pribl. prijevod), i počeli smo raditi na Helmu 2.

Željeli smo zadržati Helmovu jednostavnost korištenja, ali smo dodali sljedeće:

• predlošci grafikona za prilagodbu;
• upravljanje unutar klastera za timove;
• repozitorij grafikona svjetske klase;
• stabilan format paketa s opcijom potpisa;
• snažnu predanost semantičkoj verziji i održavanju kompatibilnosti unazad između verzija.

Kako bi se postigli ovi ciljevi, ekosustavu Helm dodan je drugi element. Ova komponenta unutar klastera zvala se Tiller i bila je odgovorna za instaliranje Helmovih karata i upravljanje njima.

Od izdanja Helm 2 2016., Kubernetes je dodao nekoliko velikih inovacija. Dodana kontrola pristupa temeljena na ulogama (RBAC), koji je na kraju zamijenio kontrolu pristupa temeljenu na atributima (ABAC). Uvedene su nove vrste resursa (u to vrijeme su implementacije još bile u beta verziji). Izmišljene su prilagođene definicije resursa (izvorno nazvane Resursi treće strane ili TPR). I što je najvažnije, pojavio se skup najboljih praksi.

Usred svih ovih promjena, Helm je nastavio vjerno služiti korisnicima Kubernetesa. Nakon tri godine i mnogo novih dodataka, bilo je jasno da je došlo vrijeme da se naprave značajne promjene u bazi koda kako bi se osiguralo da Helm može nastaviti zadovoljavati rastuće potrebe ekosustava koji se razvija.

Nježan oproštaj s Tillerom

Tijekom razvoja Helma 2, predstavili smo Tiller kao dio naše integracije s Googleovim upraviteljem implementacije. Tiller je odigrao važnu ulogu za timove koji rade unutar zajedničkog klastera: omogućio je različitim stručnjacima koji upravljaju infrastrukturom da komuniciraju s istim skupom izdanja.

Budući da je kontrola pristupa temeljena na ulogama (RBAC) bila omogućena prema zadanim postavkama u Kubernetesu 1.6, rad s Tillerom u proizvodnji postao je teži. Zbog ogromnog broja mogućih sigurnosnih pravila, naš je stav bio ponuditi permisivnu konfiguraciju prema zadanim postavkama. To je početnicima omogućilo eksperimentiranje s Helmom i Kubernetesom bez potrebe da prvo zaroni u sigurnosne postavke. Nažalost, ova konfiguracija dopuštenja mogla bi korisniku dati preširok raspon dopuštenja koja mu ne trebaju. DevOps i SRE inženjeri morali su naučiti dodatne operativne korake prilikom instaliranja Tillera u klaster s više stanara.

Nakon što smo saznali kako je zajednica koristila Helm u određenim situacijama, shvatili smo da se Tillerov sustav upravljanja izdanjima ne treba oslanjati na komponentu unutar klastera da bi održao stanje ili funkcionirao kao središnje središte za informacije o izdanju. Umjesto toga, mogli bismo jednostavno primati informacije s Kubernetes API poslužitelja, generirati grafikon na strani klijenta i pohraniti zapis o instalaciji u Kubernetes.

Tillerov glavni cilj mogao se postići bez Tillera, tako da je jedna od naših prvih odluka u vezi s Helmom 3 bila potpuno napustiti Tillera.

Odlaskom Tillera, Helmov sigurnosni model je radikalno pojednostavljen. Helm 3 sada podržava sve moderne metode sigurnosti, identiteta i autorizacije trenutnog Kubernetesa. Dopuštenja za kormilo određuju se pomoću kubeconfig datoteka. Administratori klastera mogu ograničiti korisnička prava na bilo koju razinu granularnosti. Izdanja se i dalje spremaju unutar klastera, a ostatak Helmove funkcionalnosti ostaje netaknut.

Spremišta grafikona

Na visokoj razini, repozitorij grafikona je mjesto gdje se grafikoni mogu pohraniti i dijeliti. Klijent Helm pakira i šalje grafikone u repozitorij. Jednostavno rečeno, repozitorij grafikona je primitivni HTTP poslužitelj s datotekom index.yaml i nekim pakiranim grafikonima.

Iako postoje neke prednosti API-ja Charts Repository koji ispunjava većinu osnovnih zahtjeva za pohranu, postoji i nekoliko nedostataka:

• Repozitoriji grafikona nisu kompatibilni s većinom sigurnosnih implementacija potrebnih u produkcijskom okruženju. Posjedovanje standardnog API-ja za autentifikaciju i autorizaciju iznimno je važno u proizvodnim scenarijima.
• Helmovi alati za utvrđivanje porijekla grafikona, koji se koriste za potpisivanje, provjeru integriteta i porijekla grafikona, izborni su dio procesa objavljivanja grafikona.
• U višekorisničkim scenarijima, isti grafikon može prenijeti drugi korisnik, udvostručavajući količinu prostora potrebnog za pohranjivanje istog sadržaja. Za rješavanje ovog problema razvijena su pametnija spremišta, ali ona nisu dio formalne specifikacije.
• Korištenje jedne indeksne datoteke za pretraživanje, pohranu metapodataka i dohvaćanje grafikona otežavalo je razvoj sigurnih višekorisničkih implementacija.

Projekt Docker distribucija (također poznat kao Docker Registry v2) nasljednik je Docker Registryja i u biti djeluje kao skup alata za pakiranje, otpremu, pohranu i isporuku Docker slika. Mnoge velike usluge u oblaku nude proizvode temeljene na distribuciji. Zahvaljujući ovoj povećanoj pažnji, projekt Distribucija je imao koristi od godina poboljšanja, najboljih sigurnosnih praksi i testiranja na terenu koji su ga učinili jednim od najuspješnijih neopjevanih heroja svijeta otvorenog koda.

Ali jeste li znali da je projekt distribucije dizajniran za distribuciju bilo kojeg oblika sadržaja, a ne samo slika spremnika?

Zahvaljujući naporima Inicijativa za otvoreni kontejner (ili OCI), Helm karte se mogu postaviti na bilo koju instancu Distribucije. Za sada je ovaj proces eksperimentalni. Podrška za prijavu i druge značajke potrebne za potpuni Helm 3 su u tijeku, ali smo uzbuđeni što učimo iz otkrića do kojih su OCI i distribucijski timovi došli tijekom godina. A kroz njihovo mentorstvo i vodstvo učimo kako je upravljati visoko dostupnom uslugom na velikom broju.

Dostupan je detaljniji opis nekih nadolazećih promjena u repozitoriju grafikona Helm по ссылке.

Upravljanje izdanjem

U Helmu 3, stanje aplikacije prati se unutar klastera pomoću para objekata:

• objekt izdanja - predstavlja instancu aplikacije;
• tajna verzije izdanja - predstavlja željeno stanje aplikacije u određenom trenutku (na primjer, izdavanje nove verzije).

poziv helm install stvara objekt izdanja i tajnu verzije izdanja. Poziv helm upgrade zahtijeva objekt izdanja (koji može promijeniti) i stvara novu tajnu verzije izdanja koja sadrži nove vrijednosti i pripremljeni manifest.

Objekt izdanja sadrži informacije o izdanju, gdje je izdanje specifična instalacija imenovanog grafikona i vrijednosti. Ovaj objekt opisuje metapodatke najviše razine o izdanju. Objekt izdanja postoji tijekom cijelog životnog ciklusa aplikacije i vlasnik je svih tajni verzije izdanja, kao i svih objekata koji su izravno kreirani Helmovim grafikonom.

Tajna verzije izdanja povezuje izdanje s nizom revizija (instalacija, ažuriranja, vraćanja, brisanje).

U Helmu 2, revizije su bile izuzetno dosljedne. Poziv helm install stvorena v1, naknadno ažuriranje (nadogradnja) - v2, i tako dalje. Izdanje i tajna verzija izdanja sažeti su u jedan objekt poznat kao revizija. Revizije su pohranjene u istom prostoru imena kao i Tiller, što je značilo da je svako izdanje bilo "globalno" u smislu prostora imena; kao rezultat, samo jedna instanca imena mogla se koristiti.

U Helmu 3, svako izdanje povezano je s jednom ili više tajni verzije izdanja. Objekt izdanja uvijek opisuje trenutno izdanje raspoređeno u Kubernetes. Svaka tajna verzije izdanja opisuje samo jednu verziju tog izdanja. Nadogradnja će, na primjer, stvoriti novu tajnu verzije izdanja i zatim promijeniti objekt izdanja da ukazuje na tu novu verziju. U slučaju vraćanja, možete koristiti tajne verzije prethodnog izdanja za vraćanje izdanja na prethodno stanje.

Nakon što je Tiller napušten, Helm 3 pohranjuje podatke o izdanju u istom prostoru imena kao i izdanje. Ova promjena vam omogućuje da instalirate grafikon s istim nazivom izdanja u drugom prostoru naziva, a podaci se spremaju između ažuriranja/ponovnog pokretanja klastera u itd. Na primjer, možete instalirati WordPress u prostor imena "foo", a zatim u prostor imena "bar", a oba izdanja mogu se nazvati "wordpress".

Promjene ovisnosti grafikona

Karte upakirane (upotrebom helm package) za korištenje s Helmom 2 može se instalirati s Helmom 3, međutim radni tijek razvoja grafikona je potpuno revidiran, tako da se moraju unijeti neke promjene da bi se nastavio razvoj grafikona s Helmom 3. Konkretno, promijenio se sustav upravljanja ovisnostima grafikona.

Sustav upravljanja ovisnostima grafikona prešao je s requirements.yaml и requirements.lock na Chart.yaml и Chart.lock. To znači da su grafikoni koji su koristili naredbu helm dependency, zahtijevaju određena podešavanja za rad u Helmu 3.

Pogledajmo primjer. Dodajmo ovisnost grafikonu u Helmu 2 i vidimo što se mijenja kada prijeđemo na Helm 3.

U Helmu 2 requirements.yaml izgledao ovako:

dependencies:
- name: mariadb
  version: 5.x.x
  repository: https://kubernetes-charts.storage.googleapis.com/
  condition: mariadb.enabled
  tags:
    - database

U Helmu 3, ista će se ovisnost odraziti na vaš Chart.yaml:

dependencies:
- name: mariadb
  version: 5.x.x
  repository: https://kubernetes-charts.storage.googleapis.com/
  condition: mariadb.enabled
  tags:
    - database

Karte se i dalje preuzimaju i stavljaju u imenik charts/, dakle podgrafikoni (podgrafikoni), koji leži u katalogu charts/, nastavit će s radom bez promjena.

Predstavljamo knjižnične grafikone

Helm 3 podržava klasu grafikona koji se nazivaju grafikoni knjižnice (tabela knjižnice). Ovaj grafikon koriste drugi grafikoni, ali sam ne stvara artefakte izdanja. Predlošci grafikona knjižnice mogu samo deklarirati elemente define. Ostali sadržaji se jednostavno ignoriraju. To korisnicima omogućuje ponovnu upotrebu i dijeljenje isječaka koda koji se mogu koristiti na više grafikona, čime se izbjegava dupliciranje i pridržava se načela SUHI.

Knjižnični dijagrami deklarirani su u odjeljku dependencies u spisu Chart.yaml. Instaliranje i upravljanje njima ne razlikuje se od drugih grafikona.

dependencies:
  - name: mylib
    version: 1.x.x
    repository: quay.io

Uzbuđeni smo zbog slučajeva korištenja koje će ova komponenta otvoriti za programere grafikona, kao i zbog najboljih praksi koje mogu proizaći iz grafikona knjižnice.

Što je sljedeće?

Helm 3.0.0-alpha.1 je temelj na kojem počinjemo graditi novu verziju Helma. U članku sam opisao neke zanimljive značajke Helma 3. Mnoge od njih još su u ranim fazama razvoja i to je normalno; Smisao alfa izdanja je testirati ideju, prikupiti povratne informacije od ranih korisnika i potvrditi naše pretpostavke.

Čim izađe alfa verzija (zapamtite da je ovo već se dogodilo - cca. prev.), počet ćemo prihvaćati zakrpe za Helm 3 od zajednice. Morate stvoriti snažnu osnovu koja omogućuje razvoj i usvajanje nove funkcionalnosti, te da se korisnici osjećaju uključeni u proces otvaranjem ulaznica i unošenjem popravaka.

Pokušao sam istaknuti neka od glavnih poboljšanja koja dolaze u Helm 3, ali ovaj popis nipošto nije iscrpan. Potpuni plan za Helm 3 uključuje značajke kao što su poboljšane strategije ažuriranja, dublja integracija s OCI registrima i korištenje JSON shema za provjeru vrijednosti grafikona. Također planiramo očistiti bazu kodova i ažurirati njezine dijelove koji su bili zanemareni zadnje tri godine.

Ako mislite da smo nešto propustili, voljeli bismo čuti vaše mišljenje!

Pridružite se raspravi na našem Slab kanali:

• #helm-users za pitanja i jednostavnu komunikaciju sa zajednicom;
• #helm-dev za raspravu o zahtjevima za povlačenjem, kodu i greškama.

Također možete razgovarati u našim tjednim javnim pozivima razvojnim programerima četvrtkom u 19:30 MSK. Sastanci su posvećeni raspravi o pitanjima na kojima rade ključni programeri i zajednica, kao i temama za raspravu tijekom tjedna. Svatko se može pridružiti i sudjelovati na sastanku. Link dostupan na Slack kanalu #helm-dev.

PS od prevoditelja

Pročitajte i na našem blogu:

• «Upravitelj paketa za Kubernetes - Helm: prošlost, sadašnjost, budućnost»;
• «Trezven pogled na Helm 2: “Ovo je to...”»;
• «Praktični uvod u upravitelj paketa za Kubernetes - Helm»;
• «Kubernetes savjeti i trikovi: prijenos resursa koji se izvode u klasteru na upravljanje Helmom 2»;
• «Vježbajte s dappom. Dio 2. Uvođenje Docker slika u Kubernetes pomoću Helma".

Izvor: www.habr.com