🥇Introducere în Helm 3

Notă. transl.: 16 mai a acestui an marchează o etapă semnificativă în dezvoltarea managerului de pachete pentru Kubernetes - Helm. În această zi, a fost prezentată prima versiune alfa a viitoarei versiuni majore a proiectului - 3.0. Lansarea sa va aduce schimbări semnificative și mult așteptate pentru Helm, în care mulți din comunitatea Kubernetes au mari speranțe. Noi înșine suntem unul dintre aceștia, deoarece folosim în mod activ Helm pentru implementarea aplicațiilor: l-am integrat în instrumentul nostru pentru implementarea CI/CD werf iar din când în când ne aducem contribuţia la dezvoltarea din amonte. Această traducere combină 7 note de pe blogul oficial Helm, care sunt dedicate primei versiuni alfa a Helm 3 și vorbesc despre istoria proiectului și principalele caracteristici ale Helm 3. Autorul lor este Matt „bacongobbler” Fisher, un angajat Microsoft. și unul dintre menținătorii cheie ai Helm.

Pe 15 octombrie 2015 a luat naștere proiectul cunoscut acum sub numele de Helm. La doar un an de la înființare, comunitatea Helm s-a alăturat Kubernetes, în timp ce lucra activ la Helm 2. În iunie 2018, Helm s-a alăturat CNCF ca proiect în curs de dezvoltare (incubare). Avanză rapid până în prezent și prima lansare alfa a noului Helm 3 este pe drum. (această ediție a avut deja loc la mijlocul lunii mai - aprox. traducere).

În acest articol, voi vorbi despre unde a început totul, cum am ajuns acolo unde suntem astăzi, voi introduce câteva dintre caracteristicile unice disponibile în prima versiune alfa a Helm 3 și voi explica cum intenționăm să ne dezvoltăm în continuare.

Rezumat:

istoria creării lui Helm;
un bun rămas bun de la Tiller;
depozite de diagrame;
managementul lansărilor;
modificări ale dependențelor diagramelor;
diagrame de bibliotecă;
ce urmeaza?

Istoria lui Helm

naștere

Helm 1 a început ca un proiect Open Source creat de Deis. Eram un mic startup absorbit Microsoft în primăvara anului 2017. Celălalt proiect al nostru Open Source, numit și Deis, avea un instrument deisctl, care a fost folosit (printre altele) pentru instalarea și operarea platformei Deis în Grupul de flote. La acea vreme, Fleet a fost una dintre primele platforme de orchestrare a containerelor.

La jumătatea anului 2015, am decis să schimbăm cursul și am mutat Deis (la acea vreme redenumit Deis Workflow) de la Fleet la Kubernetes. Unul dintre primele care au fost reproiectate a fost instrumentul de instalare. deisctl. L-am folosit pentru a instala și gestiona Deis Workflow în clusterul Fleet.

Helm 1 a fost creat după imaginea unor manageri de pachete celebri precum Homebrew, apt și yum. Scopul său principal a fost de a simplifica sarcini precum ambalarea și instalarea aplicațiilor pe Kubernetes. Helm a fost prezentat oficial în 2015 la conferința KubeCon din San Francisco.

Prima noastră încercare cu Helm a funcționat, dar nu a fost lipsită de anumite limitări serioase. A luat un set de manifeste Kubernetes, aromatizate cu generatoare ca blocuri introductive YAML (materia frontală)* și a încărcat rezultatele în Kubernetes.

* Notă. transl.: Din prima versiune de Helm, sintaxa YAML a fost aleasă pentru a descrie resursele Kubernetes, iar șabloanele Jinja și scripturile Python au fost acceptate la scrierea configurațiilor. Am scris mai multe despre acest lucru și despre structura primei versiuni de Helm în general în capitolul „O scurtă istorie a Helm”. acest material.

De exemplu, pentru a înlocui un câmp dintr-un fișier YAML, a trebuit să adăugați următorul construct la manifest:

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

Este grozav că motoarele de șabloane există astăzi, nu-i așa?

Din multe motive, acest program de instalare Kubernetes timpuriu a necesitat o listă codificată de fișiere manifest și a executat doar o secvență mică și fixă de evenimente. A fost atât de greu de utilizat încât echipa Deis Workflow R&D a avut dificultăți când a încercat să-și transfere produsul pe această platformă – totuși, semințele ideii fuseseră deja semănate. Prima noastră încercare a fost o mare oportunitate de învățare: ne-am dat seama că suntem cu adevărat pasionați de a crea instrumente pragmatice care să rezolve problemele de zi cu zi pentru utilizatorii noștri.

Pe baza experienței greșelilor din trecut, am început să dezvoltăm Helm 2.

Realizarea Helm 2

La sfârșitul anului 2015, echipa Google ne-a contactat. Ei lucrau la un instrument similar pentru Kubernetes. Managerul de implementare pentru Kubernetes a fost un port al unui instrument existent care a fost folosit pentru Google Cloud Platform. „Ne-am dori”, au întrebat ei, „să petrecem câteva zile discutând asemănările și diferențele?”

În ianuarie 2016, echipele Helm și Deployment Manager s-au întâlnit la Seattle pentru a face schimb de idei. Negocierile s-au încheiat cu un plan ambițios: să combine ambele proiecte pentru a crea Helm 2. Alături de Deis și Google, băieții de la SkippBox (acum face parte din Bitnami - aprox. traducere)și am început să lucrăm la Helm 2.

Am vrut să păstrăm ușurința de utilizare a lui Helm, dar adăugăm următoarele:

şabloane de diagrame pentru personalizare;
management intra-cluster pentru echipe;
depozit de diagrame de clasă mondială;
format de pachet stabil cu opțiune de semnătură;
un angajament puternic față de versiunea semantică și menținerea compatibilității cu versiunile inverse.

Pentru a atinge aceste obiective, un al doilea element a fost adăugat ecosistemului Helm. Această componentă intra-cluster a fost numită Tiller și era responsabilă cu instalarea graficelor Helm și gestionarea acestora.

De la lansarea Helm 2 în 2016, Kubernetes a adăugat câteva inovații majore. S-a adăugat controlul accesului bazat pe roluri (RBAC), care a înlocuit în cele din urmă controlul accesului bazat pe atribute (ABAC). Au fost introduse noi tipuri de resurse (Implementările erau încă în versiune beta la acea vreme). Au fost inventate definițiile personalizate de resurse (numite inițial resurse terțe sau TPR). Și, cel mai important, a apărut un set de bune practici.

În mijlocul tuturor acestor schimbări, Helm a continuat să servească cu fidelitate utilizatorii Kubernetes. După trei ani și multe completări noi, era clar că era timpul să facem modificări semnificative la baza de cod pentru a ne asigura că Helm poate continua să răspundă nevoilor tot mai mari ale unui ecosistem în evoluție.

Un rămas bun de la Tiller

În timpul dezvoltării Helm 2, am introdus Tiller ca parte a integrării noastre cu Managerul de implementare Google. Tiller a jucat un rol important pentru echipele care lucrează într-un cluster comun: a permis diferiților specialiști care operează infrastructura să interacționeze cu același set de versiuni.

Deoarece controlul accesului bazat pe roluri (RBAC) a fost activat implicit în Kubernetes 1.6, lucrul cu Tiller în producție a devenit mai dificil. 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 a permis începătorilor să experimenteze cu Helm și Kubernetes fără a fi nevoie să se scufunde mai întâi în setările de securitate. Din păcate, această configurație de permisiuni ar putea oferi utilizatorului o gamă prea largă de permisiuni de care nu avea nevoie. Inginerii DevOps și SRE au trebuit să învețe pași operaționali suplimentari atunci când instalează Tiller într-un cluster cu mai mulți locatari.

După ce am aflat cum a folosit comunitatea Helm în situații specifice, ne-am dat seama că sistemul de management al lansărilor de la Tiller nu trebuia să se bazeze pe o componentă intra-cluster pentru a menține starea sau pentru a funcționa ca un hub central pentru informațiile de lansare. În schimb, am putea pur și simplu să primim informații de la serverul API Kubernetes, să generăm o diagramă pe partea clientului și să stocăm o înregistrare a instalării în Kubernetes.

Scopul principal al lui Tiller ar fi putut fi atins fără Tiller, așa că una dintre primele noastre decizii cu privire la Helm 3 a fost să abandonăm complet Tiller.

Odată cu dispariția lui Tiller, modelul de securitate al lui Helm a fost simplificat radical. Helm 3 acceptă acum toate metodele moderne de securitate, identitate și autorizare ale Kubernetes-ului actual. Permisiunile Helm sunt determinate folosind fișier kubeconfig. Administratorii de clustere pot restricționa drepturile utilizatorilor la orice nivel de granularitate. Lansările sunt încă salvate în cluster, iar restul funcționalității lui Helm rămâne intactă.

Arhivele de diagrame

La un nivel înalt, un depozit de diagrame este un loc în care diagramele pot fi stocate și partajate. Clientul Helm împachetează și trimite diagramele către depozit. Mai simplu spus, un depozit de diagrame este un server HTTP primitiv cu un fișier index.yaml și câteva diagrame împachetate.

Deși există câteva avantaje pentru API-ul Charts Repository care îndeplinește cele mai multe cerințe de bază de stocare, există și câteva dezavantaje:

Arhivele de diagrame nu sunt compatibile cu majoritatea implementărilor de securitate necesare într-un mediu de producție. A avea un API standard pentru autentificare și autorizare este extrem de important în scenariile de producție.
Instrumentele Helm de proveniență a diagramelor, utilizate pentru a semna, a verifica integritatea și proveniența unei diagrame, sunt o parte opțională a procesului de publicare a diagramelor.
În scenariile cu mai mulți utilizatori, aceeași diagramă poate fi încărcată de un alt utilizator, dublând spațiul necesar pentru stocarea aceluiași conținut. Arhivele mai inteligente au fost dezvoltate pentru a rezolva această problemă, dar nu fac parte din specificația formală.
Utilizarea unui singur fișier index pentru căutarea, stocarea metadatelor și preluarea diagramelor a făcut dificilă dezvoltarea implementărilor securizate pentru mai mulți utilizatori.

Proiect Distribuție Docker (cunoscut și ca Docker Registry v2) este succesorul Docker Registry și acționează în esență ca un set de instrumente pentru ambalarea, expedierea, stocarea și livrarea imaginilor Docker. Multe servicii cloud mari oferă produse bazate pe distribuție. Datorită acestei atenții sporite, proiectul Distribution a beneficiat de ani de îmbunătățiri, bune practici de securitate și teste pe teren care l-au făcut unul dintre cei mai de succes eroi necunoscuti ai lumii Open Source.

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

Mulțumită eforturilor Inițiativa Open Container (sau OCI), diagramele Helm pot fi plasate pe orice instanță de Distribuție. Deocamdată, acest proces este experimental. Asistența pentru autentificare și alte funcții necesare pentru un Helm 3 complet sunt în desfășurare, dar suntem încântați să aflăm din descoperirile pe care echipele OCI și de distribuție le-au făcut de-a lungul anilor. Și prin îndrumarea și îndrumarea lor, aflăm cum este să operați un serviciu de înaltă disponibilitate la scară.

Este disponibilă o descriere mai detaliată a unor modificări viitoare ale depozitelor de diagrame Helm по ссылке.

Managementul lansărilor

În Helm 3, starea aplicației este urmărită în cluster de o pereche de obiecte:

obiect release - reprezintă o instanță de aplicație;
secretul versiunii de lansare - reprezintă starea dorită a aplicației la un anumit moment în timp (de exemplu, lansarea unei noi versiuni).

apel helm install creează un obiect de lansare și un secret al versiunii de lansare. Apel helm upgrade necesită un obiect de lansare (pe care se poate schimba) și creează o nouă versiune secretă de lansare care conține noile valori și un manifest pregătit.

Obiectul Release conține informații despre ediție, unde release este o instalare specifică a unei diagrame și valori numite. Acest obiect descrie metadatele de nivel superior despre lansare. Obiectul de lansare persistă pe tot parcursul ciclului de viață al aplicației și este proprietarul tuturor secretelor versiunii de lansare, precum și al tuturor obiectelor care sunt create direct de diagrama Helm.

Secretul versiunii de lansare asociază o versiune cu o serie de revizuiri (instalare, actualizări, rollback, ștergere).

În Helm 2, revizuirile au fost extrem de consistente. Apel helm install creat v1, actualizarea ulterioară (upgrade) - v2 și așa mai departe. Secretul versiunii de lansare și lansare au fost restrânse într-un singur obiect cunoscut sub numele de revizuire. Verziile au fost stocate în același spațiu de nume ca Tiller, ceea ce însemna că fiecare lansare era „globală” în ceea ce privește spațiul de nume; ca urmare, a putut fi folosită 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 ediția curentă implementată în Kubernetes. Fiecare versiune secretă a versiunii descrie o singură versiune a acelei versiuni. O actualizare, de exemplu, va crea o nouă versiune secretă a versiunii și apoi va schimba obiectul de lansare pentru a indica acea nouă versiune. În caz de rollback, puteți utiliza secretele versiunii anterioare pentru a reveni la o stare anterioară.

După ce Tiller este abandonat, Helm 3 stochează datele de lansare în același spațiu de nume ca și versiunea. Această modificare vă permite să instalați o diagramă cu același nume de ediție într-un spațiu de nume diferit, iar datele sunt salvate între actualizările/repornirile clusterului în etcd. De exemplu, puteți instala WordPress în spațiul de nume „foo” și apoi în spațiul de nume „bar”, iar ambele versiuni pot fi denumite „wordpress”.

Modificări ale dependențelor diagramelor

Diagrame împachetate (folosind helm package) pentru utilizare cu Helm 2 poate fi instalat cu Helm 3, cu toate acestea, fluxul de lucru de dezvoltare a diagramelor a fost complet revizuit, așa că trebuie făcute unele modificări pentru a continua dezvoltarea diagramelor cu Helm 3. În special, sistemul de gestionare a dependenței de diagrame s-a schimbat.

Sistemul de management al dependențelor graficului a trecut de la requirements.yaml и requirements.lock pe Chart.yaml и Chart.lock. Aceasta înseamnă că diagramele care au folosit comanda helm dependency, necesită o anumită configurare pentru a funcționa în Helm 3.

Să ne uităm la un exemplu. Să adăugăm o dependență diagramei din Helm 2 și să vedem ce se schimbă atunci când trecem la Helm 3.

În Helm 2 requirements.yaml arata asa:

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ță se va reflecta în dvs Chart.yaml:

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

Diagramele sunt încă descărcate și plasate în director charts/, deci subdiagrame (subdiagrame), aflat în catalog charts/, va continua să funcționeze fără modificări.

Prezentarea graficelor bibliotecii

Helm 3 acceptă o clasă de diagrame numite diagrame de bibliotecă (diagrama bibliotecii). Această diagramă este folosită de alte diagrame, dar nu creează nici un artefact de lansare în sine. Șabloanele de diagrame de bibliotecă pot declara doar elemente define. Alt conținut este pur și simplu ignorat. Acest lucru permite utilizatorilor să refolosească și să partajeze fragmente de cod care pot fi utilizate în mai multe diagrame, evitând astfel duplicarea și respectarea principiului uSCAT.

Diagramele bibliotecii sunt declarate în secțiune dependencies în dosar Chart.yaml. Instalarea și gestionarea acestora nu este diferită de alte diagrame.

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

Suntem încântați de cazurile de utilizare pe care această componentă le va deschide pentru dezvoltatorii de diagrame, precum și de cele mai bune practici care pot apărea din diagramele bibliotecii.

Ce urmeaza?

Helm 3.0.0-alpha.1 este fundația pe care începem să construim o nouă versiune a Helm. În articol am descris câteva caracteristici interesante ale Helm 3. Multe dintre ele sunt încă în stadii incipiente de dezvoltare și acest lucru este normal; Scopul unei lansări alfa este de a testa ideea, de a aduna feedback de la primii utilizatori și de a confirma presupunerile noastre.

De îndată ce versiunea alfa este lansată (amintiți-vă că acesta este sa întâmplat deja - aprox. traducere), vom începe să acceptăm patch-uri pentru Helm 3 de la comunitate. Trebuie să creați o bază solidă care să permită dezvoltarea și adoptarea de noi funcționalități, iar utilizatorii să se simtă implicați în proces, deschizând bilete și efectuând remedieri.

Am încercat să evidențiez unele dintre îmbunătățirile majore care vin la Helm 3, dar această listă nu este deloc exhaustivă. Foaia de parcurs completă pentru Helm 3 include caracteristici precum strategii de actualizare îmbunătățite, integrare mai profundă cu registrele OCI și utilizarea schemelor JSON pentru a valida valorile diagramelor. De asemenea, intenționăm să curățăm baza de cod și să actualizăm părți ale acesteia care au fost neglijate în ultimii trei ani.

Dacă simțiți că am omis ceva, ne-ar plăcea să vă auzim părerile!

Alăturați-vă discuției pe site-ul nostru Canale slăbite:

#helm-users pentru întrebări și comunicare simplă cu comunitatea;
#helm-dev pentru a discuta solicitări de extragere, cod și erori.

Puteți, de asemenea, să discutați prin Apelurile noastre săptămânale pentru dezvoltatori publici, joi, la ora 19:30 MSK. Întâlnirile sunt dedicate discutării problemelor la care dezvoltatorii cheie și comunității lucrează, precum și subiectelor de discuție pentru săptămână. Oricine se poate alătura și participa la întâlnire. Link disponibil pe canalul Slack #helm-dev.

PS de la traducator

Citește și pe blogul nostru:

Sursa: www.habr.com

Introducere în Helm 3