Pristatome Helm 3

Pastaba. vert.: Šių metų gegužės 16 d. yra svarbus etapas kuriant Kubernetes - Helm paketų tvarkyklę. Šią dieną buvo pristatytas pirmasis būsimos didžiosios projekto versijos – 3.0 – alfa leidimas. Jo išleidimas atneš reikšmingų ir ilgai lauktų Helm pokyčių, dėl kurių daugelis Kubernetes bendruomenės narių tikisi daug. Mes patys esame vieni iš jų, nes aktyviai naudojame „Helm“ programoms diegti: integravome jį į savo CI / CD diegimo įrankį. werf ir karts nuo karto prisidedame prie aukštupio plėtros. Šiame vertime sujungtos 7 pastabos iš oficialaus „Helm“ tinklaraščio, skirtos pirmajai „Helm 3“ alfa versijai ir pasakojančios apie projekto istoriją bei pagrindines „Helm 3“ savybes. Jų autorius yra Mattas „bacongobbler“ Fisheris, „Microsoft“ darbuotojas. ir vienas iš pagrindinių Helm prižiūrėtojų.

15 m. spalio 2015 d. gimė projektas, dabar žinomas kaip Helm. Praėjus vos metams nuo įkūrimo, Helmo bendruomenė prisijungė prie „Kubernetes“ ir aktyviai dirbo prie „Helm 2“. 2018 m. birželio mėn. prisijungė prie CNCF kaip vystomas (inkubuojamas) projektas. Greitai pasukame į dabartį, o pirmasis naujojo „Helm 3“ alfa versijos leidimas jau yra pakeliui. (šis leidimas jau įvyko gegužės viduryje – apytiksliai. vertimas.).

Šiame kūrinyje papasakosiu apie tai, nuo ko viskas prasidėjo, kaip mes atsidūrėme ten, kur esame šiandien, pristatysiu kai kurias unikalias pirmojo „Helm 3“ alfa leidimo funkcijas ir paaiškinsiu, kaip planuojame judėti į priekį.

Santrauka:

• Helmo sukūrimo istorija;
• švelnus atsisveikinimas su Tileriu;
• diagramų saugyklos;
• išleidimo valdymas;
• diagramų priklausomybių pokyčiai;
• bibliotekų diagramos;
• kas toliau?

Helmo istorija

Gimimas

„Helm 1“ prasidėjo kaip atvirojo kodo projektas, kurį sukūrė Deisas. Buvome mažas startuolis absorbuojamas „Microsoft“ 2017 m. pavasarį. Kitas mūsų atvirojo kodo projektas, taip pat pavadintas Deis, turėjo įrankį deisctl, kuris buvo naudojamas (be kita ko) Deis platformai įdiegti ir valdyti Laivyno klasteris. Tuo metu „Fleet“ buvo viena pirmųjų konteinerių orkestravimo platformų.

2015 m. viduryje nusprendėme pakeisti kursą ir „Deis“ (tuo metu pervadintas į „Deis Workflow“) iš „Fleet“ į „Kubernetes“. Vienas iš pirmųjų, kuris buvo perkurtas, buvo diegimo įrankis. deisctl. Jį naudojome diegdami ir tvarkydami „Deis Workflow“ „Fleet“ klasteryje.

„Helm 1“ buvo sukurtas pagal garsių paketų tvarkytojų, tokių kaip „Homebrew“, „apt“ ir „yum“, įvaizdį. Pagrindinis jo tikslas buvo supaprastinti tokias užduotis kaip pakavimas ir programų diegimas „Kubernetes“. Helmas buvo oficialiai pristatytas 2015 m. KubeCon konferencijoje San Franciske.

Mūsų pirmasis bandymas su Helmu pavyko, tačiau tai nebuvo be rimtų apribojimų. Jis paėmė Kubernetes manifestų rinkinį, pagardintą generatoriais kaip įvadinius YAML blokus (priekinis dalykas)* ir įkėlė rezultatus į „Kubernetes“.

* Pastaba. vert.: Nuo pirmosios Helm versijos YAML sintaksė buvo pasirinkta aprašyti Kubernetes išteklius, o rašant konfigūracijas buvo palaikomi Jinja šablonai ir Python scenarijai. Daugiau apie tai ir apskritai pirmosios Helmo versijos struktūrą rašėme skyriuje „Trumpa Helmo istorija“ ši medžiaga.

Pavyzdžiui, norėdami pakeisti lauką YAML faile, manifeste turėjote pridėti šią konstrukciją:

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

Puiku, kad šiandien egzistuoja šablonų varikliai, ar ne?

Dėl daugelio priežasčių šiai ankstyvajai „Kubernetes“ diegimo programai reikėjo sunkiai užkoduoto manifestų failų sąrašo ir įvykdė tik nedidelę, fiksuotą įvykių seką. Juo buvo taip sunku naudotis, kad Deis Workflow R&D komandai sunkiai sekėsi bandant perkelti savo produktą į šią platformą – tačiau idėjos sėklos jau buvo pasėtos. Pirmasis mūsų bandymas buvo puiki mokymosi galimybė: supratome, kad tikrai aistringai siekiame kurti pragmatiškus įrankius, kurie sprendžia kasdienes vartotojų problemas.

Remdamiesi praeities klaidų patirtimi, pradėjome kurti Helm 2.

Padaryti vairą 2

2015 m. pabaigoje „Google“ komanda susisiekė su mumis. Jie dirbo su panašiu „Kubernetes“ įrankiu. „Kubernetes“ diegimo tvarkyklė buvo esamo įrankio, kuris buvo naudojamas „Google Cloud Platform“, prievadas. „Ar norėtume, – paklausė jie, – praleisti kelias dienas aptariant panašumus ir skirtumus?

2016 m. sausio mėn. „Helm“ ir „Deployment Manager“ komandos susitiko Sietle pasikeisti idėjomis. Derybos baigėsi ambicingu planu: sujungti abu projektus ir sukurti Helm 2. Kartu su Deisu ir Google vaikinai iš „SkippBox“. (dabar Bitnami dalis – apytikslis vertimas), ir pradėjome dirbti su Helm 2.

Norėjome, kad „Helm“ būtų patogus naudoti, tačiau pridėkite:

• Diagramų šablonai tinkinimui;
• klasterio vidinis komandų valdymas;
• pasaulinio lygio diagramų saugykla;
• stabilus paketo formatas su parašo galimybe;
• tvirtas įsipareigojimas semantiniam versijų kūrimui ir versijų atgalinio suderinamumo palaikymui.

Norint pasiekti šiuos tikslus, Helmo ekosistemoje buvo pridėtas antras elementas. Šis klasterio komponentas buvo vadinamas „Tiller“ ir buvo atsakingas už „Helm“ diagramų diegimą ir jų valdymą.

Nuo Helm 2 išleidimo 2016 m., Kubernetes pridėjo keletą pagrindinių naujovių. Pridėtas vaidmenimis pagrįstas prieigos valdymas (RBAC), kuris galiausiai pakeitė atributais pagrįstą prieigos valdymą (ABAC). Buvo pristatyti nauji išteklių tipai (tuo metu diegimas vis dar buvo beta versijos). Buvo išrastos tinkintos išteklių apibrėžtys (iš pradžių vadinamos trečiųjų šalių ištekliais arba TPR). Ir, svarbiausia, atsirado geriausios praktikos rinkinys.

Įvykus visiems šiems pakeitimams, Helm ir toliau ištikimai aptarnavo Kubernetes vartotojus. Po trejų metų ir daugybės naujų papildymų tapo aišku, kad laikas atlikti reikšmingus kodų bazės pakeitimus, siekiant užtikrinti, kad „Helm“ galėtų ir toliau tenkinti augančius besivystančios ekosistemos poreikius.

Švelnus atsisveikinimas su Tileriu

Kurdami „Helm 2“ pristatėme „Tiller“ kaip dalį mūsų integracijos su „Google“ diegimo tvarkykle. „Tiller“ atliko svarbų vaidmenį komandoms, dirbančioms bendrame klasteryje: jis leido skirtingiems infrastruktūrą eksploatuojantiems specialistams sąveikauti su tuo pačiu leidimų rinkiniu.

Kadangi „Kubernetes 1.6“ versijoje pagal numatytuosius nustatymus buvo įjungtas vaidmenimis pagrįstas prieigos valdymas (RBAC), dirbti su „Tiller“ gamyboje tapo sunkiau. Dėl daugybės galimų saugos strategijų, mūsų pozicija buvo pagal numatytuosius nustatymus pasiūlyti leistiną konfigūraciją. Tai leido naujokams eksperimentuoti su „Helm“ ir „Kubernetes“, pirmiausia nesigilindami į saugos nustatymus. Deja, ši leidimo konfigūracija gali suteikti vartotojui per daug įvairių leidimų, kurių jiems nereikėjo. „DevOps“ ir SRE inžinieriai, diegdami „Tiller“ kelių nuomininkų grupėje, turėjo išmokti papildomų veiklos veiksmų.

Sužinoję, kaip bendruomenė naudoja „Helm“ konkrečiose situacijose, supratome, kad „Tiller“ leidimų valdymo sistemai nereikia pasikliauti klasterio komponentu, kad išlaikytų būseną arba veiktų kaip centrinis išleidimo informacijos centras. Vietoj to galėtume tiesiog gauti informaciją iš Kubernetes API serverio, sugeneruoti diagramą kliento pusėje ir išsaugoti diegimo įrašą Kubernetes.

Pagrindinis Tiller tikslas galėjo būti pasiektas be Tilerio, todėl vienas iš pirmųjų mūsų sprendimų dėl Helm 3 buvo visiškai atsisakyti Tilerio.

Kai Tilerio nebeliko, Helmo saugumo modelis buvo radikaliai supaprastintas. „Helm 3“ dabar palaiko visus šiuolaikinius dabartinės „Kubernetes“ saugos, tapatybės ir autorizacijos metodus. Vairo leidimai nustatomi naudojant kubeconfig failą. Klasterių administratoriai gali apriboti vartotojų teises iki bet kokio detalumo lygio. Leidimai vis dar išsaugomi klasteryje, o likusios Helm funkcijos lieka nepakitusios.

Diagramų saugyklos

Aukštu lygiu diagramų saugykla yra vieta, kur diagramas galima saugoti ir bendrinti. „Helm“ klientas supakuoja ir siunčia diagramas į saugyklą. Paprasčiau tariant, diagramų saugykla yra primityvus HTTP serveris su index.yaml failu ir kai kuriomis supakuotomis diagramomis.

Nors yra tam tikrų diagramų saugyklos API privalumų, atitinkančių pagrindinius saugojimo reikalavimus, yra ir keletas trūkumų:

• Diagramų saugyklos nesuderinamos su dauguma saugos diegimų, reikalingų gamybinėje aplinkoje. Gamybos scenarijuose itin svarbu turėti standartinę API autentifikavimui ir autorizavimui.
• „Helm“ diagramos kilmės įrankiai, naudojami pasirašyti, patikrinti diagramos vientisumą ir kilmę, yra neprivaloma diagramos paskelbimo proceso dalis.
• Kelių vartotojų scenarijuose tą pačią diagramą gali įkelti kitas vartotojas, o tai padvigubina vietos, reikalingos tam pačiam turiniui saugoti, kiekį. Šiai problemai išspręsti buvo sukurtos pažangesnės saugyklos, tačiau jos nėra oficialios specifikacijos dalis.
• Naudojant vieną indekso failą paieškai, metaduomenų saugojimui ir diagramų nuskaitymui, buvo sunku sukurti saugius keliems naudotojams skirtus diegimus.

Projektas Docker platinimas (taip pat žinomas kaip „Docker Registry v2“) yra „Docker Registry“ įpėdinis ir iš esmės veikia kaip „Docker“ vaizdų pakavimo, siuntimo, saugojimo ir pristatymo įrankių rinkinys. Daugelis didelių debesų paslaugų siūlo platinimo produktus. Dėl šio didesnio dėmesio Platinimo projektas gavo naudos iš daugelio metų patobulinimų, geriausios saugos praktikos ir bandymų vietoje, dėl kurių jis tapo vienu sėkmingiausių neapdainuotų atvirojo kodo pasaulio herojų.

Bet ar žinojote, kad platinimo projektas buvo skirtas platinti bet kokios formos turinį, o ne tik konteinerio vaizdus?

Dėka pastangų Atidarykite konteinerių iniciatyvą (arba OCI), vairo diagramas galima įdėti į bet kurį platinimo egzempliorių. Kol kas šis procesas yra eksperimentinis. Prisijungimo palaikymas ir kitos funkcijos, reikalingos visam „Helm 3“, yra nebaigtos, tačiau džiaugiamės galėdami pasimokyti iš atradimų, kuriuos per daugelį metų padarė OCI ir Distribution komandos. Be to, jiems patardami ir patardami sužinome, ką reiškia teikti labai prieinamą paslaugą dideliu mastu.

Galimas išsamesnis kai kurių būsimų Helm diagramų saugyklų pakeitimų aprašymas по ссылке.

Išleidimo valdymas

„Helm 3“ programos būsena klasteryje stebima poros objektų:

• išleidimo objektas – reiškia programos egzempliorių;
• leidimo versijos paslaptis – nurodo norimą programos būseną konkrečiu momentu (pavyzdžiui, išleidžiant naują versiją).

Вызов helm install sukuria leidimo objektą ir išleidimo versijos paslaptį. Skambinti helm upgrade reikalauja leidimo objekto (kurį jis gali pakeisti) ir sukuria naujos leidimo versijos paslaptį su naujomis reikšmėmis ir paruoštu manifestu.

Išleidimo objekte yra informacija apie leidimą, kur leidimas yra konkretus pavadintos diagramos ir reikšmių diegimas. Šis objektas apibūdina aukščiausio lygio metaduomenis apie leidimą. Išleidimo objektas išlieka per visą programos gyvavimo ciklą ir yra visų leidimo versijos paslapčių, taip pat visų objektų, tiesiogiai sukurtų Helm diagramos, savininkas.

Leidimo versijos paslaptis susieja leidimą su daugybe pataisymų (diegimas, naujinimai, grąžinimai, ištrynimas).

„Helm 2“ peržiūros buvo labai nuoseklios. Skambinti helm install sukurtas v1, vėlesnis atnaujinimas (atnaujinimas) - v2 ir pan. Išleidimo ir išleidimo versijos paslaptis buvo sutraukta į vieną objektą, žinomą kaip peržiūra. Versijos buvo saugomos toje pačioje vardų erdvėje kaip ir Tiller, o tai reiškė, kad kiekvienas leidimas buvo „pasaulinis“ vardų erdvės požiūriu; dėl to galėjo būti naudojamas tik vienas pavadinimo egzempliorius.

„Helm 3“ versijoje kiekvienas leidimas yra susietas su viena ar daugiau leidimo versijos paslapčių. Išleidimo objektas visada aprašo dabartinį „Kubernetes“ įdiegtą leidimą. Kiekviena leidimo versijos paslaptis apibūdina tik vieną to leidimo versiją. Pavyzdžiui, naujinimas sukurs naujos leidimo versijos paslaptį ir pakeis leidimo objektą, kad jis nurodytų tą naują versiją. Atkūrimo atveju galite naudoti ankstesnės leidimo versijos paslaptis, kad grąžintumėte leidimą į ankstesnę būseną.

Atsisakius „Tiller“, „Helm 3“ išleidimo duomenis saugo toje pačioje vardų erdvėje kaip ir leidimas. Šis pakeitimas leidžia įdiegti diagramą su tuo pačiu leidimo pavadinimu kitoje vardų srityje, o duomenys išsaugomi tarp grupių naujinimų / pakartotinio paleidimo į etcd. Pavyzdžiui, galite įdiegti „WordPress“ vardų srityje „foo“, tada – „bar“ vardų srityje, o abu leidimai gali būti pavadinti „wordpress“.

Diagramos priklausomybių pakeitimai

Diagramos supakuotos (naudojant helm package), skirtą naudoti su Helm 2, galima įdiegti su Helm 3, tačiau diagramos kūrimo darbo eiga buvo visiškai pakeista, todėl reikia atlikti kai kuriuos pakeitimus, kad būtų galima tęsti diagramų kūrimą naudojant Helm 3. Visų pirma pasikeitė diagramų priklausomybės valdymo sistema.

Diagramos priklausomybės valdymo sistema perkelta iš requirements.yaml и requirements.lock apie Chart.yaml и Chart.lock. Tai reiškia, kad diagramos, kuriose buvo naudojama komanda helm dependency, norint dirbti „Helm 3“, reikia tam tikros sąrankos.

Pažiūrėkime į pavyzdį. Pridėkite priklausomybę prie Helm 2 diagramos ir pažiūrėkime, kas pasikeičia pereinant prie 3.

2 vaire requirements.yaml atrodė taip:

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

„Helm 3“ ta pati priklausomybė atsispindės ir jūsų Chart.yaml:

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

Diagramos vis dar atsisiunčiamos ir dedamos į katalogą charts/, taigi antrinės diagramos (subschemos), guli kataloge charts/, dirbs be pakeitimų.

Pristatome bibliotekų diagramas

Helm 3 palaiko diagramų klasę, vadinamą bibliotekos diagramomis (bibliotekos diagrama). Ši diagrama naudojama kitose diagramose, tačiau ji pati nesukuria jokių išleidimo artefaktų. Bibliotekos diagramos šablonai gali deklaruoti tik elementus define. Kitas turinys tiesiog ignoruojamas. Tai leidžia vartotojams pakartotinai naudoti ir bendrinti kodo fragmentus, kurie gali būti naudojami keliose diagramose, taip išvengiant dubliavimo ir laikantis principo. SAUSAS.

Skyriuje deklaruojamos bibliotekos diagramos dependencies faile Chart.yaml. Jų diegimas ir valdymas niekuo nesiskiria nuo kitų diagramų.

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

Džiaugiamės dėl naudojimo atvejų, kuriuos šis komponentas atvers diagramų kūrėjams, ir apie geriausią praktiką, kuri gali atsirasti iš bibliotekos diagramų.

Kas toliau?

Helm 3.0.0-alpha.1 yra pagrindas, ant kurio pradedame kurti naują Helm versiją. Straipsnyje aprašiau keletą įdomių Helm 3 ypatybių. Daugelis jų vis dar yra ankstyvosiose kūrimo stadijose ir tai normalu; Alfa versijos leidimo tikslas – išbandyti idėją, surinkti atsiliepimus iš pirmųjų vartotojų ir patvirtinti mūsų prielaidas.

Kai tik bus išleista alfa versija (atminkite, kad tai yra jau įvyko - apytiksliai vertimas.), pradėsime priimti Helm 3 pataisas iš bendruomenės. Turite sukurti tvirtą pagrindą, kuris leistų kurti ir pritaikyti naujas funkcijas, o vartotojai jaustųsi dalyvaujantys procese atidarydami bilietus ir atlikdami pataisymus.

Bandžiau pabrėžti kai kuriuos svarbiausius Helm 3 patobulinimus, tačiau šis sąrašas jokiu būdu nėra baigtinis. Visas „Helm 3“ planas apima tokias funkcijas kaip patobulintos naujinimo strategijos, gilesnė integracija su OCI registrais ir JSON schemų naudojimas diagramos vertėms patvirtinti. Taip pat planuojame išvalyti kodų bazę ir atnaujinti jos dalis, kurios buvo apleistos pastaruosius trejus metus.

Jei jaučiate, kad kažką praleidome, norėtume išgirsti jūsų mintis!

Prisijunkite prie mūsų diskusijos Laisvi kanalai:

• #helm-users už klausimus ir paprastą bendravimą su bendruomene;
• #helm-dev aptarti ištraukimo užklausas, kodą ir klaidas.

Taip pat galite kalbėtis mūsų savaitiniuose viešuose kūrėjų skambučiuose ketvirtadieniais 19:30 MSK. Susitikimai skirti aptarti klausimus, kuriuos sprendžia pagrindiniai kūrėjai ir bendruomenė, taip pat savaitės diskusijų temas. Kiekvienas gali prisijungti ir dalyvauti susirinkime. Nuoroda pasiekiama „Slack“ kanale #helm-dev.

PS iš vertėjo

Taip pat skaitykite mūsų tinklaraštyje:

• «„Kubernetes“ paketų tvarkyklė – „Helm“: praeitis, dabartis, ateitis»;
• «Blaivus žvilgsnis į Helm 2: „Štai kas tai yra...“»;
• «Praktinis įvadas į Kubernetes paketų tvarkyklę – Helm»;
• «„Kubernetes“ patarimai ir gudrybės: išteklių, veikiančių klasteryje, perkėlimas į „Helm 2“ valdymą»;
• «Treniruokitės su dapp. 2 dalis. Docker vaizdų diegimas Kubernetes naudojant Helm".

Šaltinis: www.habr.com