🥇Enkonduko al Helm 3

Notu. transl.: La 16-a de majo ĉi-jare markas signifan mejloŝtonon en la evoluo de la pakadministranto por Kubernetes - Helm. En ĉi tiu tago, la unua alfa eldono de la estonta grava versio de la projekto - 3.0 - estis prezentita. Ĝia liberigo alportos signifajn kaj longe atenditajn ŝanĝojn al Helm, pri kiuj multaj en la Kubernetes-komunumo havas grandajn esperojn. Ni mem estas unu el ĉi tiuj, ĉar ni aktive uzas Helm por aplikaĵo deplojo: ni integris ĝin en nian ilon por efektivigi CI/CD. werf kaj de tempo al tempo ni faras nian kontribuon al la disvolviĝo de kontraŭflue. Ĉi tiu traduko kombinas 7 notojn de la oficiala Helm-blogo, kiuj estas dediĉitaj al la unua alfa-eldono de Helm 3 kaj parolas pri la historio de la projekto kaj la ĉefaj trajtoj de Helm 3. Ilia aŭtoro estas Matt "bacongobbler" Fisher, oficisto de Microsoft. kaj unu el la ĉefaj prizorgantoj de Helm.

La 15-an de oktobro 2015 naskiĝis la projekto nun konata kiel Helm. Nur jaron post sia fondiĝo, la Helm-komunumo aliĝis al Kubernetes, dum aktive laborante pri Helm 2. En junio 2018, Helm aliĝis al la CNCF kiel evoluanta (inkubata) projekto. Rapide antaŭen al la nuntempo, kaj la unua alfa eldono de la nova Helm 3 estas survoje. (ĉi tiu eldono jam okazis meze de majo - ĉ. traduk.).

En ĉi tiu peco, mi parolos pri kie ĉio komenciĝis, kiel ni atingis kie ni estas hodiaŭ, enkondukos kelkajn el la unikaj funkcioj disponeblaj en la unua alfa eldono de Helm 3, kaj klarigos kiel ni planas antaŭeniri.

Resumo:

la historio de la kreado de Helm;
tenera adiaŭo al Tiller;
diagramaj deponejoj;
eldonadministrado;
ŝanĝoj en diagramaj dependecoj;
biblioteko-diagramoj;
kio sekvas?

La historio de Helm

Naskiĝo

Helm 1 komenciĝis kiel Open Source projekto kreita de Deis. Ni estis malgranda ekentrepreno absorbita Microsoft en printempo 2017. Nia alia Open Source projekto, ankaŭ nomita Deis, havis ilon deisctl, kiu estis uzata (interalie) por instali kaj funkciigi la platformon Deis en Flota areto. Tiutempe, Fleet estis unu el la unuaj konteneraj instrumentadplatformoj.

Meze de 2015, ni decidis ŝanĝi kurson kaj movis Deis (tiutempe renomita Deis Workflow) de Fleet al Kubernetes. Unu el la unuaj restrukturitaj estis la instalilo. deisctl. Ni uzis ĝin por instali kaj administri Deis Workflow en la Fleet-grupo.

Helm 1 estis kreita laŭ la bildo de famaj pakadministrantoj kiel Homebrew, apt kaj yum. Ĝia ĉefa celo estis simpligi taskojn kiel paki kaj instali aplikaĵojn sur Kubernetes. Helm estis oficiale prezentita en 2015 ĉe la KubeCon-konferenco en San Francisco.

Nia unua provo kun Helm funkciis, sed ĝi ne estis sen seriozaj limigoj. Li prenis aron da Kubernetes-manifestoj, gustigitaj per generatoroj kiel enkondukaj YAML-blokoj. (antaŭa afero)*, kaj ŝarĝis la rezultojn en Kubernetes.

* Notu. transl.: El la unua versio de Helm, YAML-sintakso estis elektita por priskribi Kubernetes-resursojn, kaj Jinja-ŝablonoj kaj Python-skriptoj estis subtenataj dum skribado de agordoj. Ni skribis pli pri tio kaj la strukturo de la unua versio de Helm ĝenerale en la ĉapitro "Mallonga Historio de Helm" ĉi tiu materialo.

Ekzemple, por anstataŭigi kampon en YAML-dosiero, vi devis aldoni la sekvan konstruaĵon al la manifesto:

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

Estas bonege, ke ŝablonaj motoroj ekzistas hodiaŭ, ĉu ne?

Pro multaj kialoj, ĉi tiu frua instalilo de Kubernetes postulis malmolan koditan liston de manifestdosieroj kaj nur efektivigis malgrandan, fiksitan sekvencon de eventoj. Estis tiel malfacile uzi, ke la teamo de R&D de Deis Workflow malfacilis kiam ili provis transdoni sian produkton al ĉi tiu platformo - tamen, la semoj de la ideo jam estis semitaj. Nia unua provo estis bonega lernŝanco: ni rimarkis, ke ni vere entuziasmas pri kreado de pragmataj iloj, kiuj solvas ĉiutagajn problemojn por niaj uzantoj.

Surbaze de la sperto de pasintaj eraroj, ni komencis disvolvi Helm 2.

Farante Helmon 2

Fine de 2015, la Guglo-teamo kontaktis nin. Ili laboris pri simila ilo por Kubernetes. Deploja Administranto por Kubernetes estis haveno de ekzistanta ilo, kiu estis uzata por Google Cloud Platform. "Ĉu ni ŝatus," ili demandis, "pasigi kelkajn tagojn diskutante la similecojn kaj diferencojn?"

En januaro 2016, la Helm kaj Deployment Manager-teamoj renkontis en Seatlo por interŝanĝi ideojn. La intertraktado finiĝis kun ambicia plano: kombini ambaŭ projektojn por krei Helm 2. Kune kun Deis kaj Guglo, la infanoj de SkippBox (nun parto de Bitnami - ĉ. traduk.), kaj ni komencis labori pri Helm 2.

Ni volis konservi la facilecon de Helm, sed aldoni la jenon:

diagramaj ŝablonoj por personigo;
intra-cluster-administrado por teamoj;
mondklasa diagrama deponejo;
stabila pakformato kun subskriba opcio;
forta engaĝiĝo al semantika versio kaj konservado de retrokongruo inter versioj.

Por atingi ĉi tiujn celojn, dua elemento estis aldonita al la Helm-ekosistemo. Ĉi tiu intra-grupo estis nomita Tiller kaj respondecis pri instalado de Helm-diagramoj kaj administrado de ili.

Ekde la liberigo de Helm 2 en 2016, Kubernetes aldonis plurajn gravajn novigojn. Aldonita rol-bazita alirkontrolo (RBAC), kiu poste anstataŭigis Attribute-Based Access Control (ABAC). Novaj rimedspecoj estis lanĉitaj (Deplojoj daŭre estis en beta tiutempe). Propraj Rimedaj Difinoj (origine nomitaj Triaj Rimedoj aŭ TPRoj) estis inventitaj. Kaj plej grave, aro de plej bonaj praktikoj aperis.

Meze de ĉiuj ĉi tiuj ŝanĝoj, Helm daŭre servis uzantojn de Kubernetes fidele. Post tri jaroj kaj multaj novaj aldonoj, evidentiĝis, ke estas tempo fari signifajn ŝanĝojn al la kodbazo por certigi, ke Helm daŭre kontentigu la kreskantajn bezonojn de evoluanta ekosistemo.

Tena adiaŭo al Tiller

Dum la disvolviĝo de Helm 2, ni enkondukis Tiller kiel parton de nia integriĝo kun la Deploja Administranto de Google. Tiller ludis gravan rolon por teamoj laborantaj ene de ofta areto: ĝi permesis al malsamaj specialistoj funkciigantaj la infrastrukturon interagi kun la sama aro de eldonoj.

Ĉar rol-bazita alirkontrolo (RBAC) estis ebligita defaŭlte en Kubernetes 1.6, labori kun Tiller en produktado iĝis pli malfacila. Pro la granda nombro da eblaj sekurecaj politikoj, nia pozicio estis oferti permesan agordon defaŭlte. Ĉi tio permesis al novuloj eksperimenti kun Helm kaj Kubernetes sen devi unue plonĝi en sekurecajn agordojn. Bedaŭrinde, ĉi tiu permesa agordo povus doti la uzanton per tro larĝa gamo da permesoj, kiujn ili ne bezonis. DevOps kaj SRE-inĝenieroj devis lerni pliajn operaciajn paŝojn instalante Tiller en plur-luanta areto.

Post lerni kiel la komunumo uzis Helm en specifaj situacioj, ni rimarkis, ke la eldona administradsistemo de Tiller ne bezonas fidi je intra-grupo komponanto por konservi staton aŭ funkcii kiel centra nabo por eldoninformoj. Anstataŭe, ni povus simple ricevi informojn de la Kubernetes API-servilo, generi diagramon ĉe la klienta flanko kaj stoki rekordon de la instalado en Kubernetes.

La ĉefa celo de Tiller povus esti atingita sen Tiller, do unu el niaj unuaj decidoj pri Helm 3 estis tute forlasi Tiller.

Kun Tiller for, la sekurecmodelo de Helm estis radikale simpligita. Helm 3 nun subtenas ĉiujn modernajn sekurecon, identecon kaj rajtigajn metodojn de nuna Kubernetes. Helm-permesoj estas determinitaj uzante kubeconfig dosiero. Registaroj povas limigi uzantrajtojn al ajna nivelo de granulareco. Eldonoj daŭre estas konservitaj ene de la areto, kaj la resto de la funkcieco de Helm restas sendifekta.

Chart-deponejoj

Je alta nivelo, diagrama deponejo estas loko kie diagramoj povas esti stokitaj kaj dividitaj. La Helm-kliento pakas kaj sendas la diagramojn al la deponejo. Simple dirite, diagrama deponejo estas primitiva HTTP-servilo kun index.yaml-dosiero kaj kelkaj pakitaj diagramoj.

Kvankam estas iuj avantaĝoj al la Charts Repository API plenumanta plej bazajn konservadpostulojn, ekzistas ankaŭ kelkaj malavantaĝoj:

Diagramdeponejoj ne estas kongruaj kun la plej multaj sekurecaj efektivigoj postulataj en produktadmedio. Havi norman API por aŭtentigo kaj rajtigo estas ege grava en produktadscenaroj.
La diagramaj devenaj iloj de Helm, uzataj por subskribi, kontroli la integrecon kaj devenon de diagramo, estas laŭvola parto de la Chart-eldonprocezo.
En multuzantaj scenaroj, la sama diagramo povas esti alŝutita de alia uzanto, duobligante la kvanton de spaco necesa por stoki la saman enhavon. Pli inteligentaj deponejoj estis evoluigitaj por solvi ĉi tiun problemon, sed ili ne estas parto de la formala specifo.
Uzi ununuran indeksdosieron por serĉi, stoki metadatenojn, kaj preni furorliston malfaciligis evoluigi sekurajn multuzantajn efektivigojn.

La projekto Docker Distribuo (ankaŭ konata kiel Docker Registry v2) estas la posteulo de Docker Registry kaj esence funkcias kiel aro de iloj por pakado, sendo, stokado kaj liverado de Docker-bildoj. Multaj grandaj nubaj servoj ofertas Distribu-bazitajn produktojn. Dank'al ĉi tiu pliigita atento, la projekto Distribution profitis el jaroj da plibonigoj, sekurecajn plej bonajn praktikojn kaj kampajn provojn, kiuj igis ĝin unu el la plej sukcesaj nekantitaj herooj de la Malfermfonta mondo.

Sed ĉu vi sciis, ke la Disdona Projekto estis desegnita por distribui ajnan enhavon, ne nur ujajn bildojn?

Dankon al la klopodoj Iniciato pri Malferma Ujo (aŭ OCI), Helm-diagramoj povas esti metitaj sur ajna Distribua okazo. Nuntempe ĉi tiu procezo estas eksperimenta. Ensalutu subteno kaj aliaj funkcioj necesaj por plena Helm 3 estas laboro en progreso, sed ni ĝojas lerni de la malkovroj kiujn la teamoj de OCI kaj Distribution faris tra la jaroj. Kaj per ilia mentorado kaj gvidado, ni lernas kiel estas funkcii tre disponeblan servon je skalo.

Pli detala priskribo de kelkaj venontaj ŝanĝoj al la Helm-diagramdeponejoj estas havebla ligilo.

Eldonadministrado

En Helm 3, aplika stato estas spurita ene de la areto per paro da objektoj:

release object - reprezentas aplikaĵon;
sekreto de eldono de versio - reprezentas la deziratan staton de la aplikaĵo en specifa momento (ekzemple, la eldono de nova versio).

Defio helm install kreas eldonobjekton kaj eldonversiosekreton. Voku helm upgrade postulas eldonobjekton (kiun ĝi povas ŝanĝi) kaj kreas novan eldonversian sekreton enhavantan la novajn valorojn kaj preparitan manifeston.

Eldonobjekto enhavas informojn pri la liberigo, kie liberigo estas specifa instalaĵo de nomita diagramo kaj valoroj. Ĉi tiu objekto priskribas la plej altnivelajn metadatenojn pri la eldono. La eldonobjekto daŭras dum la vivociklo de la aplikaĵo kaj estas la posedanto de ĉiuj eldonversiaj sekretoj, same kiel ĉiuj objektoj kiuj estas rekte kreitaj per la Helm-diagramo.

Eldonversiosekreto asocias eldonon kun serio de revizioj (instalado, ĝisdatigoj, malfunkciigo, forigo).

En Helm 2, revizioj estis ekstreme konsekvencaj. Voku helm install kreita v1, la posta ĝisdatigo (ĝisdatigo) - v2, ktp. Eldonaĵo kaj eldonversiosekreto estis kolapsitaj en ununuran objekton konatan kiel revizio. Revizioj estis stokitaj en la sama nomspaco kiel Tiller, kio signifis ke ĉiu eldono estis "tutmonda" laŭ nomspaco; kiel rezulto, nur unu okazo de la nomo povus esti uzata.

En Helm 3, ĉiu eldono estas rilata al unu aŭ pluraj eldonversiaj sekretoj. La eldonobjekto ĉiam priskribas la nunan eldonon deplojitan al Kubernetes. Ĉiu eldonversiosekreto priskribas nur unu version de tiu eldono. Ĝisdatigo, ekzemple, kreos novan eldonversian sekreton kaj poste ŝanĝos la eldonobjekton por indiki tiun novan version. En la kazo de malfunkciigo, vi povas uzi sekretojn pri antaŭaj eldonaj versioj por retrovigi la liberigon al antaŭa stato.

Post kiam Tiller estas forlasita, Helm 3 stokas eldondatenojn en la sama nomspaco kiel la liberigo. Ĉi tiu ŝanĝo ebligas instali diagramon kun la sama eldonnomo en malsama nomspaco, kaj la datumoj estas konservitaj inter areto ĝisdatigoj/reboot en ktpd. Ekzemple, vi povas instali WordPress en la nomspaco "foo" kaj poste en la nomspaco "bar", kaj ambaŭ eldonoj povas esti nomitaj "wordpress".

Ŝanĝoj al diagramaj dependecoj

Diagramoj plenplenigitaj (uzante helm package) por uzo kun Helm 2 povas esti instalita kun Helm 3, tamen la laborfluo de disvolvado de diagramo estis tute reviziita, do kelkaj ŝanĝoj devas esti faritaj por daŭrigi la disvolvon de diagramo kun Helm 3. Aparte, la diagrama dependeca administradsistemo ŝanĝiĝis.

La sistemo de administrado de dependeco de la diagramo moviĝis de requirements.yaml и requirements.lock sur Chart.yaml и Chart.lock. Ĉi tio signifas, ke la leteroj kiuj uzis la komandon helm dependency, postulas iun agordon por funkcii en Helm 3.

Ni rigardu ekzemplon. Ni aldonu dependecon al la diagramo en Helm 2 kaj vidu, kio ŝanĝiĝas dum moviĝado al Helm 3.

En Helmo 2 requirements.yaml aspektis jene:

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

En Helm 3, la sama dependeco reflektiĝos en via Chart.yaml:

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

Diagramoj daŭre estas elŝutitaj kaj metitaj en la dosierujon charts/, do subdiagramoj (subdiagramoj), kuŝanta en la katalogo charts/, daŭre funkcios sen ŝanĝoj.

Enkonduko de Biblioteko Charts

Helm 3 subtenas klason de leteroj nomataj bibliotekaj leteroj (biblioteko diagramo). Ĉi tiu diagramo estas uzata de aliaj diagramoj, sed ne kreas eldonajn artefaktojn memstare. Bibliotekaj diagramŝablonoj povas nur deklari elementojn define. Alia enhavo estas simple ignorata. Ĉi tio permesas al uzantoj reuzi kaj kunhavigi kodpecetojn, kiuj povas esti uzataj tra pluraj diagramoj, tiel evitante duobligon kaj aliĝante al la principo. SEKA.

Bibliotekaj furorlisto estas deklaritaj en la sekcio dependencies en dosiero Chart.yaml. Instali kaj administri ilin ne diferencas de aliaj leteroj.

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

Ni ĝojas pri la uzkazoj, kiujn ĉi tiu komponanto malfermos por programistoj de diagramoj, kaj ankaŭ pri la plej bonaj praktikoj kiuj povas aperi el bibliotekaj diagramoj.

Kio sekvas?

Helm 3.0.0-alpha.1 estas la fundamento sur kiu ni komencas konstrui novan version de Helm. En la artikolo mi priskribis kelkajn interesajn trajtojn de Helm 3. Multaj el ili estas ankoraŭ en la fruaj stadioj de evoluo kaj tio estas normala; La celo de alfa eldono estas testi la ideon, kolekti komentojn de fruaj uzantoj kaj konfirmi niajn supozojn.

Tuj kiam la alfa versio estas publikigita (memoru, ke ĉi tio estas jam okazis - ĉ. traduk.), ni komencos akcepti flikaĵojn por Helm 3 de la komunumo. Vi devas krei fortan fundamenton, kiu ebligas disvolvi kaj adopti novajn funkciojn, kaj ke uzantoj sentas sin implikitaj en la procezo malfermante biletojn kaj farante korektojn.

Mi provis reliefigi kelkajn el la ĉefaj plibonigoj venantaj al Helm 3, sed ĉi tiu listo tute ne estas ĝisfunda. La plena vojmapo por Helm 3 inkluzivas funkciojn kiel plibonigitajn ĝisdatigajn strategiojn, pli profundan integriĝon kun OCI-registroj kaj la uzon de JSON-skemoj por validigi diagramajn valorojn. Ni ankaŭ planas purigi la kodbazon kaj ĝisdatigi partojn de ĝi, kiuj estis neglektitaj dum la lastaj tri jaroj.

Se vi sentas, ke ni maltrafis ion, ni ŝatus aŭdi viajn pensojn!

Aliĝu al la diskuto pri nia Slack kanaloj:

#helm-users por demandoj kaj simpla komunikado kun la komunumo;
#helm-dev diskuti tirpetojn, kodon kaj cimojn.

Vi ankaŭ povas babili en niaj semajnaj Publikaj Programalvokoj ĵaŭde je 19:30 MSK. Renkontiĝoj estas dediĉitaj al diskutado de temoj pri kiuj ŝlosilaj programistoj kaj la komunumo laboras, same kiel temoj de diskuto por la semajno. Ĉiu povas aliĝi kaj partopreni en la renkontiĝo. Ligo havebla en Slack-kanalo #helm-dev.

PS de tradukisto

Legu ankaŭ en nia blogo:

fonto: www.habr.com

Enkonduko de Helm 3