Predstavljamo vam Helm 3

Opomba. prevod: 16. maj tega leta je pomemben mejnik v razvoju upravitelja paketov za Kubernetes - Helm. Na ta dan je bila predstavljena prva alfa izdaja prihodnje večje različice projekta - 3.0. Njegova izdaja bo Helmu prinesla pomembne in dolgo pričakovane spremembe, od katerih mnogi v skupnosti Kubernetes veliko upajo. Tudi sami smo med temi, saj Helm aktivno uporabljamo za postavitev aplikacij: integrirali smo ga v naše orodje za implementacijo CI/CD werf in občasno prispevamo k razvoju upstreama. Ta prevod združuje 7 zapiskov iz uradnega spletnega dnevnika Helm, ki so posvečeni prvi alfa izdaji Helma 3 in govorijo o zgodovini projekta ter glavnih značilnostih Helma 3. Njihov avtor je Matt “bacongobbler” Fisher, uslužbenec Microsofta in eden ključnih vzdrževalcev Helma.

15. oktobra 2015 se je rodil projekt, zdaj znan kot Helm. Samo leto po ustanovitvi se je skupnost Helm pridružila Kubernetesu, medtem ko je aktivno delala na Helmu 2. Junija 2018 je Helm pridružil CNCF kot razvojni (inkubacijski) projekt. Hitro naprej v sedanjost in prva izdaja alfa novega Helma 3 je na poti. (ta izdaja se je že zgodil sredi maja - cca. prev.).

V tem delu bom govoril o tem, kje se je vse začelo, kako smo prišli do mesta, kjer smo danes, predstavil nekaj edinstvenih funkcij, ki so na voljo v prvi izdaji alfa Helm 3, in razložil, kako nameravamo napredovati.

Povzetek:

• zgodovina nastanka Helma;
• nežno slovo od Tillerja;
• repozitoriji grafikonov;
• upravljanje izpustov;
• spremembe odvisnosti grafikona;
• knjižnične karte;
• kaj je naslednje?

Zgodovina Helma

Rojstvo

Helm 1 se je začel kot odprtokodni projekt, ki ga je ustvaril Deis. Bili smo majhen startup absorbira Microsoft spomladi 2017. Naš drugi odprtokodni projekt, prav tako imenovan Deis, je imel orodje deisctl, ki je bil (med drugim) uporabljen za namestitev in delovanje platforme Deis v Grozd flote. Takrat je bila Fleet ena prvih platform za orkestracijo kontejnerjev.

Sredi leta 2015 smo se odločili spremeniti smer in Deis (takrat preimenovan v Deis Workflow) preselili iz Fleet v Kubernetes. Eno prvih, ki je bilo prenovljeno, je bilo orodje za namestitev. deisctl. Uporabili smo ga za namestitev in upravljanje Deis Workflow v gruči Fleet.

Helm 1 je bil ustvarjen po podobi slavnih upraviteljev paketov, kot so Homebrew, apt in yum. Njegov glavni cilj je bil poenostaviti naloge, kot sta pakiranje in nameščanje aplikacij na Kubernetes. Helm je bil uradno predstavljen leta 2015 na konferenci KubeCon v San Franciscu.

Naš prvi poskus s Helmom je uspel, vendar ni šlo brez resnih omejitev. Kot uvodne bloke YAML je vzel niz manifestov Kubernetes, začinjenih z generatorji (prednja zadeva)* in naložil rezultate v Kubernetes.

* Opomba. prevod: Od prve različice Helma je bila za opis virov Kubernetes izbrana sintaksa YAML, pri pisanju konfiguracij pa so bile podprte predloge Jinja in skripti Python. Več o tem in strukturi prve različice Helma nasploh smo pisali v poglavju “Kratka zgodovina Helma” ta material.

Če želite na primer zamenjati polje v datoteki YAML, ste morali v manifest dodati naslednjo konstrukcijo:

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

Super je, da danes obstajajo motorji predlog, kajne?

Iz več razlogov je ta zgodnji namestitveni program Kubernetes zahteval trdo kodiran seznam datotek manifesta in je izvedel le majhno, fiksno zaporedje dogodkov. Uporabiti ga je bilo tako težko, da je ekipa Deis Workflow R&D imela težave, ko je poskušala svoj izdelek prenesti na to platformo – vendar je bilo seme ideje že posejano. Naš prvi poskus je bil odlična priložnost za učenje: spoznali smo, da smo resnično navdušeni nad ustvarjanjem pragmatičnih orodij, ki rešujejo vsakodnevne težave naših uporabnikov.

Na podlagi izkušenj iz preteklih napak smo začeli razvijati Helm 2.

Izdelava čelade 2

Konec leta 2015 nas je Googlova ekipa kontaktirala. Delali so na podobnem orodju za Kubernetes. Upravitelj uvajanja za Kubernetes je bil pristanišče obstoječega orodja, ki je bilo uporabljeno za Google Cloud Platform. "Ali bi želeli," so vprašali, "nekaj dni razpravljati o podobnostih in razlikah?"

Januarja 2016 sta se ekipi Helm in Deployment Manager srečali v Seattlu, da bi izmenjali ideje. Pogajanja so se končala z ambicioznim načrtom: združiti oba projekta in ustvariti Helm 2. Skupaj z Deisom in Googlom so fantje iz SkippBox (zdaj del Bitnamija - pribl. prev.), in začeli smo delati na Helmu 2.

Želeli smo ohraniti Helmovo enostavnost uporabe, vendar smo dodali naslednje:

• predloge grafikonov za prilagajanje;
• upravljanje znotraj grozda za ekipe;
• repozitorij grafikonov svetovnega razreda;
• stabilen format paketa z možnostjo podpisa;
• močna zaveza semantičnemu ustvarjanju različic in ohranjanju združljivosti za nazaj med različicami.

Za dosego teh ciljev je bil v ekosistem Helm dodan drugi element. Ta komponenta znotraj gruče se je imenovala Tiller in je bila odgovorna za namestitev grafikonov Helm in njihovo upravljanje.

Od izdaje Helm 2 leta 2016 je Kubernetes dodal več večjih novosti. Dodan nadzor dostopa na podlagi vlog (RBAC), ki je sčasoma nadomestil nadzor dostopa na podlagi atributov (ABAC). Uvedene so bile nove vrste virov (razmestitve so bile takrat še v različici beta). Definicije virov po meri (prvotno imenovane Third Party Resources ali TPR) so bile izumljene. In kar je najpomembnejše, pojavil se je niz najboljših praks.

Med vsemi temi spremembami je Helm še naprej zvesto služil uporabnikom Kubernetesa. Po treh letih in številnih novih dodatkih je bilo jasno, da je čas za pomembne spremembe kodne baze, da bi zagotovili, da bo Helm še naprej izpolnjeval naraščajoče potrebe razvijajočega se ekosistema.

Nežno slovo od Tillerja

Med razvojem Helm 2 smo predstavili Tiller kot del naše integracije z Googlovim upraviteljem uvajanja. Tiller je igral pomembno vlogo za ekipe, ki so delale v skupnem grozdu: omogočal je različnim strokovnjakom, ki upravljajo infrastrukturo, interakcijo z istim naborom izdaj.

Ker je bil v Kubernetes 1.6 privzeto omogočen nadzor dostopa na podlagi vlog (RBAC), je postalo delo s Tillerjem v produkciji težje. Zaradi velikega števila možnih varnostnih pravilnikov je bilo naše stališče, da privzeto ponudimo permisivno konfiguracijo. To je novincem omogočilo eksperimentiranje s Helmom in Kubernetesom, ne da bi se morali najprej poglobiti v varnostne nastavitve. Na žalost bi lahko ta konfiguracija dovoljenj uporabnika obdarila s preširoko paleto dovoljenj, ki jih ne potrebuje. Inženirji DevOps in SRE so se morali naučiti dodatnih operativnih korakov pri namestitvi Tillerja v gručo z več najemniki.

Ko smo izvedeli, kako je skupnost uporabljala Helm v posebnih situacijah, smo ugotovili, da se Tillerjevemu sistemu za upravljanje izdaj ni bilo treba zanašati na komponento znotraj gruče, da bi vzdrževal stanje ali deloval kot osrednje vozlišče za informacije o izdajah. Namesto tega bi lahko preprosto prejeli informacije iz strežnika Kubernetes API, ustvarili grafikon na strani odjemalca in shranili zapis o namestitvi v Kubernetes.

Tillerjev glavni cilj bi lahko dosegli brez Tillerja, zato je bila ena naših prvih odločitev v zvezi s Helmom 3, da popolnoma opustimo Tillerja.

Ko je Tiller odšel, je bil Helmov varnostni model radikalno poenostavljen. Helm 3 zdaj podpira vse sodobne metode varnosti, identitete in avtorizacije trenutnega Kubernetesa. Dovoljenja Helm se določijo z uporabo datoteko kubeconfig. Skrbniki gruče lahko omejijo uporabniške pravice na poljubno raven razdrobljenosti. Izdaje so še vedno shranjene v gruči, preostala Helmova funkcionalnost pa ostane nedotaknjena.

Repozitoriji grafikonov

Na visoki ravni je repozitorij grafikonov mesto, kjer lahko grafikone shranite in delite. Odjemalec Helm zapakira in pošlje grafikone v repozitorij. Preprosto povedano, repozitorij grafikonov je primitiven strežnik HTTP z datoteko index.yaml in nekaj zapakiranih grafikonov.

Medtem ko ima API Charts Repository, ki izpolnjuje večino osnovnih zahtev glede shranjevanja, nekaj prednosti, obstaja tudi nekaj slabosti:

• Repozitoriji grafikonov niso združljivi z večino varnostnih izvedb, potrebnih v produkcijskem okolju. Imeti standardni API za preverjanje pristnosti in avtorizacijo je izjemno pomembno v proizvodnih scenarijih.
• Helmova orodja za preverjanje porekla grafikona, ki se uporabljajo za podpisovanje, preverjanje celovitosti in porekla grafikona, so izbirni del postopka objavljanja grafikona.
• V scenarijih z več uporabniki lahko isti grafikon naloži drug uporabnik, s čimer se podvoji količina prostora, potrebnega za shranjevanje iste vsebine. Za rešitev tega problema so bili razviti pametnejši repozitoriji, ki pa niso del uradne specifikacije.
• Uporaba ene same indeksne datoteke za iskanje, shranjevanje metapodatkov in pridobivanje grafikonov je otežila razvoj varnih večuporabniških izvedb.

Projekt Docker distribucija (znan tudi kot Docker Registry v2) je naslednik Docker Registry in v bistvu deluje kot nabor orodij za pakiranje, pošiljanje, shranjevanje in dostavo slik Docker. Številne velike storitve v oblaku ponujajo izdelke, ki temeljijo na distribuciji. Zahvaljujoč tej povečani pozornosti je bil projekt Distribution deležen let izboljšav, najboljših varnostnih praks in terenskih testiranj, ki so ga naredili za enega najuspešnejših neopevanih junakov odprtokodnega sveta.

Toda ali ste vedeli, da je bil Distribution Project zasnovan za distribucijo katere koli oblike vsebine, ne le slik vsebnikov?

Hvala za trud Odpri pobudo za zabojnike (ali OCI), lahko karte Helm postavite na katero koli distribucijsko instanco. Zaenkrat je ta postopek poskusen. Podpora za prijavo in druge funkcije, ki so potrebne za popoln Helm 3, še potekajo, vendar smo navdušeni, da se učimo iz odkritij, do katerih so v preteklih letih prišli ekipe OCI in Distribution. Z njihovim mentorstvom in usmerjanjem se naučimo, kako je upravljati visoko razpoložljivo storitev v velikem obsegu.

Na voljo je podrobnejši opis nekaterih prihajajočih sprememb v repozitorijih grafikonov Helm по ссылке.

Upravljanje izdaj

V Helmu 3 stanje aplikacije znotraj gruče spremlja par predmetov:

• objekt sprostitve - predstavlja primerek aplikacije;
• skrivnost različice izdaje - predstavlja želeno stanje aplikacije v določenem trenutku (na primer izdaja nove različice).

Izziv helm install ustvari objekt izdaje in skrivnost različice izdaje. Pokliči helm upgrade zahteva objekt izdaje (ki ga lahko spremeni) in ustvari novo skrivnost različice izdaje, ki vsebuje nove vrednosti in pripravljen manifest.

Objekt izdaje vsebuje informacije o izdaji, kjer je izdaja specifična namestitev imenovanega grafikona in vrednosti. Ta objekt opisuje metapodatke najvišje ravni o izdaji. Objekt izdaje obstaja skozi celoten življenjski cikel aplikacije in je lastnik vseh skrivnosti različice izdaje, pa tudi vseh objektov, ki jih neposredno ustvari grafikon Helm.

Skrivnost različice izdaje povezuje izdajo z nizom revizij (namestitev, posodobitve, povrnitve, brisanje).

V Helmu 2 so bile revizije izjemno dosledne. Pokliči helm install ustvarjena v1, kasnejša posodobitev (nadgradnja) - v2 itd. Izdaja in skrivnost različice izdaje sta bili strnjeni v en sam objekt, imenovan revizija. Revizije so bile shranjene v istem imenskem prostoru kot Tiller, kar je pomenilo, da je bila vsaka izdaja "globalna" v smislu imenskega prostora; posledično je bilo mogoče uporabiti samo en primerek imena.

V Helmu 3 je vsaka izdaja povezana z eno ali več skrivnostmi različice izdaje. Objekt izdaje vedno opisuje trenutno izdajo, uvedeno v Kubernetes. Vsaka skrivnost različice izdaje opisuje samo eno različico te izdaje. Nadgradnja bo na primer ustvarila novo skrivnost različice izdaje in nato spremenila objekt izdaje, da kaže na to novo različico. V primeru povrnitve lahko uporabite skrivnosti različice prejšnje izdaje za povrnitev izdaje na prejšnje stanje.

Ko je Tiller opuščen, Helm 3 shrani podatke o izdaji v isti imenski prostor kot izdaja. Ta sprememba vam omogoča namestitev grafikona z istim imenom izdaje v drugem imenskem prostoru, podatki pa se shranijo med posodobitvami/ponovnimi zagoni gruče v itd. WordPress lahko na primer namestite v imenski prostor »foo« in nato v imenski prostor »bar«, obe izdaji pa lahko poimenujete »wordpress«.

Spremembe odvisnosti grafikona

Grafikoni pakirani (uporaba helm package) za uporabo s Helm 2 je mogoče namestiti s Helm 3, vendar je bil potek dela za razvoj grafikonov popolnoma prenovljen, zato je treba narediti nekaj sprememb za nadaljevanje razvoja grafikonov s Helm 3. Zlasti se je spremenil sistem za upravljanje odvisnosti grafikonov.

Sistem za upravljanje odvisnosti grafikona se je preselil iz requirements.yaml и requirements.lock o Chart.yaml и Chart.lock. To pomeni, da so grafikoni, ki so uporabili ukaz helm dependency, zahteva nekaj nastavitev za delo v Helmu 3.

Poglejmo si primer. Dodajmo odvisnost grafikonu v Helm 2 in poglejmo, kaj se spremeni ob prehodu na Helm 3.

V Helmu 2 requirements.yaml izgledal takole:

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

V Helmu 3 se bo enaka odvisnost odražala 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 se še vedno prenesejo in postavijo v imenik charts/, torej podgrafi (podgrafi), ki leži v katalogu charts/, bo brez sprememb deloval še naprej.

Predstavljamo knjižnične grafikone

Helm 3 podpira razred grafikonov, imenovanih knjižnični grafikoni (tabela knjižnice). Ta grafikon uporabljajo drugi grafikoni, vendar sam po sebi ne ustvarja artefaktov izdaje. Predloge knjižničnih grafikonov lahko deklarirajo samo elemente define. Druge vsebine preprosto ignoriramo. To uporabnikom omogoča ponovno uporabo in skupno rabo odrezkov kode, ki jih je mogoče uporabiti v več grafikonih, s čimer se izognejo podvajanju in upoštevajo načelo DRY.

Knjižnične karte so deklarirane v razdelku dependencies v datoteki Chart.yaml. Njihova namestitev in upravljanje se ne razlikujeta od drugih grafikonov.

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

Navdušeni smo nad primeri uporabe, ki jih bo ta komponenta odprla razvijalcem grafikonov, kot tudi nad najboljšimi praksami, ki lahko izhajajo iz knjižničnih grafikonov.

Kaj sledi?

Helm 3.0.0-alpha.1 je temelj, na katerem začnemo graditi novo različico Helma. V članku sem opisal nekaj zanimivih funkcij Helm 3. Mnoge med njimi so še v zgodnjih fazah razvoja in to je normalno; Bistvo izdaje alfa je preizkusiti idejo, zbrati povratne informacije prvih uporabnikov in potrditi naše domneve.

Takoj, ko bo izdana alfa različica (ne pozabite, da je to se je že zgodilo — pribl. prev.), bomo začeli sprejemati popravke za Helm 3 od skupnosti. Ustvariti morate trdne temelje, ki bodo omogočali razvoj in sprejemanje novih funkcij ter uporabnikom, da se bodo počutili vključene v proces, tako da bodo odpirali vstopnice in opravljali popravke.

Poskušal sem poudariti nekaj glavnih izboljšav, ki prihajajo v Helm 3, vendar ta seznam nikakor ni izčrpen. Celoten načrt za Helm 3 vključuje funkcije, kot so izboljšane strategije posodabljanja, globlja integracija z registri OCI in uporaba shem JSON za preverjanje vrednosti grafikonov. Načrtujemo tudi čiščenje kodne baze in posodobitev njenih delov, ki so bili zanemarjeni zadnja tri leta.

Če menite, da smo kaj zamudili, bomo radi slišali vaše misli!

Pridružite se naši razpravi Slab kanali:

• #helm-users za vprašanja in preprosto komunikacijo s skupnostjo;
• #helm-dev za razpravo o zahtevah za vleko, kodi in hroščih.

Klepetate lahko tudi v naših tedenskih javnih razpisih za razvijalce ob četrtkih ob 19 po srednjeevropskem času. Sestanki so namenjeni razpravam o vprašanjih, s katerimi se ukvarjajo ključni razvijalci in skupnost, ter temam za razprave v tednu. Vsakdo se lahko pridruži in sodeluje na srečanju. Povezava je na voljo v kanalu Slack #helm-dev.

PS od prevajalca

Preberite tudi na našem blogu:

• «Upravitelj paketov za Kubernetes - Helm: preteklost, sedanjost, prihodnost»;
• «Trezen pogled na Helm 2: "To je to ..."»;
• «Praktični uvod v upravitelja paketov za Kubernetes - Helm»;
• «Nasveti in triki Kubernetes: prenos virov, ki se izvajajo v gruči, v upravljanje Helm 2»;
• «Vadite z dappom. 2. del. Namestitev slik Docker v Kubernetes z uporabo Helma".

Vir: www.habr.com