🥇Spoznavanje z Helm 3

Op. prev.: 16. maja letos godine - pomembna mejnik v razvoju upravitelja paketov za Kubernetes - Helm. Na ta dan je bil predstavljen prvi alfa-izdaja prihodnje velike različice projekta - 3.0. Njegov izid bo prinesel pomembne in dolgo pričakovane spremembe v Helmu, na katere mnogi v Kubernetes skupnosti stavljajo velike upanje. Med njimi smo tudi mi, saj aktivno uporabljamo Helm za namestitev aplikacij: integrirali smo ga v našo orodje za izvedbo CI/CD werf in občasno prispevamo svoj delež k razvoju upstream. Ta prevod združuje 7 opomb z uradnega bloga Helma, ki so posvečene prvemu alfa-izdaji Helma 3 in pripovedujejo zgodovino projekta ter glavne funkcionalnosti Helma 3. Njegov avtor je Matt «bacongobbler» Fisher, zaposlen pri Microsoftu in eden ključnih vzdrževalcev Helma.

15. oktobra 2015 se je rodil projekt, danes znan kot Helm. Le leto po ustanovitvi se je skupnost Helm pridružila Kubernetesu, hkrati pa je aktivno delala na Helmu 2. Junija 2018 je Helm vstopil v sestavo CNCF kot razvijajoči (incubating) projekt. Preselimo se v sedanjost - in že se bliža prvi alfa-izdaja novega Helma 3 (ta izdaja se je že zgodila sredino maja - op. prev.).

V tem gradivu bom govoril o tem, kako se je vse začelo, kako smo prišli do trenutne faze, predstavil nekatere edinstvene značilnosti, ki so na voljo v prvem alfa-izdaji Helma 3, in razložil, kako načrtujemo razvoj naprej.

Povzetek:

zgodovina nastanka Helma;
nežno slovo od Tillerja;
repozitoriji chartov;
upravljanje z različicami;
spremembe v odvisnostih chartov;
library charts;
kaj sledi?

Zgodovina nastanka Helma

Rojstvo

Helm 1 se je začel kot projekt odprte kode, ki ga je ustvarilo podjetje Deis. Bili smo majhna startup pripravljen Microsoftom spomladi 2017. Naš drug projekt odprte kode, ki je imel prav tako ime Deis, je imel orodje deisctl, ki se je uporabljalo (med drugim) za namestitev in upravljanje platforme Deis v klasterju Fleet. Takrat je bil Fleet ena prvih platform za orkestracijo kontejnerjev.

Sredi leta 2015 smo se odločili spremeniti smer in prenesli Deis (takrat preimenovan v Deis Workflow) z Fleeta na Kubernetes. Eden prvih je bil predelan namestitveni instrument deisctl. Uporabili smo ga za namestitev in upravljanje Deis Workflow v klasterju Fleet.

Helm 1 je bil ustvarjen po zgledu znanih upravljalnikov paketov, kot sta Homebrew, apt in yum. Njegova glavna naloga je bila poenostavitev nalog, kot so pakiranje in namestitev aplikacij v Kubernetes. Helm je bil uradno predstavljen leta 2015 na konferenci KubeCon v San Franciscu.

Naša prva poskusna uporaba Helma je bila uspešna, vendar ni šlo brez resnih omejitev. Uporabljal je niz manifestov Kubernetes, obogatenih z generatorji kot vhodnimi blokami YAML. (front-matter)*, in naloži rezultate v Kubernetes.

* Op. prev.: S prve različice Helma je za opis virov Kubernetes izbrana sintaksa YAML, pri pisanju konfiguracij pa sta bila podprta predloga Jinja in Python-skripte. Več o tem in o prvotni različici Helma smo pisali v poglavju 'Kratka zgodovina Helma' tega gradiva. materiala.

Na primer, za zamenjavo polja v YAML-datoteki je bilo treba dodati naslednjo konstrukcijo v manifest:

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

Super je, da danes obstajajo predloge, kajne?

Zaradi številnih razlogov je ta zgodnji namestitveni program Kubernetes zahteval strogo določen seznam manifestnih datotek in je izvajal le majhno fiksno zaporedje dogodkov. Njegova uporaba je bila tako težka, da se je R&D ekipi Deis Workflow zdelo težko, ko so poskušali prenesti svoj izdelek na to platformo — kljub temu so bila semena ideje že posejana. Naša prva poskusna uporaba je postala odlična priložnost za učenje: spoznali smo, da nas resnično zanima ustvarjanje pragmatičnih orodij, ki rešujejo vsakdanje težave naših uporabnikov.

Na osnovi izkušenj iz preteklosti smo se lotili razvoja Helma 2.

Ustvarjanje Helma 2

Konec leta 2015 nas je kontaktirala ekipa iz Googla. Delali so na podobnem orodju za Kubernetes. Deployment Manager za Kubernetes je bil prenos obstoječega orodja, ki je bilo uporabljeno na Google Cloud Platform. 'Ali ne bi želeli,' so vprašali, 'preživeti nekaj dni za razpravo o podobnostih in razlikah?'

V januarju 2016 sta se ekipi Helma in Deployment Managerja srečali v Seattlu, da bi izmenjali ideje. Pogovori so se končali z ambicioznim načrtom: združiti oba projekta, da bi ustvarili Helm 2. Skupaj z Deisom in Googlom se je ekipi razvijalcev pridružila ekipa iz SkippBox (zdaj del Bitnami — op. prev.), in pričeli smo z delom na Helmu 2.

Želeli smo ohraniti preprostost uporabe Helma, a dodati naslednje:

predloge chartov za prilagoditev;
notranje upravljanje za ekipe;
prvovrsten repozitorij chartov;
stabilen format paketov z možnostjo podpisa;
močno zavezanost semantičnemu različničenju in ohranjanju povratne združljivosti med različicami.

Za dosego teh ciljev je bil v ekosistem Helm dodan drugi element. Ta notranji komponent se je imenoval Tiller in je skrbel za namestitev Helm chartov in njihovo upravljanje.

Od izida Helma 2 leta 2016 je Kubernetes pridobil več pomembnih novosti. Pojavilo se je upravljanje dostopa, ki temelji na vlogah (RBAC), ki je sčasoma nadomestilo upravljanje dostopa, ki temelji na atributih (ABAC). Predstavili so nove vrste virov (izdelek je takrat še vedno ostal v beta različici). Izumljene so bile Definicije prilagojenih virov (sprva so bile imenovane Tretje stranske stvari ali TPR-ji). In kar je najpomembneje — pojavila se je zbirka najboljših praks.

Ob vseh teh spremembah je Helm še naprej zvest in zanesljiv uporabnikom Kubernetesa. Po treh letih in številnih novih dodatkih je postalo jasno, da je čas za pomembne spremembe v osnovi kode, da bi Helm še naprej zadostoval naraščajočim potrebam razvijajočega se ekosistema.

Neposredno slovo od Tillerja

Med razvojem Helma 2 smo predstavili Tiller kot del naše integracije z Googleovim Upravljalnikom uvajanj. Tiller je igral pomembno vlogo za ekipe, ki so delovale v okviru skupnega klasterja: dovoljeval je različnim strokovnjakom, ki upravljajo infrastrukturo, da so komunicirali s istim setom izdaj.

Ker je bila kontrola dostopa na osnovi vlog (RBAC) privzeto omogočena v Kubernetes 1.6, je bilo delo s Tillerjem v produkciji vse težje. Zaradi ogromnega števila možnih varnostnih politik smo se odločili, da privzeto ponudimo dovolilno konfiguracijo. To je omogočilo novincem, da eksperimentirajo z Helm in Kubernetes brez potrebe po začetnem poglabljanju v varnostne nastavitve. Na žalost je ta dovolilna konfiguracija lahko uporabniku podelila preširok spekter dovoljenj, ki jih ni potreboval. Inženirji DevOps in SRE so se morali naučiti dodatnih operativnih korakov za nastavitev Tillerja v večuporabniškem (multi-tenant) klastru.

Ko smo izvedeli, kako skupnost uporablja Helm v specifčnih situacijah, smo ugotovili, da Tiller, sistem za upravljanje izdaj, ne potrebuje zanašanja na intra-klasterske komponente za ohranjanje stanj ali delovanje kot osrednji vozlišče z informacijami o izdajah. Namesto tega bi lahko preprosto pridobili podatke iz API strežnika Kubernetes, generirali chart na strani odjemalca in shranili zapis o namestitvi v Kubernetes.

Glavno nalogo Tillerja je bilo mogoče izvesti tudi brez njega, zato je bila ena prvih odločitev glede Helma 3 popolna opustitev Tillerja.

S slovesom Tillerja je varnostni model Helma radikalno poenostavljen. Helm 3 zdaj podpira vse sodobne metode varnosti, identifikacije in avtorizacije trenutnega Kubernetesa. Dovoljenja Helma so določena s datoteko kubeconfig. Skupinski skrbniki lahko omejijo pravice uporabnikov na katerikoli stopnji podrobnosti. Izdaje so še vedno shranjene znotraj klasterja, ostala funkcionalnost Helma pa ostaja nespremenjena.

Repozitoriji chartov

Na splošni ravni je repozitorij chartov mesto, kjer lahko shranjujete in delite charte. Odjemalec Helm pakira in pošlje charte v repozitorij. Preprosto povedano, repozitorij chartov je osnovni HTTP strežnik s datoteko index.yaml in nekaterimi pakiranimi charti.

Čeprav ima API repozitorija chartov nekatere prednosti, da zadostuje osnovnim zahtevam skladišča, ima tudi nekaj pomanjkljivosti:

Repozitoriji chartov slabo sodelujejo z večino implementacij varnosti, potrebnih v produkcijskem okolju. Imajo standardni API za avtentikacijo in avtorizacijo, je izjemno pomembno v produkcijskih scenarijih.
Orodja Helm za sledenje izvoru charta, uporabljena za podpisovanje, preverjanje celovitosti in izvor charta, so neobvezen del postopka objave charta.
V scenarijih z več uporabniki lahko isti chart naloži drug uporabnik, kar podvoji prostor, potreben za shranjevanje istega vsebine. Za reševanje tega problema so bili razviti pametnejši repozitoriji, vendar niso del formalne specifikacije.
Uporaba enotne indeksne datoteke za iskanje, shranjevanje metapodatkov in pridobivanje chartov je otežila razvoj varnih večuporabniških implementacij.

Projekt Docker Distribution (znan tudi kot Docker Registry v2) je naslednik Docker Registry in dejansko predstavlja nabor orodij za pakiranje, pošiljanje, shranjevanje in dostavo Docker slik. Mnogi veliki oblačni ponudniki ponujajo izdelke, ki temeljijo na Distribution. Zaradi večje pozornosti je projekt Distribution pridobil od večletnih izboljšav, najboljših praks na področju varnosti in testiranja v 'bojih', kar ga je spremenilo v enega izmed najbolj uspešnih nenapisnih junakov sveta odprtokodnih programov.

Toda ali ste vedeli, da je projekt Distribution zasnovan za distribucijo katere koli oblike vsebine, ne le slik kontejnerjev?

Zaradi prizadevanj Open Container Initiative (ali OCI), Helm charti lahko gostujejo na kateremkoli primeru Distribution. Dokler je ta postopek eksperimentalen. Delo na podpori prijav in drugih funkcij, potrebnih za polno delovanje Helm 3, še ni končano, vendar smo zelo veseli priložnosti, da se učimo iz odkritij, ki so jih naredili ekipe OCI in Distribution v teh letih. In zahvaljujoč njihovemu mentorstvu in vodstvu se učimo, kaj pomeni upravljati visoko dostopno storitev na veliki lestvici.

Podrobnejši opis nekaterih prihajajočih sprememb v repozitorijih Helm chartov je na voljo na povezavi.

Upravljanje isporukom

V Helm 3 se stanje aplikacije sledi znotraj gruče z dvema objektoma:

release object — predstavlja instanco aplikacije;
release version secret — predstavlja željeno stanje aplikacije u određenom trenutku (na primer, objava nove verzije).

Poziv helm install kreira release object i release version secret. Poziv helm upgrade zahteva postojanje release object (koji može da menja) i kreira novi release version secret, koji sadrži nove vrednosti i pripremljeni manifest.

Release object sadrži informacije o izdanju, gde je izdanje — konkretna instalacija imenovanog charta i vrednosti. Ovaj objekat opisuje metapodatke na najvišem nivou o izdanju. Release object se čuva tokom celog životnog ciklusa aplikacije i predstavlja vlasnika svih release version secret-ova, kao i svih objekata koji se direktno kreiraju Helm chartom.

Release version secret povezuje izdanje sa serijom revizija (instalacija, ažuriranja, vraćanja, brisanja).

U Helm 2, revizije su bile isključivo sekvencijalne. Poziv helm install stvarao je v1, sledeće ažuriranje (upgrade) — v2, i tako dalje. Release i release version secret su bili spojeni u jedinstveni objekat, poznat kao revision. Revision-i su se čuvali u istom prostoru imena kao i Tiller, što je značilo da je svako izdanje bilo "globalno" u smislu prostora imena; kao rezultat, mogao je biti korišćen samo jedan primerak imena.

U Helm 3, svako izdanje je povezano sa jednim ili više release version secret-ova. Release object uvek opisuje trenutno izdanje, razmešteno u Kubernetes. Svaki release version secret opisuje samo jednu verziju ovog izdanja. Ažuriranje (upgrade), na primer, stvorit će novi release version secret i zatim izmeniti release object da ukazuje na ovu novu verziju. U slučaju vraćanja (rollback) može se upotrebiti prethodni release version secret-i da se vrati izdanje na prethodno stanje.

Nakon odbacivanja Tiller-a, Helm 3 čuva podatke o izdanju u jedinstvenom prostoru imena zajedno s izdanjem. Ova promena omogućava instalaciju charta sa istim imenom izdanja u drugo ime prostora, a podaci se čuvaju između ažuriranja/pregrevanja klastera u etcd. Na primer, možete instalirati WordPress u prostor imena „foo“, a zatim u prostor imena „bar“, i oba izdanja mogu se zvati „wordpress“.

Promene u zavisnostima chartova

Chartovi, upakovani (putem helm package) za uporabo s Helm 2, lahko namestite s Helm 3, vendar je bil delovni proces razvoja grafikonov popolnoma prenovljen, zato je potrebno opraviti nekatere spremembe, da bi nadaljevali z razvojem grafikonov s Helm 3. Zlasti se je spremenil sistem upravljanja odvisnosti grafikonov.

Sistem upravljanja odvisnosti grafikona se je preselil iz requirements.yaml in requirements.lock na Chart.yaml in Chart.lock. To pomeni, da grafikon, ki je uporabljal ukaz helm dependency, zahteva nekatere nastavitve, da deluje v Helm 3.

Poglejmo primer. Dodajmo odvisnost grafikonov v Helm 2 in poglejmo, kaj se bo spremenilo ob prehodu na Helm 3.

V Helm 2 requirements.yaml je izgledal takole:

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

V Helm 3 bo ta ista odvisnost odražena v vašem Chart.yaml:

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

Grafikoni še vedno nalagajo in se nahajajo v direktoriju charts/, zato subgrafikoni (subcharts), ki ležijo v mapi charts/, bodo še naprej delovali brez sprememb.

Predstavljamo Library Charts

Helm 3 podpira razred grafikona, ki se imenuje grafikon knjižnice (library chart). Ta grafikon uporabljajo drugi grafikoni, vendar sam ne ustvarja nobenih artefaktov izdaje. Predloge library chartov lahko razglašajo samo elemente define. Druga vsebina preprosto ignorira. To omogoča uporabnikom, da ponovno uporabljajo in izmenjujejo dele kode, ki jih je mogoče uporabiti v številnih grafikoni, s čimer se izognemo podvajanju in upoštevamo načelo DRY.

Grafikoni knjižnice se razglašajo v razdelku dependencies в файле Chart.yaml. Namestitev in upravljanje z njimi se ne razlikujeta od drugih grafikoni.

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

Z velikim pričakovanjem čakamo na primere uporabe, ki jih bo ta komponenta odprla pred razvijalci grafikonov, ter najboljše prakse, ki lahko nastanejo zahvaljujoč library charts.

Kaj zdaj?

Helm 3.0.0-alpha.1 je osnova, na kateri začnemo graditi novo različico Helma. V članku sem opisal nekatere zanimive možnosti Helma 3. Mnoge od njih so trenutno še v zgodnjih fazah razvoja in to je v redu; bistvo alfa-izdaje je preveriti idejo, zbrati povratne informacije prvih uporabnikov in potrditi naše predpostavke.

Ko bo alfa različica izdana (spomnimo se, da se že zgodilo — op. prev.), začnemo sprejemati popravke za Helm 3 od skupnosti. Potrebno je ustvariti zanesljivo osnovo, ki bo omogočila razvoj in sprejem novih funkcionalnosti, uporabniki pa se bodo lahko vključili v proces tako, da odpirajo zahtevke in vnašajo popravke.

V članku sem poskušal osvetliti nekatere resne izboljšave, ki bodo prišle v Helm 3, vendar tega seznama nikakor ni mogoče označiti za izčrpen. Celovit načrt za Helm 3 vključuje novosti, kot so izboljšane strategije posodabljanja, globlja integracija z OCI registri in uporaba JSON shem za preverjanje vrednosti grafov. Prav tako načrtujemo čiščenje kode in posodobitev tistih delov, ki so ostali brez pozornosti zadnja tri leta.

Če menite, da smo kaj spustili, bomo veseli vaših misli!

Pridružite se razpravi v naših Slack kanalih:

#helm-users za vprašanja in preprosto komuniciranje s skupnostjo;
#helm-dev za razpravo o pull zahtevkih, kodi in napakah.

Lahko se tudi pogovarjate na naših tedenskih Public Developer Calls ob četrtkih ob 19:30 MSK. Sestanki so namenjeni razpravi o nalogah, na katerih delajo ključni razvijalci in skupnost, ter temah razprave za teden. Vsakdo se lahko pridruži in sodeluje na sestanku. Povezava je dostopna v Slack kanalu. #helm-dev.