🥇Introducere în Helm 3

Nota traducătorului.: 16 mai a acestui an - un moment semnificativ în evoluția managerului de pachete pentru Kubernetes - Helm. În această zi a fost prezentat primul release alpha al viitoarei versiuni majore a proiectului - 3.0. Lansarea sa va aduce schimbări substanțiale și foarte așteptate în Helm, în care mulți din comunitatea Kubernetes își pun mari speranțe. Ne numărăm printre aceștia, deoarece folosim activ Helm pentru desfășurarea aplicațiilor: l-am integrat în instrumentul nostru pentru implementarea CI/CD. werf și ocazional contribuim la dezvoltarea upstream. Această traducere reunește 7 articole de pe blogul oficial Helm, care sunt legate de primul release alpha al Helm 3 și vorbesc despre povestea proiectului și funcționalitățile principale ale Helm 3. Autorul acestora este Matt „bacongobbler” Fisher, angajat Microsoft și unul dintre principalii mentori ai Helm.

15 octombrie 2015 a fost ziua în care a fost lansat proiectul, acum cunoscut drept Helm. La doar un an după înființare, comunitatea Helm s-a alăturat Kubernetes, lucrând activ la Helm 2. În iunie 2018, Helm a devenit parte integrantă a CNCF ca proiect în dezvoltare (incubating). Să ne revenim în prezent - și acum se apropie primul release alpha al noului Helm 3. (acest release deja a avut loc la mijlocul lunii mai - n.red.).

În acest material, voi povesti despre cum au început toate, cum am ajuns la această etapă, voi prezenta unele caracteristici unice disponibile în primul release alpha al Helm 3 și voi explica cum ne propunem să ne dezvoltăm în continuare.

Sumar:

povestea creării Helm;
o despărțire delicată de Tiller;
repozitoarele chart-urilor;
managementul release-urilor;
modificările în dependențele chart-urilor;
library charts;
ce urmează?

Povestea creării Helm

Nașterea

Helm 1 a început ca un proiect Open Source, creat de compania Deis. Eram o mică startup, care a fost absorbită de Microsoft în primăvara anului 2017. Un alt proiect Open Source al nostru, tot sub numele Deis, avea un instrument deisctl, care era folosit (printre altele) pentru instalarea și operarea platformei Deis în clusterele Fleet.Pe atunci, Fleet era una dintre primele platforme pentru orchestrarea containerelor.

La mijlocul anului 2015, am decis să schimbăm direcția și am migrat Deis (la acel moment redenumit în Deis Workflow) de la Fleet la Kubernetes. Unul dintre primele lucruri a fost revizuirea instrumentului de instalare. deisctlL-am folosit pentru instalarea și gestionarea Deis Workflow în clusterul Fleet.

Helm 1 a fost creat după modelul unor cunoscuți manageri de pachete, cum ar fi Homebrew, apt și yum. Scopul său principal a fost simplificarea sarcinilor precum ambalarea și instalarea aplicațiilor în Kubernetes. Helm a fost prezentat oficial în 2015 la conferința KubeCon din San Francisco.

Prima noastră încercare cu Helm a avut succes, însă nu fără limitări serioase. Acesta lua un set de manifesturi Kubernetes, condimentate cu generatoare ca blocuri YAML de intrare. (front-matter)*, și încarcă rezultatele în Kubernetes.

* Nota traducătorului.: Din prima versiune Helm, sintaxa YAML a fost aleasă pentru a descrie resursele Kubernetes, iar la redactarea configurațiilor au fost susținute șabloanele Jinja și scripturile Python. Mai multe despre aceasta și despre arhitectura primei versiuni Helm am scris în capitolul „Istoricul Helm” acest material.

De exemplu, pentru a înlocui un câmp în fișierul YAML, era necesar să adăugați următoarea construcție în manifest:

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

Unii ar spune că este grozav că astăzi există șabloane, nu-i așa?

Din multe motive, acest instalator timpuriu pentru Kubernetes necesita o listă rigoros definită de fișiere manifest și executa doar o mică secvență fixă de evenimente. A fost atât de greu de utilizat, încât echipa de R&D de la Deis Workflow a avut de suferit când au încercat să își transfere produsul pe această platformă — totuși, semințele ideii fuseseră deja plantate. Prima noastră încercare a devenit o oportunitate excelentă de învățare: ne-am dat seama că suntem cu adevărat dedicați creării de instrumente pragmatice care rezolvă problemele cotidiene ale utilizatorilor noștri.

Bazându-ne pe experiența greșelilor anterioare, am început dezvoltarea Helm 2.

Crearea Helm 2

La sfârșitul anului 2015, echipa Google ne-a contactat. Lucraseră la un instrument similar pentru Kubernetes. Deployment Manager pentru Kubernetes era un port al unui instrument existent care fusese utilizat pentru Platforma Google Cloud. „Nu vrem să discutăm câteva zile despre asemănările și diferențele?”, au întrebat ei.

În ianuarie 2016, echipele Helm și Deployment Manager s-au întâlnit în Seattle pentru a schimba idei. Negocierile s-au încheiat cu un plan ambițios: de a uni cele două proiecte pentru a crea Helm 2. Împreună cu Deis și Google, echipei de dezvoltatori i s-au alăturat băieții de la SkippBox (acum parte din Bitnami — nota trad.), și am început lucrările la Helm 2.

Am dorit să păstrăm simplitatea utilizării Helm, dar să adăugăm următoarele:

șabloane de charturi pentru personalizare;
gestionare intra-cluster pentru echipe;
un depozit de charturi de primă clasă;
un format stabil al pachetelor cu capacitate de semnare;
o fermă angajament față de versiunea semantică și păstrarea compatibilității între versiuni.

Pentru a atinge aceste obiective, în ecosistemul Helm a fost adăugat un al doilea element. Acest component intra-cluster a fost numit Tiller și se ocupa cu instalarea charturilor Helm și gestionarea acestora.

De la lansarea Helm 2 în 2016, Kubernetes a înregistrat câteva inovații semnificative. A apărut controlul accesului bazat pe roluri (RBAC), care, în cele din urmă, a înlocuit controlul accesului bazat pe atribute (ABAC). Au fost introduse noi tipuri de resurse (Deployments erau încă în faza beta la acea vreme). Au fost inventate Definițiile de Resurse Personalizate (initial numite Resurse Terțe sau TPR-uri). Și, cel mai important, a apărut un set de bune practici.

Pe fondul acestor schimbări, Helm a continuat să servească cu credință utilizatorii Kubernetes. După trei ani și multe adăugiri noi, a devenit clar că era timpul pentru modificări semnificative în baza de cod pentru ca Helm să poată satisface în continuare nevoile în creștere ale ecosistemului în dezvoltare.

O despărțire blândă de Tiller

În timpul dezvoltării Helm 2, am prezentat Tiller ca parte a integrării noastre cu Deployment Manager de la Google. Tiller a jucat un rol important pentru echipele care lucrau într-un cluster comun: le permitea diferiților specialiști, care exploatau infrastructura, să interacționeze cu același set de lansări.

De când controlul accesului pe bază de roluri (RBAC) a fost activat implicit în Kubernetes 1.6, utilizarea Tiller în medii de producție a devenit mai complicată. Datorită numărului mare de politici de securitate posibile, poziția noastră a fost să oferim o configurație permisivă în mod implicit. Acest lucru permitea utilizatorilor noi să experimenteze cu Helm și Kubernetes fără a fi necesar să se familiarizeze mai întâi cu setările de securitate. Din păcate, această configurație permisivă putea oferi utilizatorilor un spectru prea larg de permisiuni de care nu aveau nevoie. Inginerii DevOps și SRE au fost nevoiți să învețe pași suplimentari pentru a configura Tiller într-un cluster multi-utilizator.

În urma discuțiilor cu reprezentanții comunității despre cum utilizează Helm în situații specifice, am realizat că sistemul de gestionare a lansărilor Tiller nu trebuie să se bazeze pe un component intern al cluster-ului pentru a menține stările sau pentru a funcționa ca un hub central pentru informațiile despre lansare. În schimb, am putea pur și simplu să obținem informații direct de la API-ul Kubernetes, să generăm chart-uri pe partea clientului și să păstrăm înregistrările de instalare în Kubernetes.

Funcția de bază a lui Tiller putea fi realizată și fără Tiller, astfel că una dintre primele noastre decizii referitoare la Helm 3 a fost eliminarea completă a lui Tiller.

Odată cu eliminarea lui Tiller, modelul de securitate al Helm s-a simplificat radical. Helm 3 suportă acum toate metodele moderne de securitate, identificare și autorizare ale Kubernetes-ului actual. Permisiunile Helm sunt definite prin fișierul kubeconfig. Administratorii cluster-ului pot restricționa drepturile utilizatorilor cu orice grad de detaliere. Lansările continuă să fie păstrate în cadrul cluster-ului, iar restul funcționalității Helm rămâne neschimbată.

Repositoarele de chart-uri

La un nivel înalt, un repository de chart-uri este un loc în care pot fi stocate și partajate chart-urile. Clientul Helm împachetează și trimite chart-uri în repository. Cu alte cuvinte, un repository de chart-uri este un server HTTP primitiv cu un fișier index.yaml și câteva chart-uri împachetate.

Deși există anumite avantaje în faptul că API-ul unui repository de chart-uri răspunde cerințelor esențiale pentru stocare, acesta are și câteva dezavantaje:

Repozițiile charturilor sunt slab compatibile cu majoritatea implementărilor de securitate necesare în medii de producție. Un API standard pentru autentificare și autorizare este extrem de important în scenariile de producție.
Instrumentele Helm pentru urmărirea provenienței chartului, utilizate pentru semnare, verificarea integrității și provenienței chartului, sunt o parte opțională a procesului de publicare a Chart-ului.
În scenariile multi-utilizator, același chart poate fi încărcat de alt utilizator, dublând volumul de spațiu necesar pentru stocarea aceluiași conținut. Pentru a rezolva această problemă, au fost dezvoltate repozitorii mai inteligente, totuși acestea nu fac parte din specificația formală.
Utilizarea unui singur fișier index pentru căutare, stocarea metadatelor și obținerea charturilor a complicat dezvoltarea implementărilor sigure multi-utilizator.

Proiect Docker Distribution (cunoscut și sub numele de Docker Registry v2) este succesorul Docker Registry și reprezintă, de fapt, un set de instrumente pentru ambalarea, trimiterea, stocarea și livrarea imaginilor Docker. Multe servicii majore de cloud oferă produse bazate pe Distribution. Datorită atenției sporite, proiectul Distribution a beneficiat de îmbunătățiri timp de mulți ani, cele mai bune practici în materie de securitate și teste în condiții 'de lucru', transformându-l într-unul dintre cei mai de succes eroi neobservați ai lumii Open Source.

Dar știați că proiectul Distribution a fost dezvoltat pentru a distribui orice formă de conținut, nu doar imagini de containere?

Datorită eforturilor Open Container Initiative (sau OCI), charturile Helm pot fi gazduite pe orice instanță Distribution. Deocamdată, acest proces este experimental. Lucrările de suport pentru autentificare și alte funcții necesare pentru Helm 3 sunt încă în desfășurare, dar suntem foarte încântați de oportunitatea de a învăța din descoperirile realizate de echipele OCI și Distribution în acești ani. D gracias mentoratului și ghidării lor, învățăm ce înseamnă operarea unui serviciu de înaltă disponibilitate la scară mare.

O descriere mai detaliată a unor modificări viitoare în repozitoarele charturilor Helm este disponibilă la link.

Gestionarea versiunilor

În Helm 3, starea aplicației este urmărită în interiorul clusterului de un pair de obiecte:

objektul release — reprezintă o instanță a aplicației;
secretul versiunii de lansare reprezintă starea dorită a aplicației într-un moment specific (de exemplu, lansarea unei noi versiuni).

Apel helm install creează obiectul de lansare și secretul versiunii de lansare. Apelul helm upgrade necesită un obiect de lansare (pe care îl poate modifica) și creează un nou secret pentru versiunea de lansare, conținând valori noi și un manifest pregătit.

Obiectul de lansare conține informații despre lansare, unde lansarea este o instalare specifică a unei diagrame denumite și a valorilor acesteia. Acest obiect descrie metadatele de nivel superior despre lansare. Obiectul de lansare este păstrat pe parcursul întregului ciclu de viață al aplicației și este responsabil de toate secretele versiunii de lansare, precum și de toate obiectele care sunt create direct de diagrama Helm.

Secretul versiunii de lansare leagă lansarea de o serie de revizii (instalări, actualizări, rollback-uri, ștergeri).

În Helm 2, reviziile erau exclusiv secvențiale. Apelul helm install crea v1, actualizarea următoare (upgrade) — v2, și așa mai departe. Lansarea și secretul versiunii de lansare erau combinate într-un singur obiect cunoscut sub numele de revizie. Reviziile erau stocate în același spațiu de nume ca și Tiller, ceea ce însemna că fiecare lansare era «globală» din punct de vedere al spațiului de nume; drept urmare, se putea folosi doar o singură instanță a numelui.

În Helm 3, fiecare lansare este asociată cu unul sau mai multe secrete ale versiunii de lansare. Obiectul de lansare descrie întotdeauna lansarea curentă, desfășurată în Kubernetes. Fiecare secret al versiunii de lansare descrie doar o versiune a acestei lansări. O actualizare (upgrade), de exemplu, va crea un nou secret pentru versiunea de lansare și apoi va modifica obiectul de lansare pentru a indica această nouă versiune. În cazul unui rollback, se pot folosi secretele versiunii de lansare anterioare pentru a face rollback la starea anterioară a lansării.

După abandonarea lui Tiller, Helm 3 păstrează datele despre lansare într-un singur spațiu de nume cu lansarea. Această modificare permite instalarea unei diagrame cu același nume de lansare într-un alt spațiu de nume, iar datele sunt păstrate între actualizări/reîncărcări ale clusterului în etcd. De exemplu, se poate instala WordPress în spațiul de nume «foo», iar apoi în spațiul de nume «bar», și ambele lansări pot fi denumite «wordpress».

Modificări în dependențele diagramelor

Diagrama, ambalată (cu ajutorul helm package) pentru utilizarea cu Helm 2, poate fi instalat cu Helm 3, totuși fluxul de lucru pentru dezvoltarea chart-urilor a fost complet revizuit, așa că trebuie făcute unele modificări pentru a continua dezvoltarea chart-urilor cu Helm 3. În special, sistemul de gestionare a dependențelor chart-urilor s-a schimbat.

Sistemul de gestionare a dependențelor chart-ului a trecut la requirements.yaml și requirements.lock pe Chart.yaml și Chart.lock. Asta înseamnă că chart-urile care foloseau comanda helm dependency, necesită o anumită configurare pentru a funcționa în Helm 3.

Să luăm un exemplu. Să adăugăm o dependență la chart în Helm 2 și să vedem ce se va schimba când trecem la Helm 3.

În Helm 2 requirements.yaml se prezenta astfel:

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

În Helm 3, aceeași dependență va fi reflectată în Chart.yaml:

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

Chart-urile sunt încă încărcate și plasate în directorul charts/, așa că subchart-urile (subcharts), aflate în directorul charts/, vor continua să funcționeze fără modificări.

Prezentăm Library Charts

Helm 3 acceptă un tip de chart numit chart-uri library (library chart). Acest chart este utilizat de alte chart-uri, dar nu creează singur artefacte de release. Template-urile chart-urilor library pot declara doar elemente define. Alte conținuturi sunt pur și simplu ignorate. Acest lucru le permite utilizatorilor să reutilizeze și să împărtășească fragmente de cod care pot fi utilizate în multe chart-uri, evitând astfel duplicarea și respectând principiul DRY.

Chart-urile library sunt declarate în secțiunea dependencies în fișierul Chart.yaml. Instalarea și gestionarea lor nu diferă de celelalte chart-uri.

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

Așteptăm cu nerăbdare cazurile de utilizare pe care acest component le va deschide pentru dezvoltatorii de chart-uri, precum și cele mai bune practici care pot apărea datorită chart-urilor library.

Ce urmează?

Helm 3.0.0-alpha.1 este baza pe care vom începe să construim o nouă versiune a Helm. În acest articol am descris câteva dintre oportunitățile interesante ale Helm 3. Multe dintre ele se află încă în stadii incipiente de dezvoltare și este normal; esența unui alpha release este de a testa ideea, de a colecta feedback de la primii utilizatori și de a valida presupunerile noastre.

Odată ce versiunea alpha va fi lansată (să ne amintim că a avut deja loc — nota trad.), vom începe să acceptăm patch-uri pentru Helm 3 din partea comunității. Este necesar să creăm o bază solidă care să permită dezvoltarea și acceptarea de noi funcționalități, iar utilizatorii să se simtă implicați în proces, deschizând ticheturi și făcând corecturi.

În acest articol am încercat să evidențiez unele îmbunătățiri semnificative care vor apărea în Helm 3, totuși această listă nu poate fi considerată în niciun caz cuprinzătoare. Planul complet pentru Helm 3 include asemenea noutăți, cum ar fi strategii de actualizare îmbunătățite, integrare mai profundă cu registrele OCI și utilizarea schemelor JSON pentru validarea valorilor diagramelor. De asemenea, plănuim să curățăm baza de cod și să actualizăm acele părți care au fost neglijate în ultimii trei ani.

Dacă simțiți că am omis ceva, ne-ar face plăcere să auzim părerile dumneavoastră!

Alăturați-vă discuției în canalele noastre Slack:

#helm-users pentru întrebări și comunicare simplă cu comunitatea;
#helm-dev pentru discutarea pull request-urilor, codului și bug-urilor.

De asemenea, puteți participa la apelurile publice pentru dezvoltatori săptămânal, joia la ora 19:30 MSK. Întâlnirile sunt dedicate discuțiilor despre sarcinile la care lucrează dezvoltatorii cheie și comunitatea, precum și tematicilor de discuție pentru săptămână. Oricine este binevenit să se alăture și să participe la întâlnire. Linkul este disponibil în canalul Slack #helm-dev.

P.S. de la traducător

Citiți și în blogul nostru:

Sursa: habr.com