Predstavljamo Helm 3

Bilješka. transl.: 16. maj ove godine označava značajnu prekretnicu u razvoju paket menadžera za Kubernetes - Helm. Na današnji dan predstavljeno je prvo alfa izdanje buduće glavne verzije projekta - 3.0. Njegovo objavljivanje će donijeti značajne i dugo očekivane promjene u Helmu, u koje mnogi u Kubernetes zajednici polažu velike nade. Mi smo sami jedni od njih, jer aktivno koristimo Helm za implementaciju aplikacija: integrirali smo ga u naš alat za implementaciju CI/CD werf i s vremena na vrijeme dajemo svoj doprinos razvoju upstream. Ovaj prijevod kombinuje 7 bilješki sa službenog Helm bloga, koje su posvećene prvom alfa izdanju Helm 3 i govore o povijesti projekta i glavnim karakteristikama Helm 3. Njihov autor je Matt “bacongobbler” Fisher, zaposlenik Microsofta i jedan od ključnih održavatelja Helma.

15. oktobra 2015. rođen je projekat sada poznat kao Helm. Samo godinu dana nakon osnivanja, Helm zajednica se pridružila Kubernetesu, dok je aktivno radila na Helm 2. U junu 2018. Helm pridružio se CNCF-u kao razvojni (inkubacijski) projekat. Brzo naprijed u sadašnjost i prvo alfa izdanje novog Helm 3 je na putu. (ovo izdanje se već dogodilo sredinom maja - cca. prevod).

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

Rezime:

• istorija stvaranja Helma;
• nježni oproštaj od Tillera;
• spremišta grafikona;
• upravljanje izdavanjem;
• promjene u ovisnostima grafikona;
• bibliotečke karte;
• šta je sledeće?

Istorija Helma

Rođenje

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

Sredinom 2015. odlučili smo da promijenimo kurs i Deis (u to vrijeme preimenovan u Deis Workflow) iz Fleet-a u Kubernetes. Jedan od prvih koji je redizajniran bio je alat za instalaciju. deisctl. Koristili smo ga za instalaciju i upravljanje Deis Workflow-om u Fleet klasteru.

Helm 1 je kreiran po ugledu na poznate menadžere paketa kao što su Homebrew, apt i yum. Njegov glavni cilj bio je pojednostaviti zadatke kao što su pakovanje 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 Kubernetes manifesta, začinjenih generatorima kao uvodnim YAML blokovima (prednja stvar)* i učitao rezultate u Kubernetes.

* Bilješka. transl.: Od prve verzije Helma, YAML sintaksa je odabrana da opiše Kubernetes resurse, a Jinja predlošci i Python skripte su podržani prilikom pisanja konfiguracija. Više o tome i strukturi prve verzije Helma općenito pisali smo u poglavlju „Kratka povijest Helma“ ovog materijala.

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

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

Sjajno je što danas postoje šablonski motori, zar ne?

Iz mnogo razloga, ovaj rani instalater Kubernetesa zahtijevao je tvrdo kodiranu listu manifestnih datoteka i izvršavao je samo mali, fiksni niz događaja. Bio je toliko težak za korištenje da je tim za istraživanje i razvoj Deis Workflow imao poteškoća kada je pokušao prenijeti svoj proizvod na ovu platformu - međutim, sjeme ideje je već bilo posijano. Naš prvi pokušaj bio je odlična prilika za učenje: shvatili smo da smo zaista strastveni u stvaranju pragmatičnih alata koji rješavaju svakodnevne probleme za naše korisnike.

Na osnovu iskustva prošlih grešaka, počeli smo razvijati Helm 2.

Izrada kormila 2

Krajem 2015. godine kontaktirao nas je Google tim. Radili su na sličnom alatu za Kubernetes. Deployment Manager za Kubernetes bio je port postojećeg alata koji se koristio za Google Cloud Platform. „Hoćemo li“, upitali su, „da provedemo nekoliko dana raspravljajući o sličnostima i razlikama?“

U januaru 2016. timovi Helm i Deployment Manager sastali su se u Sijetlu kako bi razmijenili ideje. Pregovori su završeni ambicioznim planom: spojiti oba projekta za stvaranje Helm 2. Uz Deis i Google, momci iz SkippBox (sada dio Bitnamija - pribl. prev.), i počeli smo raditi na Helmu 2.

Htjeli smo zadržati Helmovu jednostavnost korištenja, ali dodamo sljedeće:

• predlošci grafikona za prilagođavanje;
• upravljanje unutar klastera za timove;
• repozitorijum grafikona svjetske klase;
• stabilan format paketa sa opcijom potpisa;
• snažna posvećenost semantičkom verzioniranju i održavanju kompatibilnosti unatrag između verzija.

Da bi se postigli ovi ciljevi, drugi element je dodat ekosistemu Helm. Ova komponenta unutar klastera zvala se Tiller i bila je odgovorna za instaliranje Helmovih grafikona i upravljanje njima.

Od izdavanja Helm 2 2016. godine, Kubernetes je dodao nekoliko velikih inovacija. Dodata kontrola pristupa zasnovana na ulogama (RBAC), koji je na kraju zamijenio kontrolu pristupa zasnovanu na atributima (ABAC). Uvedeni su novi tipovi resursa (Deployments je u to vrijeme još uvijek bio u beta verziji). Izmišljene su prilagođene definicije resursa (prvobitno nazvane resursi trećih strana ili TPR). I što je najvažnije, pojavio se niz najboljih praksi.

Usred svih ovih promjena, Helm je nastavio vjerno služiti Kubernetes korisnicima. Nakon tri godine i mnogih novih dodataka, bilo je jasno da je vrijeme za značajne promjene u bazi koda kako bi se osiguralo da Helm nastavi da zadovoljava rastuće potrebe ekosistema koji se razvija.

Nežni oproštaj od Tillera

Tokom razvoja Helm 2, predstavili smo Tiller kao dio naše integracije sa Google-ovim Deployment Managerom. Tiller je igrao važnu ulogu za timove koji rade unutar zajedničkog klastera: omogućio je različitim stručnjacima koji upravljaju infrastrukturom da komuniciraju sa istim skupom izdanja.

Pošto je kontrola pristupa zasnovana na ulogama (RBAC) podrazumevano omogućena u Kubernetes 1.6, rad sa Tiller-om u produkciji postao je teži. Zbog velikog broja mogućih sigurnosnih politika, naša pozicija je bila da ponudimo dozvoljenu konfiguraciju prema zadanim postavkama. Ovo je omogućilo novajlijama da eksperimentišu sa Helmom i Kubernetesom bez potrebe da prvo zarone u bezbednosne postavke. Nažalost, ova konfiguracija dozvola može korisniku dati preširok raspon dozvola koje mu nisu bile potrebne. Inženjeri DevOps-a i SRE-a morali su naučiti dodatne operativne korake prilikom instaliranja Tiller-a u klaster s više korisnika.

Nakon što smo saznali kako je zajednica koristila Helm u specifičnim situacijama, shvatili smo da Tillerov sistem upravljanja izdanjima nije morao da se oslanja na komponentu unutar klastera da bi održao stanje ili funkcionisao kao centralno čvorište za informacije o izdanju. Umjesto toga, mogli bismo jednostavno primiti informacije od Kubernetes API servera, generirati grafikon na strani klijenta i pohraniti zapis o instalaciji u Kubernetes.

Tillerov glavni cilj mogao je biti ostvaren i bez Tillera, pa je jedna od naših prvih odluka u vezi s Helmom 3 bila potpuno napuštanje Tillera.

Nakon što je Tiller otišao, Helmov sigurnosni model je radikalno pojednostavljen. Helm 3 sada podržava sve moderne metode sigurnosti, identiteta i autorizacije trenutnog Kubernetesa. Dozvole za upravljanje se određuju korištenjem kubeconfig fajl. Administratori klastera mogu ograničiti korisnička prava na bilo koji nivo granularnosti. Izdanja se i dalje čuvaju unutar klastera, a ostatak Helmove funkcionalnosti ostaje netaknut.

Spremišta grafikona

Na visokom nivou, spremište grafikona je mjesto gdje se grafikoni mogu skladištiti i dijeliti. Helm klijent pakuje i šalje grafikone u spremište. Jednostavno rečeno, spremište grafikona je primitivni HTTP server sa index.yaml datotekom i nekim upakovanim grafikonima.

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

• Spremišta grafikona nisu kompatibilna sa većinom sigurnosnih implementacija potrebnih u proizvodnom okruženju. Posjedovanje standardnog API-ja za autentifikaciju i autorizaciju je izuzetno važno u scenarijima proizvodnje.
• Helmovi alati za porijeklo grafikona, koji se koriste za potpisivanje, provjeru integriteta i porijekla grafikona, su neobavezni dio procesa objavljivanja grafikona.
• U scenarijima s više korisnika, isti grafikon može učitati drugi korisnik, udvostručujuć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.
• Upotreba jedne indeksne datoteke za pretraživanje, pohranjivanje metapodataka i dohvaćanje grafikona otežava razvoj sigurnih implementacija za više korisnika.

Projekat Docker distribucija (također poznat kao Docker Registry v2) je nasljednik Docker Registry-a i u suštini djeluje kao skup alata za pakovanje, isporuku, skladištenje i isporuku Docker slika. Mnoge velike usluge u oblaku nude proizvode zasnovane na distribuciji. Zahvaljujući ovoj povećanoj pažnji, projekat Distribution 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 Distribution Project dizajniran da distribuira bilo koji oblik sadržaja, a ne samo slike kontejnera?

Zahvaljujući trudu Inicijativa za otvoreni kontejner (ili OCI), Helm karte se mogu postaviti na bilo koju instancu distribucije. Za sada je ovaj proces eksperimentalan. Podrška za prijavu i druge funkcije potrebne za potpuni Helm 3 su u toku, ali mi smo uzbuđeni što učimo iz otkrića do kojih su OCI i distribucijski timovi došli tokom godina. A kroz njihovo mentorstvo i vodstvo učimo kako je to raditi s visoko dostupnom uslugom u velikom obimu.

Dostupan je detaljniji opis nekih nadolazećih promjena repozitorija Helmovih grafikona link.

Upravljanje izdanjima

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

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

Call helm install kreira objekt izdanja i tajnu verzije izdanja. Zovi helm upgrade zahtijeva objekt izdanja (koji može promijeniti) i kreira novu tajnu verzije izdanja koja sadrži nove vrijednosti i pripremljen manifest.

Objekt Release sadrži informacije o izdanju, gdje je izdanje specifična instalacija imenovanog grafikona i vrijednosti. Ovaj objekt opisuje metapodatke najviše razine o izdanju. Objekat izdanja opstaje kroz životni ciklus aplikacije i vlasnik je svih tajni izdanja, kao i svih objekata koji su direktno kreirani pomoću Helm grafikona.

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

U Helm 2, revizije su bile izuzetno konzistentne. Zovi helm install kreiran v1, naknadno ažuriranje (nadogradnja) - v2, i tako dalje. Tajna izdanja i izdanja verzije su skupljene u jedan objekat poznat kao revizija. Revizije su pohranjene u istom imenskom prostoru kao Tiller, što je značilo da je svako izdanje bilo "globalno" u smislu prostora imena; kao rezultat, može se koristiti samo jedna instanca imena.

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

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

Promjene ovisnosti grafikona

Karte su upakovane (koristeći helm package) za upotrebu sa Helmom 2 može se instalirati sa Helmom 3, međutim tok rada razvoja grafikona je u potpunosti revidiran, tako da se moraju napraviti neke promjene da bi se nastavio razvoj grafikona sa Helmom 3. Konkretno, sistem upravljanja ovisnostima grafikona se promijenio.

Sistem upravljanja zavisnošću grafikona je prešao sa requirements.yaml и requirements.lock na Chart.yaml и Chart.lock. To znači da su grafikoni koji su koristili naredbu helm dependency, zahtijevaju neke postavke za rad u Helm 3.

Pogledajmo primjer. Hajde da dodamo zavisnost grafikonu u Helm 2 i vidimo šta se menja kada pređemo na Helm 3.

U Helm 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 Helm-u 3, ista zavisnost će se 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 direktorij charts/, dakle podgrafikoni (podgrafikoni), leži u katalogu charts/, nastavit će sa radom bez promjena.

Predstavljamo bibliotečke karte

Helm 3 podržava klasu grafikona koja se zove bibliotečki grafikoni (bibliotečka karta). Ovaj grafikon koriste druge karte, ali ne stvara nikakve artefakte izdanja sam po sebi. Predlošci bibliotečkog grafikona mogu samo deklarirati elemente define. Ostali sadržaji se jednostavno zanemaruju. Ovo omogućava korisnicima da ponovo koriste i dijele isječke koda koji se mogu koristiti na više grafikona, čime se izbjegava dupliciranje i pridržavanje principa DRY.

Bibliotečki grafikoni su deklarisani u sekciji dependencies u fajlu Chart.yaml. Instaliranje i upravljanje njima se ne razlikuje od ostalih grafikona.

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

Uzbuđeni smo zbog slučajeva upotrebe koje će ova komponenta otvoriti za programere grafikona, kao i zbog najboljih praksi koje mogu proizaći iz bibliotečkih grafikona.

Što je sljedeće?

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

Čim alfa verzija bude objavljena (zapamtite da je ovo već se dogodilo - cca. prevod), počet ćemo primati zakrpe za Helm 3 od zajednice. Morate stvoriti snažnu osnovu koja omogućava razvoj i usvajanje novih funkcionalnosti, kao i da se korisnici osjećaju uključenima u proces otvaranjem tiketa i ispravkama.

Pokušao sam da istaknem neka od glavnih poboljšanja koja dolaze u Helm 3, ali ova lista ni u kom slučaju nije konačna. Potpuna mapa puta za Helm 3 uključuje funkcije kao što su poboljšane strategije ažuriranja, dublja integracija sa OCI registrima i korištenje JSON šema za provjeru vrijednosti grafikona. Također planiramo očistiti kodnu bazu i ažurirati njene dijelove koji su bili zanemareni posljednje tri godine.

Ako se osjećate kao da smo nešto propustili, voljeli bismo čuti vaše mišljenje!

Pridružite se raspravi na našoj Slack kanali:

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

Također možete razgovarati u našim sedmičnim javnim pozivima za programere četvrtkom u 19:30 MSK. Sastanci su posvećeni raspravi o pitanjima na kojima rade ključni programeri i zajednica, kao i temama za diskusiju tokom sedmice. Svako se može pridružiti i učestvovati na sastanku. Link je dostupan na Slack kanalu #helm-dev.

PS od prevodioca

Pročitajte i na našem blogu:

• «Menadžer paketa za Kubernetes - Helm: prošlost, sadašnjost, budućnost»;
• «Trezan pogled na Helm 2: "Ovo je ono što je..."»;
• «Praktičan uvod u menadžer paketa za Kubernetes - Helm»;
• «Kubernetes savjeti i trikovi: prijenos resursa koji rade u klasteru na upravljanje Helm 2»;
• «Vježbajte uz dapp. Dio 2. Postavljanje Docker slika u Kubernetes koristeći Helm".

izvor: www.habr.com