🥇 Helm 3rako sarrera

Ohar. itzul.: Aurtengo maiatzaren 16ak mugarri garrantzitsua markatzen du Kubernetes - Helm-en paketeen kudeatzailea garatzeko. Egun honetan, proiektuaren etorkizuneko bertsio nagusiaren lehen bertsio alfa - 3.0 - aurkeztu zen. Bere kaleratzeak aldaketa esanguratsuak eta luze itxaroten ditu Helm-i, eta Kubernetes komunitateko askok itxaropen handia dute. Gu geu gara horietako bat, Helm aktiboki erabiltzen baitugu aplikazioak hedatzeko: CI/CD inplementatzeko gure tresnan integratu dugu. werf eta noizean behin gure ekarpena egiten dugu upstream garapenean. Itzulpen honek Helm blog ofizialeko 7 ohar konbinatzen ditu, Helm 3-ren lehen alfa bertsioari eskainitakoak eta proiektuaren historiari eta Helm 3-ren ezaugarri nagusiei buruz hitz egiten dutenak. Beren egilea Matt “bacongobbler” Fisher da, Microsoft-eko langilea. eta Helm-en mantentzaile nagusietako bat.

15eko urriaren 2015ean, gaur egun Helm izenez ezagutzen den proiektua jaio zen. Sortu eta urtebetera, Helm komunitatea Kubernetes-en sartu zen, Helm 2-n aktiboki lan egiten zuen bitartean. 2018ko ekainean, Helm CNCFn sartu zen garatzen den (inkubatzen) proiektu gisa. Aurreratu orain arte, eta Helm 3 berriaren lehen alfa bertsioa bidean da. (argitalpen hau dagoeneko egin da maiatzaren erdialdean - gutxi gorabehera. itzul.).

Zati honetan, dena non hasi zen, gaur gauden lekura nola iritsi garen, Helm 3-ren lehen alfa bertsioan dauden ezaugarri berezi batzuk aurkeztuko ditut eta aurrera nola egin asmo dugun azalduko dut.

Laburpena:

Helm-en sorreraren historia;
Tilleri agur samurra;
diagramen biltegiak;
kaleratze kudeaketa;
diagramen menpekotasunen aldaketak;
liburutegiko diagramak;
zer da hurrengoa?

Helm-en historia

jaiotza

Helm 1 Deis-ek sortutako Open Source proiektu gisa hasi zen. Startup txiki bat ginen xurgatu Microsoft 2017ko udaberrian. Gure beste Open Source proiektuak, Deis izenekoa ere, tresna bat zeukan deisctl, Deis plataforma instalatzeko eta funtzionatzeko erabili zen (besteak beste). Flota multzoa. Garai hartan, Fleet edukiontzien orkestrazio plataformetako bat izan zen.

2015aren erdialdean, bidea aldatzea erabaki genuen eta Deis (orduan Deis Workflow izena hartu zuen) Fleetetik Kubernetesera eraman genuen. Berriz diseinatu zuten lehenetariko bat instalazio tresna izan zen. deisctl. Fleet klusterrean Deis Workflow instalatzeko eta kudeatzeko erabili dugu.

Helm 1 pakete kudeatzaile ospetsuen irudian sortu zen, hala nola Homebrew, apt eta yum. Bere helburu nagusia Kubernetesen aplikazioak ontziratzea eta instalatzea bezalako zereginak erraztea zen. Helm 2015ean aurkeztu zen ofizialki San Frantziskoko KubeCon konferentzian.

Helm-ekin egin genuen lehen saiakerak funtzionatu zuen, baina ez zen muga larririk izan. Kubernetes-eko manifestu sorta bat hartu zuen, YAML sarrerako bloke gisa sorgailuekin zaporetuta. (aurrealdea)*, eta emaitzak Kubernetesen kargatu ditu.

* Ohar. itzul.: Helm-en lehen bertsiotik, YAML sintaxia aukeratu zen Kubernetes baliabideak deskribatzeko, eta Jinja txantiloiak eta Python scriptak onartzen ziren konfigurazioak idazterakoan. Honi eta, oro har, Helm-en lehen bertsioaren egiturari buruz gehiago idatzi genuen "Helm-en historia laburra" kapituluan. material hau.

Adibidez, YAML fitxategi bateko eremu bat ordezkatzeko, eraikuntza hau gehitu behar izan duzu manifestuan:

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

Sekulakoa da gaur egun txantiloi motorrak egotea, ezta?

Arrazoi askorengatik, Kubernetes instalatzaile goiztiar honek manifestu fitxategien zerrenda gogor kodetua behar zuen eta gertaeren sekuentzia txiki eta finko bat baino ez zuen exekutatu. Hain zaila zen erabiltzea, non Deis Workflow I+G taldeari zailtasunak izan baitzituzten bere produktua plataforma horretara transferitzen saiatu zirenean; hala ere, ideiaren hazia jada ereinda zegoen. Gure lehen saiakera ikasteko aukera bikaina izan zen: konturatu ginen benetan sutsuak ginela gure erabiltzaileentzako eguneroko arazoak konpontzen dituzten tresna pragmatikoak sortzeaz.

Iraganeko akatsen esperientzian oinarrituta, Helm 2 garatzen hasi ginen.

Helmuga egitea 2

2015. urte amaieran, Google taldea gurekin harremanetan jarri zen. Kubernetesentzako antzeko tresna batean ari ziren lanean. Kubernetes-en Deployment Manager lehendik zegoen tresna baten ataka zen, Google Cloud Platform-erako erabiltzen zena. "Gustuko genuke", galdetu zuten, "egun batzuk pasatzea antzekotasun eta desberdintasunak eztabaidatzen?"

2016ko urtarrilean, Helm eta Deployment Manager taldeak Seattlen elkartu ziren ideiak trukatzeko. Negoziazioak asmo handiko plan batekin amaitu ziren: bi proiektuak bateratzea Helm 2 sortzeko. Deis eta Googlerekin batera, mutilek. SkippBox (orain Bitnami-ren parte da - gutxi gorabehera itzul.), eta Helm 2 lanean hasi ginen.

Helm-en erabilera-erraztasuna mantendu nahi genuen, baina gehitu hurrengoa:

pertsonalizatzeko diagramen txantiloiak;
taldeen barne-kluster kudeaketa;
mundu mailako diagramen biltegia;
pakete formatu egonkorra sinadura aukerarekin;
bertsio semantikoaren eta bertsioen arteko atzerako bateragarritasuna mantentzeko konpromiso sendoa.

Helburu horiek lortzeko, bigarren elementu bat gehitu zaio Helm ekosistemari. Kluster barneko osagai honek Tiller deitzen zen eta Helm diagramak instalatzeaz eta haiek kudeatzeaz arduratzen zen.

2an Helm 2016 kaleratu zenetik, Kubernetes-ek hainbat berrikuntza nagusi gehitu ditu. Roletan oinarritutako sarbide-kontrola gehitu da (RBAC), azkenean Atributuetan Oinarritutako Sarbide Kontrola (ABAC) ordezkatu zuen. Baliabide mota berriak sartu ziren (Inplementazioak oraindik beta-n zeuden garai hartan). Pertsonalizatutako Baliabideen Definizioak (hasieran Hirugarrenen Baliabideak edo TPR izenekoak) asmatu ziren. Eta garrantzitsuena, praktika onen multzo bat sortu da.

Aldaketa horien guztien artean, Helmek Kuberneteseko erabiltzaileei leialki zerbitzatzen jarraitu zuen. Hiru urte eta gehigarri berri askoren ondoren, argi zegoen kode-oinarrian aldaketa garrantzitsuak egiteko garaia zela Helm-ek eboluzionatzen ari den ekosistema baten beharrak asetzen jarraitzeko.

Tillerri agur samurra

Helm 2-ren garapenean, Tiller aurkeztu genuen Google-ren Deployment Manager-ekin gure integrazioaren zati gisa. Tiller-ek zeregin garrantzitsua izan zuen kluster komun baten barruan lan egiten zuten taldeentzat: azpiegitura kudeatzen zuten espezialista ezberdinei bertsio-multzo berdinarekin elkarreragiteko aukera eman zien.

Roletan oinarritutako sarbide-kontrola (RBAC) Kubernetes 1.6-n lehenespenez gaituta zegoenez, Tiller-ekin lan egitea zailagoa zen ekoizpenean. Segurtasun-politika posibleak direnez, gure jarrera lehenespenez konfigurazio permisibo bat eskaintzea izan da. Horri esker, hasiberriei Helm eta Kubernetesekin esperimentatu ahal izan zuten segurtasun-ezarpenetan murgildu beharrik gabe. Zoritxarrez, baimen-konfigurazio honek erabiltzaileari behar ez dituen baimen sorta zabalegia eman diezaioke. DevOps eta SRE ingeniariek urrats operatibo gehigarriak ikasi behar izan zituzten Tiller maizter anitzeko kluster batean instalatzean.

Komunitateak Helm egoera zehatzetan nola erabiltzen zuen ikasi ondoren, konturatu ginen Tiller-en oharra kudeatzeko sistemak ez zuela zertan kluster barruko osagai batean fidatu behar egoera mantentzeko edo kaleratze-informaziorako zentro zentral gisa funtzionatzeko. Horren ordez, Kubernetes API zerbitzaritik informazioa jaso, bezeroaren aldean grafiko bat sortu eta Kubernetesen instalazioaren erregistroa gorde genezake.

Tillerren helburu nagusia Tillerrik gabe lor zitekeen, beraz Helm 3-ri buruz gure lehen erabakietako bat Tiller erabat alde batera uztea izan zen.

Tiller desagertuta, Helmen segurtasun eredua zeharo sinplifikatu da. Helm 3-k gaur egungo Kubernetesen segurtasun, identitate eta baimen-metodo moderno guztiak onartzen ditu. Helm baimenak erabiliz zehazten dira kubeconfig fitxategia. Klusterreko administratzaileek erabiltzaile-eskubideak edozein xehetasun-mailara muga ditzakete. Argitalpenak kluster barruan gordetzen dira oraindik, eta Helm-en gainerako funtzionalitateak bere horretan jarraitzen du.

Diagrama-biltegiak

Maila altuan, diagramen biltegia diagramak gorde eta partekatzeko lekua da. Helm bezeroak paketatu eta diagramak biltegira bidaltzen ditu. Besterik gabe, diagramen biltegi bat HTTP zerbitzari primitibo bat da, index.yaml fitxategi batekin eta diagrama paketatu batzuekin.

Charts Repository APIak biltegiratze-baldintza gehienak betetzen dituen abantaila batzuk baditu ere, desabantaila batzuk ere baditu:

Diagrama-biltegiak ez dira bateragarriak ekoizpen-ingurunean behar diren segurtasun-inplementazio gehienekin. Autentifikaziorako eta baimenerako API estandar bat edukitzea oso garrantzitsua da ekoizpen agertokietan.
Helm-en diagrama-jatorrizko tresnak, diagrama baten osotasuna eta jatorria sinatzeko, egiaztatzeko erabiltzen direnak, Chart argitaratzeko prozesuaren aukerako zati bat dira.
Erabiltzaile anitzeko agertokietan, diagrama bera beste erabiltzaile batek igo dezake, eduki bera gordetzeko behar den espazioa bikoiztuz. Arazo hau konpontzeko biltegi adimendunagoak garatu dira, baina ez dira zehaztapen formalaren parte.
Bilatu, metadatuak gordetzeko eta diagramak berreskuratzeko indize-fitxategi bakarra erabiltzeak erabiltzaile anitzeko inplementazio seguruak garatzea zaildu du.

Proiektu Docker banaketa (Docker Registry v2 izenez ere ezaguna) Docker Registry-ren oinordekoa da eta funtsean, Docker irudiak ontziratzeko, bidaltzeko, gordetzeko eta entregatzeko tresna multzo gisa jokatzen du. Hodeiko zerbitzu handi askok banaketan oinarritutako produktuak eskaintzen dituzte. Arreta areagotu horri esker, Distribution proiektuak urteetako hobekuntzei, segurtasun-jardunbide egokiei eta eremuko proben etekina atera dio, Iturburu Irekiaren munduko heroirik arrakastatsuenetako bat bihurtu dutenak.

Baina ba al zenekien Banaketa Proiektua edozein eduki mota banatzeko diseinatu zela, ez edukiontzien irudiak soilik?

Ahaleginari esker Edukiontzi Irekiaren Ekimena (edo OCI), Helm diagramak edozein Banaketa instantziatan jar daitezke. Oraingoz, prozesu hau esperimentala da. Saio-hasteko laguntza eta Helm 3 osorako beharrezkoak diren beste eginbide batzuk abian dira, baina OCI eta Distribution taldeek urteetan zehar egindako aurkikuntzetatik ikasteko gogotsu gaude. Eta haien tutoretza eta orientazioaren bidez, eskala mailan erabilgarritasun handiko zerbitzu bat funtzionatzea zer den ikasten dugu.

Helm diagramen biltegietan datozen aldaketen deskribapen zehatzagoa eskuragarri dago по ссылке.

Askapenaren kudeaketa

Helm 3-n, aplikazioaren egoera kluster barruan jarraitzen du objektu pare batek:

askatzeko objektua - aplikazioaren instantzia bat adierazten du;
kaleratzeko bertsioaren sekretua - une jakin batean aplikazioaren nahi den egoera adierazten du (adibidez, bertsio berri bat kaleratzea).

deiaren helm install kaleratze-objektu bat eta kaleratzeko bertsio sekretua sortzen du. Deitu helm upgrade kaleratze-objektu bat behar du (aldatu daitekeena) eta balio berriak eta prestatutako manifestu bat dituen bertsio sekretu berri bat sortzen du.

Release objektuak bertsioari buruzko informazioa dauka, non kaleratzea izendun diagrama eta balioen instalazio espezifikoa den. Objektu honek bertsioari buruzko goi-mailako metadatuak deskribatzen ditu. Askapen-objektuak aplikazioaren bizi-ziklo osoan irauten du eta bertsioaren sekretu guztien jabea da, baita Helm diagramak zuzenean sortzen dituen objektu guztien jabea ere.

Bertsio-bertsio sekretuak bertsio bat berrikuspen sortarekin lotzen du (instalazioa, eguneraketak, atzera botatzea, ezabatzea).

Helm 2-n, berrikuspenak oso koherenteak ziren. Deitu helm install sortu v1, ondorengo eguneratzea (berritzea) - v2, eta abar. Argitalpenaren eta bertsioaren sekretua berrikuspena izenez ezagutzen den objektu bakar batean bildu dira. Berrikuspenak Tillerren izen-espazio berean gordetzen ziren, hau da, bertsio bakoitza "globala" zela izen-espazioari dagokionez; ondorioz, izenaren instantzia bakarra erabil zitekeen.

Helm 3-n, bertsio bakoitza bertsio sekretu batekin edo gehiagorekin lotuta dago. Kaleratze-objektuak Kubernetes-en inplementatutako uneko bertsioa deskribatzen du beti. Argitalpenaren bertsio sekretu bakoitzak bertsio horren bertsio bakarra deskribatzen du. Eguneratze batek, adibidez, bertsio berriaren sekretua sortuko du eta, ondoren, bertsio-objektua aldatuko du bertsio berri horretara seinalatzeko. Atzera egitean, aurreko bertsioaren sekretuak erabil ditzakezu bertsioa aurreko egoera batera itzultzeko.

Tiller bertan behera utzi ondoren, Helm 3-k kaleratze-datuak bertsioaren izen-espazio berean gordetzen ditu. Aldaketa honek bertsio-izen berdina duen diagrama bat instalatzeko aukera ematen du beste izen-espazio batean, eta datuak kluster eguneratze/berrabiarazi artean gordetzen dira etcd-en. Adibidez, WordPress "foo" izen-espazioan instala dezakezu eta gero "bar" izen-eremuan, eta bi bertsioak "wordpress" izenda daitezke.

Grafikoen mendekotasunen aldaketak

Grafikoak bilduta (erabiliz helm package) Helm 2-rekin erabiltzeko Helm 3-rekin instalatu daiteke, hala ere diagramen garapen-fluxua guztiz berritu da, beraz, aldaketa batzuk egin behar dira Helm 3-rekin diagrama garatzen jarraitzeko. Bereziki, diagramen mendekotasunen kudeaketa sistema aldatu da.

Grafikoaren menpekotasuna kudeatzeko sistematik mugitu da requirements.yaml и requirements.lock on Chart.yaml и Chart.lock. Horrek esan nahi du komandoa erabiltzen duten diagramak helm dependencyHelm 3-n funtzionatzeko konfigurazio batzuk behar dira.

Ikus dezagun adibide bat. Gehi diezaiogun menpekotasun bat Helm 2-ko taulari eta ikusi zer aldatzen den Helm 3-ra mugitzean.

Helm 2-n requirements.yaml itxura hau zuen:

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

Helm 3-n, mendekotasun bera islatuko da zurean Chart.yaml:

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

Diagramak deskargatu eta direktorioan jartzen dira oraindik charts/, beraz, azpidiagramak (azpidiagramak), katalogoan etzanda charts/, aldaketarik gabe lanean jarraituko du.

Liburutegien diagramak aurkezten

Helm 3-k liburutegi-diagrama izeneko diagramen klase bat onartzen du (liburutegi-diagrama). Diagrama hau beste diagramek erabiltzen dute, baina ez du kaleratze-artefakturik sortzen bere kabuz. Liburutegiko diagramen txantiloiak elementuak soilik deklara ditzakete define. Beste eduki batzuk baztertu egiten dira. Horri esker, erabiltzaileek grafiko anitzetan erabil daitezkeen kode zatiak berrerabili eta partekatu ditzakete, horrela bikoizketak saihestuz eta printzipioa betez. DRY.

Liburutegiko diagramak atalean adierazten dira dependencies fitxategian Chart.yaml. Horiek instalatzea eta kudeatzea ez da beste diagrama batzuen aldean.

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

Pozik gaude osagai honek diagramen garatzaileei irekiko dizkien erabilera-kasuei buruz, baita liburutegi-diagrametatik sor daitezkeen jardunbide egokiei buruz ere.

Zer da hurrengoa?

Helm 3.0.0-alpha.1 Helm-en bertsio berri bat eraikitzen hasten garen oinarria da. Artikuluan Helm 3-ren ezaugarri interesgarri batzuk deskribatu nituen. Horietako asko garapenaren hasierako faseetan daude oraindik eta hori normala da; Alpha bertsio baten helburua ideia probatzea da, lehen erabiltzaileen iritziak biltzea eta gure hipotesiak berrestea.

Alpha bertsioa kaleratu bezain laster (gogoratu hau dela dagoeneko gertatu da - gutxi gorabehera. itzul.), komunitatetik Helm 3rako adabakiak onartzen hasiko gara. Funtzio berriak garatu eta hartzea ahalbidetzen duen oinarri sendo bat sortu behar duzu, eta erabiltzaileak prozesuan parte hartzen senti daitezen txartelak irekiz eta konponketak eginez.

Helm 3-ra datozen hobekuntza nagusietako batzuk nabarmentzen saiatu naiz, baina zerrenda hau ez da inolaz ere zehatza. Helm 3-ren bide-orri osoak eguneratze-estrategia hobetuak, OCI erregistroekin integrazio sakonagoa eta diagramen balioak balioztatzeko JSON eskemak erabiltzea bezalako ezaugarriak biltzen ditu. Gainera, kode-oinarria garbitu eta azken hiru urteetan baztertuta egon diren zatiak eguneratzeko asmoa dugu.

Zerbait galdu dugula iruditzen bazaizu, zure pentsamenduak entzutea gustatuko litzaiguke!

Bat egin gure eztabaidan Slack kanalak:

#helm-users galderetarako eta komunitatearekin komunikazio errazetarako;
#helm-dev pull eskaerak, kodea eta akatsak eztabaidatzeko.

Gure asteroko Garatzaile Publikoen Deietan ere hitz egin dezakezu ostegunetan, 19:30ean, MSK. Topaketak garatzaile nagusiek eta komunitateak lantzen dituzten gaiak eztabaidatzera bideratzen dira, baita astean eztabaidatzeko gaiak ere. Edonor bat egin daiteke eta bileran parte hartu dezake. Esteka eskuragarri dago Slack kanalean #helm-dev.

PS itzultzailetik

Irakurri ere gure blogean:

Iturria: www.habr.com

Helm 3 aurkezten