IepazÄ«stinām ar Helm 3

IepazÄ«stinām ar Helm 3

PiezÄ«me. tulk.: Ŕī gada 16. maijs iezÄ«mē nozÄ«mÄ«gu pavērsienu Kubernetes - Helm pakotņu pārvaldnieka attÄ«stÄ«bā. Å ajā dienā tika prezentēts projekta topoŔās galvenās versijas pirmais alfa laidiens - 3.0. Tā izlaiÅ”ana ienesÄ«s Helm nozÄ«mÄ«gas un ilgi gaidÄ«tas izmaiņas, uz kurām daudzi Kubernetes kopienā saista lielas cerÄ«bas. Mēs paÅ”i esam viens no tiem, jo ā€‹ā€‹mēs aktÄ«vi izmantojam Helm lietojumprogrammu izvietoÅ”anai: esam to integrējuÅ”i mÅ«su CI/CD ievieÅ”anas rÄ«kā. werf un laiku pa laikam mēs sniedzam savu ieguldÄ«jumu augÅ”teces attÄ«stÄ«bā. Å ajā tulkojumā ir apvienotas 7 piezÄ«mes no oficiālā Helm emuāra, kas ir veltÄ«tas Helm 3 pirmajam alfa izlaidumam un stāsta par projekta vēsturi un Helm 3 galvenajām iezÄ«mēm. To autors ir Mets ā€œbacongobblerā€ FiÅ”ers, Microsoft darbinieks. un viens no galvenajiem Helm uzturētājiem.

15. gada 2015. oktobrÄ« piedzima projekts, kas tagad pazÄ«stams kā Helm. Tikai gadu pēc tās dibināŔanas Helmas kopiena pievienojās Kubernetes, vienlaikus aktÄ«vi strādājot pie Helm 2. 2018. gada jÅ«nijā Helm pievienojās CNCF kā attÄ«stÄ«bas (inkubācijas) projekts. Ātri pārejiet uz mÅ«sdienām, un jaunā Helm 3 pirmā alfa versija ir ceļā. (Å”is izlaidums jau ir noticis maija vidÅ« - apm. tulk.).

Å ajā rakstā es runāŔu par to, kur tas viss sākās, kā mēs nokļuvām tur, kur esam Å”odien, iepazÄ«stināŔu ar dažām unikālajām funkcijām, kas pieejamas pirmajā Helm 3 alfa laidienā, un paskaidroÅ”u, kā mēs plānojam virzÄ«ties uz priekÅ”u.

Kopsavilkums

  • Helmas izveides vēsture;
  • maigas atvadas no Tillera;
  • diagrammu krātuves;
  • izlaiÅ”anas vadÄ«ba;
  • izmaiņas diagrammu atkarÄ«bās;
  • bibliotēku diagrammas;
  • ko tālāk?

Helmas vēsture

DzimŔana

Helm 1 sākās kā Deisa izveidots atvērtā pirmkoda projekts. Mēs bijām mazs startup uzsÅ«cas Microsoft 2017. gada pavasarÄ«. MÅ«su citam atvērtā pirmkoda projektam, ko sauc arÄ« par Deisu, bija rÄ«ks deisctl, kas tika izmantota (cita starpā), lai instalētu un darbinātu Deis platformu Flotes klasteris. Tajā laikā Fleet bija viena no pirmajām konteineru orÄ·estrÄ“Å”anas platformām.

2015. gada vidū mēs nolēmām mainīt kursu un pārcēlām Deis (tolaik pārdēvēja par Deis Workflow) no Fleet uz Kubernetes. Viens no pirmajiem, kas tika pārveidots, bija instalācijas rīks. deisctl. Mēs to izmantojām, lai instalētu un pārvaldītu Deis Workflow flotes klasterī.

Helm 1 tika izveidots pēc slavenu pakotņu pārvaldnieku, piemēram, Homebrew, apt un yum, tēla. Tās galvenais mērÄ·is bija vienkārÅ”ot tādus uzdevumus kā iesaiņoÅ”ana un lietojumprogrammu instalÄ“Å”ana vietnē Kubernetes. Helms oficiāli tika prezentēts 2015. gadā KubeCon konferencē Sanfrancisko.

MÅ«su pirmais mēģinājums ar Helmu izdevās, taču tas nebija bez nopietniem ierobežojumiem. ViņŔ paņēma Kubernetes manifestu komplektu, kas papildināts ar Ä£eneratoriem kā ievada YAML blokus. (priekŔējais jautājums)* un ielādēja rezultātus Kubernetes.

* PiezÄ«me. tulk.: no pirmās Helm versijas YAML sintakse tika izvēlēta, lai aprakstÄ«tu Kubernetes resursus, un, rakstot konfigurācijas, tika atbalstÄ«tas Jinja veidnes un Python skripti. Vairāk par to un Helmas pirmās versijas uzbÅ«vi kopumā rakstÄ«jām nodaļā ā€œÄŖsa Helmas vēstureā€ Å”o materiālu.

Piemēram, lai YAML failā aizstātu lauku, manifestam bija jāpievieno Ŕāda konstrukcija:

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

Tas ir lieliski, ka mūsdienās pastāv veidņu dzinēji, vai ne?

Daudzu iemeslu dēļ Å”im agrÄ«najam Kubernetes instalētājam bija nepiecieÅ”ams cieti kodēts manifesta failu saraksts un tika izpildÄ«ta tikai neliela, fiksēta notikumu secÄ«ba. To bija tik grÅ«ti izmantot, ka Deis Workflow R&D komandai bija grÅ«ti, mēģinot pārnest savu produktu uz Å”o platformu ā€“ tomēr idejas sēklas jau bija iesētas. MÅ«su pirmais mēģinājums bija lieliska mācÄ«bu iespēja: mēs sapratām, ka esam patiesi aizrautÄ«gi ar pragmatisku rÄ«ku izveidi, kas risina mÅ«su lietotāju ikdienas problēmas.

Pamatojoties uz pagātnes kļūdu pieredzi, mēs sākām izstrādāt Helm 2.

Stūres izgatavoŔana 2

2015. gada beigās Google komanda ar mums sazinājās. Viņi strādāja pie lÄ«dzÄ«ga Kubernetes rÄ«ka. Kubernetes izvietoÅ”anas pārvaldnieks bija esoÅ”a rÄ«ka ports, kas tika izmantots pakalpojumam Google Cloud Platform. "Vai mēs vēlētos," viņi jautāja, "pavadÄ«t dažas dienas, lai apspriestu lÄ«dzÄ«bas un atŔķirÄ«bas?"

2016. gada janvārÄ« Helm un Deployment Manager komandas tikās Sietlā, lai apmainÄ«tos ar idejām. Sarunas beidzās ar vērienÄ«gu plānu: apvienot abus projektus, lai izveidotu Helm 2. Kopā ar Deisu un Google puiÅ”i no plkst. SkipBox (tagad daļa no Bitnami ā€” aptuveni tulk.), un mēs sākām strādāt pie Helm 2.

Mēs vēlējāmies saglabāt Helm lietoÅ”anas ērtumu, taču pievienojiet tālāk norādÄ«to.

  • diagrammu veidnes pielāgoÅ”anai;
  • klasteru iekŔēja vadÄ«ba komandām;
  • pasaules klases diagrammu repozitorijs;
  • stabils pakotnes formāts ar paraksta iespēju;
  • stingra apņemÅ”anās nodroÅ”ināt semantisko versiju veidoÅ”anu un saglabāt atgriezenisku saderÄ«bu starp versijām.

Lai sasniegtu Å”os mērÄ·us, Helmas ekosistēmai ir pievienots otrs elements. Å o klastera iekŔējo komponentu sauca par Tiller, un tas bija atbildÄ«gs par Helm diagrammu instalÄ“Å”anu un to pārvaldÄ«bu.

KopÅ” Helm 2 izlaiÅ”anas 2016. gadā Kubernetes ir pievienojis vairākus nozÄ«mÄ«gus jauninājumus. Pievienota uz lomu balstÄ«ta piekļuves kontrole (RBAC), kas galu galā aizstāja uz atribÅ«tiem balstÄ«tu piekļuves kontroli (ABAC). Tika ieviesti jauni resursu veidi (tolaik izvietoÅ”ana vēl bija beta versijā). Tika izgudrotas pielāgotas resursu definÄ«cijas (sākotnēji sauktas par TreŔās puses resursiem vai TPR). Un pats galvenais, ir izveidojies paraugprakses kopums.

Visu Å”o izmaiņu laikā Helm turpināja uzticÄ«gi apkalpot Kubernetes lietotājus. Pēc trim gadiem un daudziem jauniem papildinājumiem bija skaidrs, ka ir pienācis laiks veikt bÅ«tiskas izmaiņas kodu bāzē, lai nodroÅ”inātu, ka Helm varētu turpināt apmierināt augoŔās ekosistēmas vajadzÄ«bas.

Maigas atvadas no Tillera

Helm 2 izstrādes laikā mēs ieviesām Tiller kā daļu no mÅ«su integrācijas ar Google izvietoÅ”anas pārvaldnieku. Tiller spēlēja svarÄ«gu lomu komandām, kas strādāja kopējā klasterÄ«: tas ļāva dažādiem speciālistiem, kas izmanto infrastruktÅ«ru, mijiedarboties ar vienu un to paÅ”u izlaidumu kopu.

Tā kā Kubernetes 1.6 versijā pēc noklusējuma tika iespējota uz lomu balstÄ«ta piekļuves kontrole (RBAC), darbs ar Tiller ražoÅ”anas procesā kļuva grÅ«tāks. Ņemot vērā iespējamo droŔības politiku milzÄ«go skaitu, mÅ«su nostāja ir bijusi pēc noklusējuma piedāvāt pieļaujamu konfigurāciju. Tas ļāva iesācējiem eksperimentēt ar Helm un Kubernetes, vispirms neiedziļinoties droŔības iestatÄ«jumos. Diemžēl Ŕī atļauju konfigurācija var nodroÅ”ināt lietotāju ar pārāk plaÅ”u atļauju klāstu, kas viņam nebija vajadzÄ«gas. Instalējot Tiller vairāku nomnieku klasterÄ«, DevOps un SRE inženieriem bija jāapgÅ«st papildu darbÄ«bas.

Uzzinot, kā kopiena izmanto Helm konkrētās situācijās, mēs sapratām, ka Tiller laidienu pārvaldÄ«bas sistēmai nav jāpaļaujas uz klastera iekŔējo komponentu, lai uzturētu stāvokļus vai darbotos kā centrālais izlaiÅ”anas informācijas centrs. Tā vietā mēs varētu vienkārÅ”i saņemt informāciju no Kubernetes API servera, Ä£enerēt diagrammu klienta pusē un saglabāt instalÄ“Å”anas ierakstu Kubernetes.

Tillera galveno mērķi varēja sasniegt bez Tillera, tāpēc viens no mūsu pirmajiem lēmumiem attiecībā uz Helm 3 bija pilnībā atteikties no Tillera.

LÄ«dz ar Tillera aizieÅ”anu Helmas droŔības modelis ir radikāli vienkārÅ”ots. Helm 3 tagad atbalsta visas paÅ”reizējās Kubernetes mÅ«sdienu droŔības, identitātes un autorizācijas metodes. StÅ«res atļaujas tiek noteiktas, izmantojot kubeconfig failu. Klasteru administratori var ierobežot lietotāju tiesÄ«bas lÄ«dz jebkuram precizitātes lÄ«menim. Izlaidumi joprojām tiek saglabāti klasterÄ«, un pārējā Helm funkcionalitāte paliek neskarta.

Diagrammu krātuves

Augstā līmenī diagrammu repozitorijs ir vieta, kur diagrammas var uzglabāt un koplietot. Helm klients iepako un nosūta diagrammas uz repozitoriju. VienkārŔi sakot, diagrammu repozitorijs ir primitīvs HTTP serveris ar failu index.yaml un dažām iepakotām diagrammām.

Lai gan Charts Repository API, kas atbilst lielākajai daļai pamata krātuves prasību, ir dažas priekŔrocības, ir arī daži trūkumi:

  • Diagrammu krātuves nav saderÄ«gas ar lielāko daļu droŔības ievieÅ”anu, kas nepiecieÅ”ama ražoÅ”anas vidē. Standarta API autentifikācijai un autorizācijai ir ārkārtÄ«gi svarÄ«gi ražoÅ”anas scenārijos.
  • Helmas diagrammas izcelsmes rÄ«ki, ko izmanto, lai parakstÄ«tu, pārbaudÄ«tu diagrammas integritāti un izcelsmi, ir diagrammas publicÄ“Å”anas procesa izvēles daļa.
  • Vairāku lietotāju scenārijos vienu un to paÅ”u diagrammu var augÅ”upielādēt cits lietotājs, tādējādi dubultojot vietas daudzumu, kas nepiecieÅ”ams viena un tā paÅ”a satura glabāŔanai. Lai atrisinātu Å”o problēmu, ir izstrādātas viedākas krātuves, taču tās neietilpst oficiālajā specifikācijā.
  • Viena indeksa faila izmantoÅ”ana meklÄ“Å”anai, metadatu glabāŔanai un diagrammu izgÅ«Å”anai ir apgrÅ«tinājusi droÅ”u vairāku lietotāju ievieÅ”anu.

Projekts Docker izplatÄ«Å”ana (pazÄ«stams arÄ« kā Docker Registry v2) ir Docker Registry pēctecis un bÅ«tÄ«bā darbojas kā rÄ«ku komplekts Docker attēlu iesaiņoÅ”anai, nosÅ«tÄ«Å”anai, uzglabāŔanai un piegādei. Daudzi lieli mākoņpakalpojumi piedāvā uz izplatÄ«Å”anu balstÄ«tus produktus. Pateicoties Å”ai pastiprinātajai uzmanÄ«bai, Distribution projekts ir guvis labumu no gadiem ilgiem uzlabojumiem, droŔības paraugprakses un lauka testÄ“Å”anas, kas padarÄ«ja to par vienu no veiksmÄ«gākajiem neapdziedātajiem varoņiem atvērtā pirmkoda pasaulē.

Bet vai zinājāt, ka izplatÄ«Å”anas projekts tika izstrādāts, lai izplatÄ«tu jebkāda veida saturu, ne tikai konteineru attēlus?

Pateicoties pÅ«lēm Atvērt konteineru iniciatÄ«vu (vai OCI), stÅ«res diagrammas var ievietot jebkurā izplatÄ«Å”anas instancē. Pagaidām Å”is process ir eksperimentāls. PieteikÅ”anās atbalsts un citas funkcijas, kas nepiecieÅ”amas pilnam Helm 3, ir darbs, taču mēs ar prieku varam mācÄ«ties no atklājumiem, ko OCI un izplatÄ«Å”anas komandas ir veikuÅ”as gadu gaitā. Pateicoties viņu mentoringam un norādÄ«jumiem, mēs uzzinām, kā ir nodroÅ”ināt ļoti pieejamu pakalpojumu plaŔā mērogā.

Ir pieejams detalizētāks apraksts par dažām gaidāmajām izmaiņām Helm diagrammu krātuvēs ŠæŠ¾ ссыŠ»ŠŗŠµ.

Izlaidumu pārvaldība

Programmā Helm 3 lietojumprogrammas stāvokli klasterÄ« izseko objektu pāris:

  • izlaiÅ”anas objekts ā€” apzÄ«mē lietojumprogrammas gadÄ«jumu;
  • izlaiduma versijas noslēpums - apzÄ«mē vēlamo lietojumprogrammas stāvokli noteiktā brÄ«dÄ« (piemēram, jaunas versijas izlaiÅ”ana).

Zvans helm install izveido izlaiÅ”anas objektu un laidiena versijas noslēpumu. Zvaniet helm upgrade pieprasa izlaiÅ”anas objektu (ko tas var mainÄ«t) un izveido jaunas laidiena versijas noslēpumu, kas satur jaunās vērtÄ«bas un sagatavotu manifestu.

Izlaiduma objekts satur informāciju par laidienu, kur laidiens ir konkrēta nosauktas diagrammas un vērtÄ«bu instalācija. Å is objekts apraksta augstākā lÄ«meņa metadatus par laidienu. Izlaiduma objekts saglabājas visā lietojumprogrammas dzÄ«ves ciklā un ir visu laidiena versiju noslēpumu Ä«paÅ”nieks, kā arÄ« visi objekti, kas ir tieÅ”i izveidoti Helm diagrammā.

Laidiena versijas noslēpums saista laidienu ar virkni labojumu (instalÄ“Å”ana, atjauninājumi, atcelÅ”ana, dzÄ“Å”ana).

Helm 2 pārskatÄ«Å”anas bija ļoti konsekventas. Zvaniet helm install izveidots v1, sekojoÅ”ais atjauninājums (upgrade) - v2 utt. Izlaiduma un izlaiduma versijas noslēpums ir sakļauts vienā objektā, kas pazÄ«stams kā pārskatÄ«Å”ana. Pārskati tika glabāti tajā paŔā nosaukumvietā kā Tiller, kas nozÄ«mēja, ka katrs laidiens bija "globāls" nosaukumvietas ziņā; rezultātā varēja izmantot tikai vienu nosaukuma gadÄ«jumu.

Programmā Helm 3 katrs laidiens ir saistÄ«ts ar vienu vai vairākiem laidiena versijas noslēpumiem. Izlaiduma objekts vienmēr apraksta paÅ”reizējo Kubernetes laidienu. Katrs laidiena versijas noslēpums apraksta tikai vienu Ŕī laidiena versiju. Piemēram, jaunināŔana izveidos jaunas laidiena versijas noslēpumu un pēc tam mainÄ«s laidiena objektu, lai norādÄ«tu uz Å”o jauno versiju. AtcelÅ”anas gadÄ«jumā varat izmantot iepriekŔējās laidiena versijas noslēpumus, lai atgrieztu laidienu uz iepriekŔējo stāvokli.

Pēc tam, kad Tiller ir pamests, Helm 3 izlaiduma datus glabā tajā paŔā nosaukumvietā, kurā atrodas izlaidums. Å Ä«s izmaiņas ļauj instalēt diagrammu ar tādu paÅ”u laidiena nosaukumu citā nosaukumvietā, un dati tiek saglabāti starp klasteru atjauninājumiem/atsāknÄ“Å”anu programmā etcd. Piemēram, varat instalēt WordPress nosaukumvietā "foo" un pēc tam nosaukumvietā "bar", un abus laidienus var nosaukt par "wordpress".

Izmaiņas diagrammu atkarībās

Iepakotas diagrammas (izmantojot helm package) lietoÅ”anai ar Helm 2 var instalēt ar Helm 3, tomēr diagrammu izstrādes darbplÅ«sma ir pilnÄ«bā pārveidota, tāpēc ir jāveic dažas izmaiņas, lai turpinātu diagrammu izstrādi ar Helm 3. Jo Ä«paÅ”i ir mainÄ«jusies diagrammu atkarÄ«bas pārvaldÄ«bas sistēma.

Diagrammas atkarÄ«bas pārvaldÄ«bas sistēma ir pārvietota no requirements.yaml Šø requirements.lock par Chart.yaml Šø Chart.lock. Tas nozÄ«mē, ka diagrammas, kas izmantoja komandu helm dependency, nepiecieÅ”ama noteikta iestatÄ«Å”ana, lai darbotos Helm 3.

ApskatÄ«sim piemēru. Pievienosim atkarÄ«bu Helm 2 diagrammai un redzēsim, kas mainās, pārejot uz Helm 3.

2. stÅ«rē requirements.yaml izskatÄ«jās Ŕādi:

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

Stūrē 3 tā pati atkarība tiks atspoguļota jūsu Chart.yaml:

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

Diagrammas joprojām tiek lejupielādētas un ievietotas direktorijā charts/, tātad apakÅ”diagrammas (apakÅ”diagrammas), kas atrodas katalogā charts/, turpinās strādāt bez izmaiņām.

Iepazīstinām ar bibliotēku diagrammām

Helm 3 atbalsta diagrammu klasi, ko sauc par bibliotēku diagrammām (bibliotēkas diagramma). Å o diagrammu izmanto citas diagrammas, taču tā pati nerada nekādus izlaiÅ”anas artefaktus. Bibliotēkas diagrammas veidnes var deklarēt tikai elementus define. Cits saturs tiek vienkārÅ”i ignorēts. Tas ļauj lietotājiem atkārtoti izmantot un koplietot koda fragmentus, ko var izmantot vairākās diagrammās, tādējādi izvairoties no dublÄ“Å”anās un saglabājot principu. DRY.

Bibliotēkas diagrammas ir deklarētas sadaļā dependencies failā Chart.yaml. To instalÄ“Å”ana un pārvaldÄ«ba neatŔķiras no citām diagrammām.

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

Mēs priecājamies par lietoÅ”anas gadÄ«jumiem, ko Å”is komponents pavērs diagrammu izstrādātājiem, kā arÄ« par labāko praksi, kas var parādÄ«ties no bibliotēku diagrammām.

Ko tālāk?

Helm 3.0.0-alpha.1 ir pamats, uz kura mēs sākam veidot jaunu Helm versiju. Rakstā es aprakstīju dažas interesantas Helm 3 iezīmes. Daudzas no tām joprojām ir attīstības sākuma stadijā, un tas ir normāli; Alfa versijas mērķis ir pārbaudīt ideju, apkopot atsauksmes no agrīnajiem lietotājiem un apstiprināt mūsu pieņēmumus.

TiklÄ«dz iznāks alfa versija (atcerieties, ka tas ir jau noticis ā€” apm. tulk.), mēs sāksim pieņemt Helm 3 ielāpus no kopienas. Jums ir jāizveido spēcÄ«gs pamats, kas ļauj izstrādāt un pieņemt jaunas funkcionalitātes, un lietotāji var justies iesaistÄ«ti procesā, atverot biļetes un veicot labojumus.

Esmu mēģinājis izcelt dažus no galvenajiem Helm 3 uzlabojumiem, taču Å”is saraksts nekādā ziņā nav pilnÄ«gs. Pilnajā Helm 3 ceļvedÄ« ir iekļautas tādas funkcijas kā uzlabotas atjaunināŔanas stratēģijas, dziļāka integrācija ar OCI reÄ£istriem un JSON shēmu izmantoÅ”ana diagrammu vērtÄ«bu apstiprināŔanai. Mēs arÄ« plānojam iztÄ«rÄ«t kodu bāzi un atjaunināt tās daļas, kas pēdējos trÄ«s gadus ir atstātas novārtā.

Ja jÅ«tat, ka esam kaut ko palaiduÅ”i garām, mēs labprāt uzklausÄ«sim jÅ«su domas!

Pievienojieties mūsu diskusijai Slack kanāli:

  • #helm-users jautājumiem un vienkārÅ”ai komunikācijai ar sabiedrÄ«bu;
  • #helm-dev lai apspriestu izvilkÅ”anas pieprasÄ«jumus, kodu un kļūdas.

Varat arī tērzēt mūsu iknedēļas publiskajos izstrādātāju zvanos ceturtdienās plkst. 19:30 MSK. Sanāksmes ir veltītas, lai apspriestu jautājumus, pie kuriem strādā galvenie izstrādātāji un sabiedrība, kā arī nedēļas diskusiju tēmas. Ikviens var pievienoties un piedalīties sanāksmē. Saite pieejama Slack kanālā #helm-dev.

PS no tulka

Lasi arī mūsu emuārā:

Avots: www.habr.com

Pievieno komentāru