ShĂ«n. pĂ«rk.: 16 maj 2023 â njĂ« ngjarje e rĂ«ndĂ«sishme nĂ« zhvillimin e menaxherit tĂ« paketave pĂ«r Kubernetes â Helm. NĂ« kĂ«tĂ« ditĂ« u prezantua versioni i parĂ« alpha i njĂ« versioni tĂ« rĂ«ndĂ«sishĂ«m tĂ« projektit â 3.0. Dalja e tij do tĂ« sjellĂ« ndryshime tĂ« konsiderueshme dhe tĂ« shumĂ«pritura nĂ« Helm, pĂ«r tĂ« cilat shumĂ« nĂ« komunitetin Kubernetes kanĂ« shpresĂ« tĂ« madhe. Ne vetĂ« jemi pjesĂ« e kĂ«saj, pasi e pĂ«rdorim aktivisht Helm pĂ«r tĂ« realizuar aplikacione: e kemi integruar atĂ« nĂ« mjetin tonĂ« pĂ«r realizimin e CI/CD dhe nga rasti nĂ« rast, kontribuojmĂ« me mundĂ«sitĂ« tona nĂ« zhvillimin e upstream. Ky pĂ«rkthim bashkon 7 shĂ«nime nga blogu zyrtar i Helm, tĂ« cilat janĂ« dedikuar pĂ«r versionin e parĂ« alpha tĂ« Helm 3 dhe tregojnĂ« historinĂ« e projektit dhe karakteristikat kryesore tĂ« Helm 3. Autori i tyre Ă«shtĂ« Matt «bacongobbler» Fisher, njĂ« punonjĂ«s i Microsoft dhe njĂ« nga mbajtĂ«sit kryesorĂ« tĂ« Helm.
15 tetor 2015 lindi projekti, tani i njohur si Helm. VetĂ«m njĂ« vit pas themelimit, komuniteti i Helm u bashkua me Kubernetes, duke punuar aktivisht nĂ« Helm 2. NĂ« qershor 2018, Helm si njĂ« projekt nĂ« zhvillim (incubating). Tani po shkojmĂ« nĂ« tĂ« tashmen â dhe ja, po afrohet versioni i parĂ« alpha i Helm 3 (ky version nĂ« mes tĂ« majit â shĂ«n. i pĂ«rk..
Në këtë material do të flas për fillimet tona, si arritëm në këtë fazë, do të paraqes disa karakteristika unike që janë disponible në versionin e parë alfa të Helm 3 dhe do të shpjegoj se si planifikojmë të zhvillohemi më tej.
PĂ«rmbledhje:
- historia e krijimit të Helm;
- ndarje e butë nga Tiller;
- repozitorët e chart-ëve;
- menaxhimi i lëshimeve;
- ndryshimet në varësitë e chart-ëve;
- chart-a të bibliotekës;
- çfarë duhet të bëni më pas?
Historia e krijimit të Helm
Lindja
Helm 1 filloi si një projekt Open Source, i krijuar nga kompania Deis. Ne ishim një startup i vogël, nga Microsoft pranverën e vitit 2017. Projekti ynë tjetër Open Source, gjithashtu me emrin Deis, kishte një mjet deisctl, i cili përdorej (përveç të tjerave) për të instaluar dhe menaxhuar platformën Deis në . Në atë kohë, Fleet ishte një nga platformat e para për orkestrimin e kontejnerëve.
Në mes të vitit 2015, ne vendosëm të ndryshojmë kursin dhe e kaluam Deis (në atë kohë i riemëruar në Deis Workflow) nga Fleet në Kubernetes. Një nga të parët ishte riprojektimi i mjetit të instalimit deisctl. E përdorëm atë për instalimin dhe menaxhimin e Deis Workflow në klasterin Fleet.
Helm 1 është krijuar sipas modeleve të menaxherëve të njohur të paketave, si Homebrew, apt dhe yum. Qëllimi kryesor i tij ishte të thjeshtonte detyra të tilla si paketimi dhe instalimi i aplikacioneve në Kubernetes. Zyrtarisht, Helm u prezantua në vitin 2015 në konferencën KubeCon në San Francisco.
Përpjekja jonë e parë me Helm kishte sukses, megjithatë nuk kaluam pa kufizime serioze. Ai merrte një grup manifestesh Kubernetes, të pasuruara me gjenerues si input YAML. (front-matter)*, dhe ngarkohej rezultati në Kubernetes.
* Shën. përk.: Nga versioni i parë të Helm, sintaksa YAML ishte zgjedhur për përshkrimin e burimeve Kubernetes, dhe në shkruarjen e konfigurimeve ishin mbështetur shabllonat Jinja dhe skenarët Python. Më shumë rreth kësaj dhe ndërtimit të versionit të parë të Helm në përgjithësi, ne kemi shkruar në kapitullin "Një histori e shkurtër e Helm". .
Për shembull, për të zëvendësuar një fushë në skedarin YAML, duhet të shtoni në manifest këtë konstrukcion:
#helm:generate sed -i -e s|ubuntu-debootstrap|fluffy-bunny| my/pod.yamlĂshtĂ« e mrekullueshme qĂ« sot ekzistojnĂ« shabllonizues, apo jo?
PĂ«r shumĂ« arsye, ky instalues i hershĂ«m tĂ« Kubernetes kĂ«rkoi njĂ« listĂ« tĂ« caktuar tĂ« skedarĂ«ve tĂ« manifestit dhe ekzekutoi vetĂ«m njĂ« sekuencĂ« tĂ« vogĂ«l tĂ« ngjarjeve tĂ« fiksuara. PĂ«rdorimi i tij ishte aq i vĂ«shtirĂ«, saqĂ« ekipi R&D i Deis Workflow kishte vĂ«shtirĂ«si kur pĂ«rpiqej tĂ« transferonte produktin e tij nĂ« kĂ«tĂ« platformĂ« â megjithatĂ«, farat e ideve ishin tashmĂ« mbjellur. PĂ«rpjekja jonĂ« e parĂ« u bĂ« njĂ« mundĂ«si e shkĂ«lqyer pĂ«r tĂ« mĂ«suar: kuptuam se ishim me tĂ« vĂ«rtetĂ« tĂ« apasionuar pas krijimit tĂ« mjeteve pragmatike qĂ« zgjidhnin probleme tĂ« pĂ«rditshme pĂ«r pĂ«rdoruesit tanĂ«.
Duke u mbështetur në përvojën e gabimeve të kaluara, ne filluam zhvillimin e Helm 2.
Krijimi i Helm 2
NĂ« fund tĂ« vitit 2015, ekipi ynĂ« u kontaktua nga ekipi i Google. Ata po punonin mbi njĂ« mjet tĂ« ngjashĂ«m pĂ«r Kubernetes. Manageri i rreshtimit pĂ«r Kubernetes ishte njĂ« port i njĂ« mjeti ekzistues qĂ« pĂ«rdorej pĂ«r Google Cloud Platform. "A do tĂ« dĂ«shironim, â pyetĂ«n ata, â tĂ« kalonin disa ditĂ« duke diskutuar pĂ«r ngjashmĂ«ritĂ« dhe dallimet?"
NĂ« janar 2016, ekipet e Helm dhe Deployment Manager u takuan nĂ« Seattle pĂ«r tĂ« ndarĂ« ide. Negociatat pĂ«rfunduan me njĂ« plan ambicioz: tĂ« bashkojnĂ« tĂ« dy projektet pĂ«r tĂ« krijuar Helm 2. BashkĂ« me Deis dhe Google, ekipi i zhvilluesve u bashkua me djemtĂ« nga (tani i pĂ«rfshirĂ« nĂ« Bitnami â shĂ«n. pĂ«rkth.), dhe ne filluam punĂ«n mbi Helm 2.
Donim të ruanim lehtësinë e përdorimit të Helm, por të shtonim në vazhdim:
- shabllonët e chart-eve për personalizim;
- menaxhim brenda klasterit për ekipet;
- një depandencë e klasit të parë për chart-e;
- një format të stabilizuar paketash me mundësi nënshkrimi;
- një përkushtim të fortë ndaj versionimit semantik dhe ruajtjes së përputhshmërisë mbrapsht midis versioneve.
Për të arritur këto qëllime, një komponent i dytë u shtua në ekosistemin e Helm. Ky komponent brenda klasterit quhej Tiller dhe merrej me instalimin dhe menaxhimin e Helm-chart-eve.
QĂ« nga dalja e Helm 2 nĂ« vitin 2016, Kubernetes ka kaluar nĂ«pĂ«r disa risitĂ« e mĂ«dha. U krijua menaxhimi i aksesit mbi baza rolesh (), e cila nĂ« fund zĂ«vendĂ«soi kontrollin e aksesit bazuar nĂ« atribute (ABAC). U prezantuan tipe tĂ« reja burimesh (Deployments ende ishin nĂ« fazĂ«n beta). U shpikĂ«n Definicioni i Burimeve tĂ« Personalizuara ( nĂ« fillim u quajtĂ«n Burime tĂ« PalĂ«ve tĂ« Treta ose TPRs). ĂfarĂ« Ă«shtĂ« mĂ« e rĂ«ndĂ«sishmja â u shfaq njĂ« grup praktikash mĂ« tĂ« mira.
Në sfondin e të gjitha këtyre ndryshimeve, Helm vazhdoi të shërbejë me besnikëri për përdoruesit e Kubernetes. Pas tre vjetësh dhe shumë shtesave të reja, u bë e qartë se ishte koha për të bërë ndryshime të rëndësishme në bazën e kodit, në mënyrë që Helm të mund të përmbushte nevojat në rritje të ekosistemit në zhvillim.
Lamtumirë e butë me Tiller-in
GjatĂ« zhvillimit tĂ« Helm 2, ne prezantuam Tiller-in si pjesĂ« e integrimit tonĂ« me Menaxherin e ĂdojĂ«s nga Google. Tiller luajti njĂ« rol tĂ« rĂ«ndĂ«sishĂ«m pĂ«r ekipet qĂ« punonin brenda njĂ« klasteri tĂ« pĂ«rbashkĂ«t: ai lejojti specialistĂ« tĂ« ndryshĂ«m, qĂ« shfrytĂ«zonin infrastrukturĂ«n, tĂ« komunikonin me tĂ« njĂ«jtin set publikimesh.
Mei ndodhej që kontrolli i qasjes bazuar në role (RBAC) ishte aktiv nga default në Kubernetes 1.6, punojnë me Tiller në prodhim bëhej më e vështirë. Për shkak të numrit të madh të politikave të mundshme të sigurisë, pozita jonë ishte që të ofronim një konfigurim lehtësues nga default. Kjo lejonte fillestarët të bëjnë eksperimente me Helm dhe Kubernetes pa pasur nevojë të thellohet më parë në konfigurimet e sigurisë. Fatkeqësisht, kjo konfigurim lehtësues mund të jepte përdoruesit një gamë shumë të gjerë lejesh që ata nuk i nevojiteshin. Inxhinierët DevOps dhe SRE duhet të studionin hapa të tjerë operativ ndërsa instalonin Tiller në një klaster me shumë përdorues.
Duke mësuar se si përfaqësuesit e komunitetit përdorin Helm në situata të veçanta, ne kuptuam se sistemi i menaxhimit të rilizave Tiller nuk ka nevojë të mbështetet në një komponent brenda klasterit për të mbajtur gjendjet ose për të funksionuar si një qendër qendrore me informacion për rilizimin. Në vend të kësaj, ne mund të marrim thjesht informacion nga API-serveri i Kubernetes, të gjenerojmë chart-in në anën e klientit dhe të ruajmë një regjistër të instalimit në Kubernetes.
Detyrën kryesore të Tiller mund ta realizonim edhe pa Tiller, kështu që një nga vendimet e para për Helm 3 ishte heqja e plotë e Tiller.
Me largimin e Tiller, modeli i sigurisë së Helm është radikalisht thjeshtuar. Helm 3 tani mbështet të gjitha metodat moderne të sigurisë, identifikimit dhe autorizimit të Kubernetes aktual. Lejet e Helm përcaktohen me anë të . Administratorët e klasterit mund të kufizojnë të drejtat e përdoruesve me çdo nivel detaji. Rilizat akoma ruhen brenda klasterit, funksionaliteti i mbetur i Helm mbetet.
Repozitoret e chart-eve
Në një nivel të lartë, depoja e chart-eve është vendi ku mund të ruani dhe të ndani chart-et. Klienti Helm paketonte dhe dërgon chart-et në depo. Thënë ndryshe, depoja e chart-eve është një server HTTP temelor me një dosje index.yaml dhe disa chart-e të paketuar.
Megjithëse ka disa përfitime nga kjo që API e depozitës së chart-eve përmbush kërkesat më themelore për ruajtje, ajo ka gjithashtu disa disavantazhe:
- Depozitat e chart-eve janë pak kompatibile me shumicën e zbatimeve të sigurisë që nevojiten në mjedisin e prodhimit. Këtu, prania e një API standard për autentifikimin dhe autorizimin është jashtëzakonisht e rëndësishme në skenarët e prodhimit.
- Veglat e Helm për të ndjekur origjinën e chart-it, të përdorura për nënshkrimin, verifikimin e integritetit dhe origjinën e chart-it, janë një pjesë opsionale e procesit të publikimit të Chart-it.
- Në skenarët shumëpërdorues, e njëjta chart mund të ngarkohet nga një përdorues tjetër, duke dyfishuar hapësirën e nevojshme për ruajtjen e përmbajtjes së njëjtë. Për të zgjidhur këtë problem janë zhvilluar depo më të mençura, megjithatë ato nuk janë pjesë e specifikimit formal.
- Përdorimi i një skedari indeksi të vetëm për kërkimin, ruajtjen e metadata dhe marrjen e chart-eve e ka komplikuar zhvillimin e realizimeve të sigurta shumëpërdorues.
Projekt (i njohur gjithashtu si Docker Registry v2) është pasardhësi i Docker Registry dhe faktikisht përfaqëson një grup mjetesh për paketimin, dërgimin, ruajtjen dhe shpërndarjen e imazheve Docker. Shumë shërbime të mëdha cloud ofrojnë produkte mbi bazën e Distribution. Falë kësaj vëmendjeje të rritur, projekti Distribution ka përfituar nga përmirësime të vazhdueshme, praktikat më të mira në fushën e sigurisë dhe testimin në kushte 'beteje', duke u transformuar në një nga heronjtë më të suksesshëm të paqëruar në botën Open Source.
Por a e dini se projekti Distribution është zhvilluar për të shpërndarë çdo lloj përmbajtjeje, jo vetëm imazhe kontejnerësh?
Falënderit për përpjekjet (ose OCI), Helm-chartet mund të vendosen në çdo instancë Distribution. Deri tani, ky proces ka një karakter eksperimental. Puna për mbështetje të fjalëkalimeve dhe funksioneve të tjera të nevojshme për Helm 3 nuk ka përfunduar ende, por jemi shumë të kënaqur me mundësinë për të mësuar nga zbulimet e bëra nga ekipet OCI dhe Distribution gjatë këtyre viteve. Dhe falë mentorimit dhe udhëheqjes së tyre, po mësojmë se çfarë është operimi i një shërbimi me disponueshmëri të lartë në një shkallë të madhe.
Një përshkrim më i detajuar i disa ndryshimeve të ardhshme në depozitë të Helm-chart-it është në dispozicion .
Menaxhimi i lëshimeve
Në Helm 3, gjendja e aplikacionit ndjeket brenda klasterit nga një çift objektesh:
- objekti release â pĂ«rfaqĂ«son njĂ« instancĂ« tĂ« aplikacionit;
- sekreti i versionit release â pĂ«rfaqĂ«son gjendjen e dĂ«shiruar tĂ« aplikacionit nĂ« njĂ« moment tĂ« caktuar (p.sh., lĂ«shimi i njĂ« versioni tĂ« ri).
Thirrja helm install krijon objektin release dhe sekretin e versionit release. Thirrja helm upgrade kërkon një objekt release (të cilin mund ta ndryshojë) dhe krijon një sekret të ri të versionit release, duke përfshirë vlerat e reja dhe manifestin e përgatitur.
Objekti i lansimit përmban informacion në lidhje me lansimin, ku lansimi është një instalim specifik i një charta dhe vlerave të emëruara. Ky objekt përshkruan meta të nivelit të lartë për lansimin. Objekti i lansimit ruhet gjatë gjithë ciklit të jetës së aplikacionit dhe vepron si pronari i të gjitha sekretëve të versioneve të lansimit, si dhe të gjitha objekteve që krijohen drejtpërdrejt nga charta e Helm.
Sekreti i versionit të lansimit lidh lansimin me një seri revizioni (instalimi, përditësimet, rikthimet, fshirja).
NĂ« Helm 2, revizionet ishin ekskluzivisht tĂ« radhitur. Thirrja helm install krijonte v1, pĂ«rditĂ«simi i mĂ«tejmĂ« (upgrade) â v2, dhe kĂ«shtu me radhĂ«. Lansimi dhe sekreti i versionit tĂ« lansimit u shkurorĂ«zuan nĂ« njĂ« objekt tĂ« vetĂ«m, tĂ« njohur si revizion. Revizionet u ruajtĂ«n nĂ« tĂ« njĂ«jtin hapĂ«sirĂ« emri si Tiller, duke do tĂ« thotĂ« se çdo lansim ishte "global" nĂ« aspektin e hapĂ«sirĂ«s emri; si rezultat, mund tĂ« pĂ«rdorej vetĂ«m njĂ« ekzemplar emri.
NĂ« Helm 3, çdo lĂ«shim lidhet me njĂ« ose mĂ« shumĂ« sekrete versioni tĂ« lĂ«shimit. Objekti i lĂ«shimit gjithmonĂ« pĂ«rshkruan lĂ«shimin aktual tĂ« implementuar nĂ« Kubernetes. Ădo sekrete versioni lĂ«shimi pĂ«rshkruan vetĂ«m njĂ« version tĂ« kĂ«tij lĂ«shimi. NjĂ« pĂ«rditĂ«sim (upgrade), pĂ«r shembull, do tĂ« krijojĂ« njĂ« sekrete versioni tĂ« re dhe mĂ« pas do tĂ« ndryshojĂ« objektin e lĂ«shimit pĂ«r tĂ« treguar pĂ«r kĂ«tĂ« version tĂ« ri. NĂ« rastin e rikthimit (rollback), mund tĂ« pĂ«rdoren sekrete versioni tĂ« mĂ«parshme pĂ«r tĂ« kthyer lĂ«shimin nĂ« gjendjen e tij tĂ« mĂ«parshme.
Pasi u hoq Tiller, Helm 3 ruan të dhënat e lëshimit në një hapësirë emri të vetme me lëshimin. Ky ndryshim lejon instalimin e një karte me të njëjtin emër lëshimi në një hapësirë emri tjetër, duke ruajtur të dhënat midis përditësimeve/rindezjeve të klasterit në etcd. Për shembull, mund të instaloni WordPress në hapësirën e emrit "foo", dhe më pas në hapësirën e emrit "bar", dhe të dy lëshimet mund të quhen "wordpress".
Ndryshimet në varësitë e kartave
Kartat, të paketuar (me helm package) për përdorim me Helm 2, mund të instalohet me Helm 3; megjithatë, procesi i zhvillimit të grafikëve është rishikuar plotësisht, kështu që disa ndryshime duhet të bëhen për të vazhduar zhvillimin e grafikëve me Helm 3. Në veçanti, sistemi i menaxhimit të varësive të grafikëve ka ndryshuar.
Sistemi i menaxhimit të varësive të grafikëve kaloi nga requirements.yaml dhe requirements.lock në Chart.yaml dhe Chart.lock. Kjo do të thotë se grafikët që përdorën komandën helm dependency, kërkojnë disa konfigurime për të funksionuar në Helm 3.
Le të shohim një shembull. Shtojmë një varësi në grafikët në Helm 2 dhe shohim se çfarë do të ndryshojë kur kalojmë në Helm 3.
Në Helm 2 requirements.yaml dukej si më poshtë:
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ë reflektohet në Chart.yaml:
dependencies:
- name: mariadb
version: 5.x.x
repository: https://kubernetes-charts.storage.googleapis.com/
condition: mariadb.enabled
tags:
- database Grafikët ende ngarkohen dhe vendosen në drejtorinë charts/, prandaj subgrafikët (subcharts), që ndodhen në katalogun charts/, do të vazhdojnë të funksionojnë pa ndryshime.
Prezantimi i Grafikëve të Bibliotekave
Helm 3 mbështet një klasë grafikësh që quhet grafikë-bibliotekë (library chart). Ky chart përdoret nga chart-e të tjera, por vetë nuk krijon asnjë artefakt lëshimi. Shabllonet e chart-eve library mund të shpallin vetëm elemente përcakto. Përmbajtje tjetër thjesht injorohet. Kjo lejon përdoruesit të ripërdorin dhe ndajnë fragmente kodi që mund të përdoren në shumë chart-e, duke shmangur kështu përsëritjen dhe duke ndjekur parimin .
Chart-et library shpallen në seksionin varësi në skedarin Chart.yaml. Instalimi dhe menaxhimi i tyre nuk ndryshon nga chart-et e tjera.
varësi:
- emri: mylib
version: 1.x.x
repo: quay.ioNe me padurim presim rastet e përdorimit që ky komponent do të hapë para zhvilluesve të chart-eve, si dhe praktikat më të mira që mund të lindin falë chart-eve library.
ĂfarĂ« ndodh mĂ« tej?
Helm 3.0.0-alpha.1 â baza mbi tĂ« cilĂ«n fillojmĂ« tĂ« krijojmĂ« njĂ« version tĂ« ri tĂ« Helm. NĂ« kĂ«tĂ« artikull kam pĂ«rshkruar disa mundĂ«si interesante tĂ« Helm 3. ShumĂ« prej tyre janĂ« ende nĂ« fazat fillestare tĂ« zhvillimit dhe kjo Ă«shtĂ« nĂ« rregull; thelbi i lĂ«shimit alfa Ă«shtĂ« tĂ« provosh idenĂ«, tĂ« mbledhĂ«sh mendime nga pĂ«rdoruesit e parĂ« dhe tĂ« konfirmosh supozimet tona.
Sapo tĂ« lĂ«shohet versione alfa (kujtoj, se kjo â shĂ«nim i pĂ«rkthyesit.), ne do tĂ« fillojmĂ« tĂ« pranojmĂ« patches pĂ«r Helm 3 nga komuniteti. ĂshtĂ« thelbĂ«sore tĂ« krijojmĂ« njĂ« bazĂ« solide qĂ« do tĂ« lejojĂ« zhvillimin dhe pranimet e karakteristikave tĂ« reja, ndĂ«rsa pĂ«rdoruesit do tĂ« ndihen tĂ« angazhuar nĂ« proces, duke hapur tiketa dhe duke kontribuar me rregullime.
Në këtë artikull përpiqem të përmbledh disa përmirësime të rëndësishme që do të vinë në Helm 3, megjithatë kjo listë nuk mund të quhet e plotë në asnjë rast. Plani i plotë për Helm 3 përfshin inovacione të tilla si strategji të përmirësuara të përditësimit, integrim më të thellë me regjistrat OCI dhe përdorimin e skemave JSON për të verifikuar vlerat e grafikëve. Gjithashtu, ne planifikojmë të pastrojmë bazën e kodit dhe të azhurnojmë ato pjesë që kanë mbetur pa vëmendje gjatë tre viteve të fundit.
Nëse ndiheni se kemi humbur diçka, do të ishim të lumtur të dëgjonim mendimet tuaja!
Bashkohuni në diskutimin tonë në :
-
#helm-userspër pyetje dhe komunikim të thjeshtë me komunitetin; -
#helm-devpër diskutimin e pull requests, kodit dhe gabimeve.
Mund tĂ« bisedoni nĂ« Thirrjet Publike pĂ«r Zhvilluesit qĂ« mbahen çdo javĂ« tĂ« enjten nĂ« orĂ«n 19:30 MSK. Takimet janĂ« tĂ« dedikuara pĂ«r diskutimin e detyrave qĂ« po punojnĂ« zhvilluesit kryesorĂ« dhe komuniteti, si dhe temave qĂ« do tĂ« diskutohen gjatĂ« javĂ«s. Ădokush Ă«shtĂ« e mirĂ«pritur tĂ« bashkohet dhe tĂ« marrĂ« pjesĂ« nĂ« takim. Linku Ă«shtĂ« i disponueshĂ«m nĂ« kanalin Slack. #helm-dev.
P.S. nga përkthyesi
Lexoni gjithashtu në blogun tonë:
- «»;
- «»;
- «»;
- «»;
- «».
Burimi: habr.com
