🥇 Hyrje në Helm 3

Shënim. përkth.: 16 maji i këtij viti shënon një moment historik të rëndësishëm në zhvillimin e menaxherit të paketave për Kubernetes - Helm. Në këtë ditë, u prezantua lëshimi i parë alfa i versionit të ardhshëm madhor të projektit - 3.0. Publikimi i tij do të sjellë ndryshime të rëndësishme dhe të shumëpritura në Helm, për të cilat shumë në komunitetin Kubernetes kanë shpresa të mëdha. Ne vetë jemi një nga këto, pasi përdorim në mënyrë aktive Helm-in për vendosjen e aplikacionit: ne e kemi integruar atë në mjetin tonë për zbatimin e CI/CD werf dhe herë pas here ne japim kontributin tonë në zhvillimin e rrjedhës së sipërme. Ky përkthim kombinon 7 shënime nga blogu zyrtar i Helm, të cilat i kushtohen publikimit të parë alfa të Helm 3 dhe flasin për historinë e projektit dhe veçoritë kryesore të Helm 3. Autori i tyre është Matt "bacongobbler" Fisher, një punonjës i Microsoft-it dhe një nga mirëmbajtësit kryesorë të Helmit.

Më 15 tetor 2015 lindi projekti i njohur tashmë si Helm. Vetëm një vit pas themelimit të tij, komuniteti Helm iu bashkua Kubernetes, ndërsa punonte në mënyrë aktive në Helm 2. Në qershor 2018, Helm iu bashkua CNCF si një projekt në zhvillim (inkubues). Shpejt përpara në të tashmen, dhe publikimi i parë alfa i Helm 3 të ri është në rrugë e sipër. (ky publikim tashmë ka ndodhur në mes të majit - përafërsisht. përkth.).

Në këtë pjesë, unë do të flas se ku filloi gjithçka, si arritëm këtu ku jemi sot, do të prezantoj disa nga veçoritë unike të disponueshme në versionin e parë alfa të Helm 3 dhe do të shpjegoj se si planifikojmë të ecim përpara.

përmbledhje:

historia e krijimit të Helmit;
një lamtumirë e butë për Tiller;
magazinat e grafikëve;
menaxhimi i lëshimit;
ndryshimet në varësitë e grafikut;
grafikët e bibliotekës;
ç'pritet më tej?

Historia e Helmit

lindje

Helm 1 filloi si një projekt me burim të hapur i krijuar nga Deis. Ne ishim një startup i vogël absorbohet Microsoft në pranverë 2017. Projekti ynë tjetër me burim të hapur, i quajtur gjithashtu Deis, kishte një mjet deisctl, e cila u përdor (ndër të tjera) për të instaluar dhe operuar platformën Deis në Grupimi i flotës. Në atë kohë, Fleet ishte një nga platformat e para të orkestrimit të kontejnerëve.

Në mesin e vitit 2015, vendosëm të ndryshonim kursin dhe zhvendosëm Deis (në atë kohë u riemërua Deis Workflow) nga Fleet në Kubernetes. Një nga të parët që u ridizajnua ishte mjeti i instalimit. deisctl. Ne e përdorëm atë për të instaluar dhe menaxhuar Deis Workflow në grupin Fleet.

Helm 1 u krijua në imazhin e menaxherëve të famshëm të paketave si Homebrew, apt dhe yum. Qëllimi i tij kryesor ishte të thjeshtonte detyra të tilla si paketimi dhe instalimi i aplikacioneve në Kubernetes. Helm u prezantua zyrtarisht në 2015 në konferencën KubeCon në San Francisko.

Përpjekja jonë e parë me Helmin funksionoi, por nuk ishte pa disa kufizime serioze. Ai mori një grup manifestesh Kubernetes, të aromatizuara me gjeneratorë si blloqe hyrëse YAML (çështje e përparme)* dhe i ngarkoi rezultatet në Kubernetes.

* Shënim. përkth.: Nga versioni i parë i Helm, sintaksa YAML u zgjodh për të përshkruar burimet e Kubernetes, dhe shabllonet Jinja dhe skriptet Python u mbështetën kur shkruanin konfigurime. Ne kemi shkruar më shumë për këtë dhe strukturën e versionit të parë të Helm në përgjithësi në kapitullin "Një histori e shkurtër e Helm" këtë material.

Për shembull, për të zëvendësuar një fushë në një skedar YAML, duhet të shtoni konstruktin e mëposhtëm në manifest:

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

Është mirë që motorët shabllon ekzistojnë sot, apo jo?

Për shumë arsye, ky instalues i hershëm i Kubernetes kërkonte një listë të koduar të skedarëve manifest dhe ekzekutonte vetëm një sekuencë të vogël, fikse ngjarjesh. Ishte aq e vështirë për t'u përdorur sa ekipi i Deis Workflow R&D e pati të vështirë kur u përpoq të transferonte produktin e tyre në këtë platformë - megjithatë, farat e idesë ishin mbjellë tashmë. Përpjekja jonë e parë ishte një mundësi e shkëlqyer mësimi: kuptuam se ishim vërtet të pasionuar pas krijimit të mjeteve pragmatike që zgjidhin problemet e përditshme për përdoruesit tanë.

Bazuar në përvojën e gabimeve të së kaluarës, ne filluam të zhvillojmë Helm 2.

Bërja e timonit 2

Në fund të vitit 2015, ekipi i Google na kontaktoi. Ata po punonin në një mjet të ngjashëm për Kubernetes. Menaxheri i vendosjes për Kubernetes ishte një port i një mjeti ekzistues që përdorej për platformën e resë kompjuterike të Google. "A do të dëshironim," pyetën ata, "të kalonim disa ditë duke diskutuar ngjashmëritë dhe dallimet?"

Në janar 2016, ekipet e Helm dhe Deployment Manager u takuan në Seattle për të shkëmbyer ide. Negociatat përfunduan me një plan ambicioz: të kombinohen të dy projektet për të krijuar Helm 2. Së bashku me Deis dhe Google, djemtë nga SkippBox (tani pjesë e Bitnami - përafërsisht përkth.), dhe filluam të punonim në Helm 2.

Ne donim të ruanim lehtësinë e përdorimit të Helm, por shtoni sa vijon:

shabllone grafiku për personalizim;
menaxhim brenda grupit për ekipet;
depo e grafikëve të klasit botëror;
format i qëndrueshëm i paketës me opsionin e nënshkrimit;
një angazhim i fortë për versionimin semantik dhe ruajtjen e përputhshmërisë së prapambetur midis versioneve.

Për të arritur këto qëllime, një element i dytë i është shtuar ekosistemit Helm. Ky komponent brenda grupit quhej Tiller dhe ishte përgjegjës për instalimin e diagrameve Helm dhe menaxhimin e tyre.

Që nga publikimi i Helm 2 në 2016, Kubernetes ka shtuar disa risi të mëdha. U shtua kontrolli i aksesit i bazuar në role (RBAC), i cili përfundimisht zëvendësoi Kontrollin e Aksesit të Bazuar në Atribute (ABAC). Llojet e reja të burimeve u prezantuan (Dislokimet ishin ende në beta në atë kohë). Përkufizimet e burimeve të personalizuara (fillimisht të quajtura burime të palëve të treta ose TPR) u shpikën. Dhe më e rëndësishmja, janë shfaqur një sërë praktikash më të mira.

Mes të gjitha këtyre ndryshimeve, Helm vazhdoi t'u shërbente me besnikëri përdoruesve të Kubernetes. Pas tre vjetësh dhe shumë shtesash të reja, ishte e qartë se ishte koha për të bërë ndryshime të rëndësishme në bazën e kodeve për të siguruar që Helm mund të vazhdonte të plotësonte nevojat në rritje të një ekosistemi në zhvillim.

Një lamtumirë e butë për Tiller

Gjatë zhvillimit të Helm 2, ne prezantuam Tiller si pjesë e integrimit tonë me Menaxherin e vendosjes së Google. Tiller luajti një rol të rëndësishëm për ekipet që punonin brenda një grupi të përbashkët: ai lejoi specialistë të ndryshëm që operonin infrastrukturën të ndërveprojnë me të njëjtin grup publikimesh.

Meqenëse kontrolli i aksesit i bazuar në role (RBAC) u aktivizua si parazgjedhje në Kubernetes 1.6, puna me Tiller në prodhim u bë më e vështirë. Për shkak të numrit të madh të politikave të mundshme të sigurisë, pozicioni ynë ka qenë të ofrojmë një konfigurim lejues si parazgjedhje. Kjo i lejoi fillestarët të eksperimentonin me Helm dhe Kubernetes pa pasur nevojë të zhyten më parë në cilësimet e sigurisë. Fatkeqësisht, ky konfigurim leje mund t'i japë përdoruesit një gamë shumë të gjerë lejesh për të cilat ai nuk kishte nevojë. Inxhinierët e DevOps dhe SRE duhej të mësonin hapa shtesë operacionalë kur instalonin Tiller në një grup me shumë qiramarrës.

Pasi mësuam se si komuniteti përdorte Helm-in në situata specifike, kuptuam se sistemi i menaxhimit të lëshimit të Tiller nuk kishte nevojë të mbështetej në një komponent brenda grupit për të ruajtur gjendjen ose për të funksionuar si një qendër qendrore për informacionin e lëshimit. Në vend të kësaj, ne thjesht mund të marrim informacion nga serveri Kubernetes API, të gjenerojmë një grafik në anën e klientit dhe të ruajmë një regjistrim të instalimit në Kubernetes.

Qëllimi kryesor i Tiller mund të ishte arritur pa Tiller, kështu që një nga vendimet tona të para në lidhje me Helm 3 ishte braktisja e plotë e Tiller.

Me largimin e Tiller-it, modeli i sigurisë së Helm-it është thjeshtuar rrënjësisht. Helm 3 tani mbështet të gjitha metodat moderne të sigurisë, identitetit dhe autorizimit të Kubernetes aktuale. Lejet e timonit përcaktohen duke përdorur skedari kubeconfig. Administratorët e grupeve mund të kufizojnë të drejtat e përdoruesve në çdo nivel të hollësishme. Publikimet ruhen ende brenda grupit dhe pjesa tjetër e funksionalitetit të Helm mbetet e paprekur.

Depot e grafikëve

Në një nivel të lartë, një depo grafiku është një vend ku grafikët mund të ruhen dhe ndahen. Klienti Helm paketon dhe dërgon grafikët në depo. E thënë thjesht, një depo e grafikëve është një server primitiv HTTP me një skedar index.yaml dhe disa grafiqe të paketuara.

Ndërsa ka disa avantazhe për API-në e Depove të Grafikëve që plotëson kërkesat më themelore të ruajtjes, ka edhe disa disavantazhe:

Depot e grafikëve nuk janë në përputhje me shumicën e zbatimeve të sigurisë që kërkohen në një mjedis prodhimi. Pasja e një API standarde për vërtetimin dhe autorizimin është jashtëzakonisht e rëndësishme në skenarët e prodhimit.
Mjetet e origjinës së grafikut Helm, të përdorura për të nënshkruar, verifikuar integritetin dhe origjinën e një grafiku, janë një pjesë opsionale e procesit të publikimit të Grafikut.
Në skenarët me shumë përdorues, i njëjti grafik mund të ngarkohet nga një përdorues tjetër, duke dyfishuar hapësirën e nevojshme për të ruajtur të njëjtën përmbajtje. Depo më të zgjuara janë zhvilluar për të zgjidhur këtë problem, por ato nuk janë pjesë e specifikimit formal.
Përdorimi i një skedari të vetëm indeks për kërkimin, ruajtjen e meta të dhënave dhe marrjen e grafikëve e ka bërë të vështirë zhvillimin e zbatimeve të sigurta me shumë përdorues.

Projekt Shpërndarja Docker (i njohur gjithashtu si Docker Registry v2) është pasardhësi i Docker Registry dhe në thelb vepron si një grup mjetesh për paketimin, dërgimin, ruajtjen dhe shpërndarjen e imazheve të Docker. Shumë shërbime të mëdha cloud ofrojnë produkte të bazuara në shpërndarje. Falë kësaj vëmendjeje të shtuar, projekti Distribution ka përfituar nga vite përmirësimesh, praktika më të mira të sigurisë dhe testime në terren që e kanë bërë atë një nga heronjtë më të suksesshëm të botës me burim të hapur.

Por a e dini se Projekti i Shpërndarjes ishte krijuar për të shpërndarë çdo formë të përmbajtjes, jo vetëm imazhe të kontejnerëve?

Falë përpjekjeve Iniciativa e Open Container (ose OCI), tabelat e Helm mund të vendosen në çdo shembull të Shpërndarjes. Për momentin, ky proces është eksperimental. Mbështetja e hyrjes dhe veçoritë e tjera të nevojshme për një Helm 3 të plotë janë një punë në progres, por ne jemi të ngazëllyer të mësojmë nga zbulimet që ekipet e OCI dhe Distribution kanë bërë gjatë viteve. Dhe nëpërmjet mentorimit dhe udhëzimit të tyre, ne mësojmë se si është të operosh një shërbim shumë të disponueshëm në shkallë.

Ekziston një përshkrim më i detajuar i disa ndryshimeve të ardhshme në magazinat e diagramit Helm по ссылке.

Menaxhimi i lëshimit

Në Helm 3, gjendja e aplikacionit gjurmohet brenda grupit nga një palë objektesh:

lëshimi i objektit - paraqet një shembull të aplikacionit;
Sekreti i versionit të lëshimit - përfaqëson gjendjen e dëshiruar të aplikacionit në një moment të caktuar kohor (për shembull, lëshimi i një versioni të ri).

Вызов helm install krijon një objekt lëshimi dhe sekret të versionit të lëshimit. Thirrni helm upgrade kërkon një objekt lëshimi (të cilin mund ta ndryshojë) dhe krijon një sekret të ri të versionit të lëshimit që përmban vlerat e reja dhe një manifest të përgatitur.

Objekti i lëshimit përmban informacion rreth lëshimit, ku lëshimi është një instalim specifik i një grafiku të emërtuar dhe vlerave. Ky objekt përshkruan meta të dhënat e nivelit të lartë rreth lëshimit. Objekti i lëshimit vazhdon gjatë gjithë ciklit jetësor të aplikacionit dhe është pronar i të gjitha sekreteve të versionit të lëshimit, si dhe të gjitha objekteve që krijohen drejtpërdrejt nga grafiku Helm.

Sekreti i versionit të lëshimit lidh një version me një sërë rishikimesh (instalim, përditësime, rikthime, fshirje).

Në Helm 2, rishikimet ishin jashtëzakonisht të qëndrueshme. Thirrni helm install krijuar v1, përditësimi (përmirësimi) pasues - v2, e kështu me radhë. Sekreti i versionit të lëshimit dhe lëshimit janë shembur në një objekt të vetëm të njohur si rishikim. Rishikimet u ruajtën në të njëjtën hapësirë emri si Tiller, që do të thoshte se çdo version ishte "global" për sa i përket hapësirës së emrave; si rezultat, vetëm një shembull i emrit mund të përdoret.

Në Helm 3, çdo version shoqërohet me një ose më shumë sekrete të versionit të lëshimit. Objekti i lëshimit përshkruan gjithmonë lëshimin aktual të vendosur në Kubernetes. Çdo sekret versioni i lëshimit përshkruan vetëm një version të atij lëshimi. Një përmirësim, për shembull, do të krijojë një sekret të versionit të ri të lëshimit dhe më pas do të ndryshojë objektin e lëshimit për të treguar atë version të ri. Në rastin e një rikthimi, mund të përdorni sekretet e versionit të mëparshëm të lëshimit për ta rikthyer versionin në një gjendje të mëparshme.

Pasi Tiller braktiset, Helm 3 ruan të dhënat e lëshuara në të njëjtën hapësirë emri si lëshimi. Ky ndryshim ju lejon të instaloni një grafik me të njëjtin emër lëshimi në një hapësirë emri të ndryshme dhe të dhënat ruhen midis përditësimeve/rinisjeve të grupit në etj. Për shembull, mund ta instaloni WordPress në hapësirën e emrave "foo" dhe më pas në hapësirën e emrave "bar", dhe të dy versionet mund të emërtohen "wordpress".

Ndryshimet në varësitë e grafikut

Grafikët e paketuar (duke përdorur helm package) për përdorim me Helm 2 mund të instalohet me Helm 3, megjithatë rrjedha e punës e zhvillimit të grafikut është rishikuar plotësisht, kështu që duhen bërë disa ndryshime për të vazhduar zhvillimin e grafikut me Helm 3. Në veçanti, sistemi i menaxhimit të varësisë së grafikut ka ndryshuar.

Sistemi i menaxhimit të varësisë së grafikut ka lëvizur nga requirements.yaml и requirements.lock mbi Chart.yaml и Chart.lock. Kjo do të thotë se grafikët që përdorën komandën helm dependency, kërkojnë disa konfigurime për të punuar në Helm 3.

Le të shohim një shembull. Le të shtojmë një varësi në grafikun në Helm 2 dhe të shohim se çfarë ndryshon kur kalojmë në Helm 3.

Në Helm 2 requirements.yaml dukej kështu:

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

Në Helm 3, e njëjta varësi do të pasqyrohet në tuaj Chart.yaml:

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

Grafikët ende shkarkohen dhe vendosen në drejtori charts/, pra nëngrafikë (nëngrafikë), shtrirë në katalog charts/, do të vazhdojë të punojë pa ndryshime.

Prezantimi i grafikëve të bibliotekës

Helm 3 mbështet një klasë tabelash të quajtura grafikët e bibliotekës (grafiku i bibliotekës). Ky grafik përdoret nga grafikët e tjerë, por nuk krijon më vete asnjë artefakte lëshimi. Modelet e grafikëve të bibliotekës mund të deklarojnë vetëm elementë define. Përmbajtja tjetër thjesht shpërfillet. Kjo i lejon përdoruesit të ripërdorin dhe të ndajnë copa kodi që mund të përdoren nëpër grafikët e shumtë, duke shmangur kështu dyfishimin dhe respektimin e parimit E THAT.

Grafikët e bibliotekës janë deklaruar në seksion dependencies në dosje Chart.yaml. Instalimi dhe menaxhimi i tyre nuk ndryshon nga grafikët e tjerë.

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

Ne jemi të ngazëllyer për rastet e përdorimit që ky komponent do të hapë për zhvilluesit e grafikëve, si dhe për praktikat më të mira që mund të dalin nga grafikët e bibliotekës.

Çka më tej?

Helm 3.0.0-alpha.1 është themeli mbi të cilin fillojmë të ndërtojmë një version të ri të Helm. Në artikull përshkrova disa veçori interesante të Helm 3. Shumë prej tyre janë ende në fazat e hershme të zhvillimit dhe kjo është normale; Qëllimi i një lëshimi alfa është të testojë idenë, të mbledhë reagime nga përdoruesit e hershëm dhe të konfirmojë supozimet tona.

Sapo të lëshohet versioni alfa (Mos harroni se kjo është tashmë ka ndodhur - përafërsisht. përkth.), do të fillojmë të pranojmë arna për Helm 3 nga komuniteti. Ju duhet të krijoni një bazë të fortë që lejon zhvillimin dhe miratimin e funksionalitetit të ri, dhe që përdoruesit të ndihen të përfshirë në proces duke hapur biletat dhe duke bërë rregullime.

Jam përpjekur të nënvizoj disa nga përmirësimet kryesore që vijnë në Helm 3, por kjo listë nuk është aspak shteruese. Udhërrëfyesi i plotë për Helm 3 përfshin veçori të tilla si strategjitë e përmirësuara të përditësimit, integrim më të thellë me regjistrat OCI dhe përdorimin e skemave JSON për të vërtetuar vlerat e grafikut. Ne gjithashtu planifikojmë të pastrojmë bazën e kodeve dhe të përditësojmë pjesët e saj që janë lënë pas dore për tre vitet e fundit.

Nëse mendoni se kemi humbur diçka, do të donim të dëgjonim mendimet tuaja!

Bashkohuni në diskutimin tonë Kanalet e dobëta:

#helm-users për pyetje dhe komunikim të thjeshtë me komunitetin;
#helm-dev për të diskutuar kërkesat për tërheqje, kodin dhe gabimet.

Ju gjithashtu mund të bisedoni në Thirrjet tona javore të Zhvilluesve Publikë të Enjten në orën 19:30 MSK. Takimet i dedikohen diskutimit të çështjeve mbi të cilat po punojnë zhvilluesit kryesorë dhe komuniteti, si dhe tema të diskutimit për javën. Çdokush mund të bashkohet dhe të marrë pjesë në takim. Lidhja disponohet në kanalin Slack #helm-dev.

PS nga përkthyesi

Lexoni edhe në blogun tonë:

Burimi: www.habr.com

Prezantimi i Helm 3