🥇Iepazīšanās ar Helm 3

Piezīme:: 16. maijs šogad ir nozīmīga robežšķirtne Kubernetes pakotņu pārvaldnieka — Helm attīstībā. Šajā dienā tika prezentēts pirmais alfa izlaidums nākamajai lielajai projekta versijai — 3.0. Tā iznākšana nesīs Helm būtiskas un ilgi gaidītas izmaiņas, kuras daudzi Kubernetes kopienas dalībnieki gaida ar cerībām. Mēs paši arī esam to vidū, jo aktīvi izmantojam Helm lietojumprogrammu izvietošanai: esam integrējuši to mūsu CI/CD rīku izstrādē. werf un gadījuma gadījumā sniedzam savu ieguldījumu upstream attīstībā. Šis tulkojums apvieno 7 piezīmes no oficiālā Helm emuāra, kas piesaistītas Helm 3 pirmā alfa izlaiduma un stāsta par projekta vēsturi un galvenajām Helm 3 funkcijām. To autors ir Matis «bacongobbler» Fišers, Microsoft darbinieks un viens no galvenajiem Helm uzturētājiem.

2015. gada 15. oktobrī dzima projekts, tagad pazīstams kā Helm. Tikai gadu pēc dibināšanas Helm kopiena pievienojās Kubernetes, aktīvi strādājot pie Helm 2. 2018. gada jūnijā Helm pievienojās CNCF kā attīstošs (incubating) projekts. Pāriesim uz tagadni — un nu jau tuvojas pirmā alfa izlaiduma jaunajam Helm 3 (šis izlaidums jau notika maija vidū — piezīme tulkotājam.).

Šajā materiālā es pastāstīšu par to, kā viss sākās, kā mēs nonācām līdz šai fāzei, iepazīstināšu ar dažām unikālām īpašībām, kas pieejamas pirmajā Helm 3 alfa izlaidumā, un izskaidrošu, kā plānojam tālāk attīstīties.

Kopsavilkums:

Helm izveides vēsture;
maigs atvadu sveiciens Tiller;”
chartu krātuvēm;
izlaižu pārvaldība;
izmaiņas chartu atkarībās;
library charts;
kas tālāk?

Helm izveides vēsture

Dzimšana

Helm 1 sākās kā Open Source projekts, ko izveidoja uzņēmums Deis. Mēs bijām neliels jaunuzņēmums, ko pavasarī 2017. gadā iegādājās Microsoft. Mūsu citam Open Source projektam, kas arī saucās Deis, bija rīks deisctl, kas tika izmantots (starpp citu) kā platformas Deis uzstādīšanas un ekspluatācijas rīks Fleet klasterī.Tajā laikā Fleet bija viena no pirmajām kontēneru orķestrācijas platformām.

2015. gada vidū mēs nolēmām mainīt virzienu un pārvietojām Deis (tolaik pārdēvētu par Deis Workflow) no Fleet uz Kubernetes. Viens no pirmajiem tika pārveidots instalācijas rīks. deisctlMēs izmantojām to, lai instalētu un pārvaldītu Deis Workflow Fleet klasterī.

Helm 1 tika izstrādāts pēc tādiem zināmiem pakotņu pārvaldniekiem kā Homebrew, apt un yum. Tās galvenais mērķis bija atvieglot tādas uzdevumus kā lietojumprogrammu iepakošanu un instalēšanu Kubernetes vidē. Oficiāli Helm tika prezentēts 2015. gadā KubeCon konferencē Sanfrancisko.

Mūsu pirmā mēģinājuma ar Helm darbība bija veiksmīga, tomēr tas nesagādāja nopietnus ierobežojumus. Tas ņēma Kubernetes manifestu kopumu, papildināto ar ģeneratoriem kā ievades YAML blokiem (front-matter)*, un ielādēja rezultātus Kubernetes vidē.

* Piezīme:: Kopš pirmās Helm versijas resursu aprakstīšanai Kubernetes tika izvēlēta YAML sintakse, un konfigurāciju rakstīšanā tika atbalstīti Jinja veidnes un Python skripti. Vairāk par to un pirmās versijas Helm struktūru mēs rakstījām nodaļā "Helm īsa vēsture" šajā materiālā.

Piemēram, lai nomainītu lauku YAML failā, bija jāpapildina manifests ar sekojošo struktūru:

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

Ir lieliski, ka šodien eksistē veidnes, vai ne?

Daudzu iemeslu dēļ šis agrīnais Kubernetes instalētājs prasīja stingri noteiktu manifest failu sarakstu un veica tikai nelielu fiksētu notikumu secību. Tā lietošana bija tik grūta, ka R&D komanda Deis Workflow saskārās ar nopietnām grūtībām, mēģinot pārcelt savu produktu uz šo platformu — tomēr idejas sēklas jau bija sētas. Mūsu pirmais mēģinājums izrādījās lieliska mācību iespēja: mēs apzinājāmies, ka esam patiešām aizrauti ar pragmatisku rīku radīšanu, kas risina ikdienas problēmas mūsu lietotājiem.

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

Helm 2 izveide

2015. gada beigās sazinājās ar mums Google komanda. Viņi strādāja pie līdzīga rīka Kubernetes. Deployment Manager priekš Kubernetes bija esoša rīka ports, kas tika izmantots Google Cloud Platform. "Vai mēs negribētu, " viņi jautāja, "pavadīt dažas dienas, apspriežot 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 ambiciozu plānu: apvienot abus projektus, lai izveidotu Helm 2. Kopā ar Deis un Google izstrādātāju komanda nāca klāt puiši no SkippBox (tagad daļa no Bitnami — tulkojuma piezīme), un mēs uzsākām darbu pie Helm 2.

Mēs vēlējāmies saglabāt Helm lietošanas vienkāršību, bet pievienot sekojošo:

veidnes chartiem pielāgošanai;
iekšklasteru pārvaldība komandām;
augstākās kvalitātes chartu repozitorijs;
stabils pakotņu formāts ar parakstīšanas iespēju;
stingru apņemšanos ievērot semantisko versiju vadību un saglabāt atpakaļ savietojamību starp versijām.

Lai sasniegtu šos mērķus, Helm ekosistēmai tika pievienots otrais elements. Šis iekšklastera komponents tika nosaukts par Tiller un bija atbildīgs par Helm chartu instalēšanu un pārvaldību.

Kopš Helm 2 iznākšanas 2016. gadā Kubernetes ir ieguvis vairākus nozīmīgus jauninājumus. Tika ieviesta piekļuves pārvaldība, balstoties uz lomām (RBAC), kas beidzot aizstāja piekļuves kontroli, balstoties uz atribūtiem (ABAC). Parādījās jauni resursu veidi (Deployments tolaik vēl atradās beta versijā). Tika izgudrotas Custom Resource Definitions (sākotnēji tās tika sauktas par Third Party Resources vai TPRs). Un, pats galvenais — parādījās labāko prakses piemēru kopums.

Visu šo izmaiņu fona gaismā Helm turpināja kalpot Kubernetes lietotājiem. Pēc trim gadiem un daudziem jaunajiem papildinājumiem kļuva skaidrs, ka ir pienācis laiks veikt būtiskas izmaiņas kodā, lai Helm varētu turpināt apmierināt augošās prasības attiecībā uz attīstīgu ekosistēmu.

Maigs atvadu sveiciens Tiller'iem

Helm 2 izstrādāšanas laikā mēs prezentējām Tiller kā daļu no mūsu integrācijas ar Google izstrādāto Deployment Manager. Tiller spēlēja nozīmīgu lomu komandām, kas strādāja kopējā klasterī: tas ļāva dažādiem speciālistiem, kuri ekspluatēja infrastruktūru, sadarboties ar vienu un to pašu izlaidumu komplektu.

Kopš lomas balstīta piekļuves kontrole (RBAC) tika ieviesta pēc noklusējuma Kubernetes 1.6 versijā, darbs ar Tiller ražošanā kļuva sarežģītāks. Lielo drošības politiku skaita dēļ mūsu pozīcija bija piedāvāt atļaujošu konfigurāciju pēc noklusējuma. Tas ļāva iesācējiem eksperimentēt ar Helm un Kubernetes, neskatoties uz iepriekšēju drošības iestatījumu apguvi. Diemžēl šī atļaujošā konfigurācija varēja piešķirt lietotājam pārāk plašas atļaujas, kas viņam nebija nepieciešamas. DevOps un SRE inženieriem vajadzēja apgūt papildus darbības, instalējot Tiller vairāku lietotāju (multi-tenant) klasterī.

Saprotot, kā kopienas pārstāvji izmanto Helm konkrētās situācijās, mēs sapratām, ka Tiller izlaidumu pārvaldības sistēmai nav jāpaļaujas uz iekšējo komponentu, lai uzturētu stāvokļus vai darbotos kā centrālais centrs ar informāciju par izlaidumiem. Tā vietā mēs varējām vienkārši iegūt informāciju no Kubernetes API servera, ģenerēt chart klienta pusē un saglabāt uzstādīšanas ierakstu Kubernetes.

Galvenā Tiller funkcionalitāte varēja tikt īstenota arī bez Tiller, tāpēc viens no pirmajiem mūsu lēmumiem attiecībā uz Helm 3 bija pilnīga atteikšanās no Tiller.

Atsakoties no Tiller, Helm drošības modelis radikāli vienkāršojās. Helm 3 tagad atbalsta visas mūsdienu drošības, identifikācijas un autorizācijas metodes, kas ir pieejamas pašreizējā Kubernetes. Helm atļaujas tiek noteiktas, izmantojot kubeconfig failu.Klastera administratori var ierobežot lietotāju tiesības ar jebkādu detalizācijas pakāpi. Izlaidumi joprojām tiek saglabāti klasterī, bet visa Helm funkcionalitāte paliek.

Chartu repozitoriji

Augstākā līmenī chartu repozitorijs ir vieta, kur uzglabāt un koplietot chartus. Helm klients iepakot un nosūta chartus uz repozitoriju. Vienkāršoti sakot, chartu repozitorijs ir primitīvs HTTP serveris ar index.yaml failu un dažiem iepakotiem chartiem.

Lai gan ir daži ieguvumi no tā, ka chartu repozitorija API atbilst vispārējām krātuves prasībām, tam ir arī daži trūkumi:

Chart repozitoriji ir vāji savietojami ar lielāko daļu drošības īstenojumu, kas nepieciešami ražošanas vidē. Standarta API autentifikācijai un autorizācijai esamība ir ārkārtīgi svarīga ražošanas scenārijos.
Helm rīki chart izcelsmes izsekošanai, kas tiek izmantoti parakstīšanai, integritātes pārbaudēm un chart izcelsmes noteikšanai, ir obligātā daļa no Chart publicēšanas procesa.
Daudzlietotāju scenārijos vienu un to pašu chart var augšupielādēt cits lietotājs, otrreiz palielinot nepieciešamās krātuves apjomu vienam un tam pašam saturam. Lai risinātu šo problēmu, tika izstrādāti saprātīgāki repozitoriji, taču tie nav daļa no formālās specifikācijas.
Vienotā indeksu faila izmantošana, lai meklētu, glabātu metadatus un iegūtu chart, sarežģījusi drošu daudzlietotāju īstenojumu izstrādi.

Projekts Docker Distribution (pazīstams arī kā Docker Registry v2) ir Docker Registry pēctecis un faktiski ir rīku kopums Docker attēlu iepakošanai, nosūtīšanai, glabāšanai un piegādāšanai. Daudzi lielie mākoņa pakalpojumi piedāvā produktus, kas balstīti uz Distribution. Šis pastiprinātais uzmanības līmenis ir devis iespēju projekts Distribution gūt labumu no daudzu gadu uzlabojumiem, drošības labākajām praksēm un testēšanas reālā vidē, padarot to par vienu no veiksmīgākajiem neizceltajiem varoņiem atvērtā koda pasaulē.

Bet vai zinājāt, ka projekts Distribution tika izstrādāts, lai izplatītu jebkādu satura formu, ne tikai konteineru attēlus?

Pateicoties Open Container Initiative (vai OCI), Helm chart var tikt izvietots jebkurā Distribution instancē. Pašlaik šis process ir eksperimentālā posmā. Darbs pie atbalsta pieteikšanās un citām funkcijām, kas nepieciešamas pilnvērtīgam Helm 3, vēl nav pabeigts, taču mēs ļoti priecājamies par iespēju mācīties no atklājumiem, ko izdarījušas OCI un Distribution komandas šajos gados. Un pateicoties viņu mentorēšanai un vadībai, mēs uzzinām, kā ir darboties augsta pieejamības pakalpojumam lielā mērogā.

Sīkāka informācija par dažām gaidāmajām izmaiņām Helm chart repozitorijos ir pieejama caur saiti.

Izlaižu pārvaldība

Helm 3 lietojumprogrammas stāvoklis tiek izsekots iekšējā klasterī ar pāru objektiem:

release object — pārstāv lietojumprogrammas instanci;
release version secret — attēlo vēlamo lietojumprogrammas stāvokli konkrētā brīdī (piemēram, jauna versija).

Izsaukt helm install izveido release object un release version secret. Izsaukums helm upgrade prasa esošā release object (kuru tas var mainīt) un izveido jaunu release version secret, kas satur jaunās vērtības un sagatavoto manifestu.

Release object satur informāciju par relīzi, kur relīze — ir konkrēta nosauktā chart un vērtību instalācija. Šis objekts apraksta meta datus augsta līmeņa par relīzi. Release object tiek saglabāts visas lietojumprogrammas dzīves cikla laikā un ir visu release version secret īpašnieks, kā arī visu objektu, kas tieši tiek izveidoti ar Helm chart, īpašnieks.

Release version secret sasaista relīzi ar revīziju sēriju (instalācija, atjauninājumi, atgriešana, dzēšana).

Helm 2 revīzijas bija tikai sekvenšas. Izsaukums helm install izveidoja v1, sekojošs atjauninājums (upgrade) — v2, un tā tālāk. Release un release version secret bija apvienoti vienā objektā, kas pazīstams kā revision. Revision’iem tika glabāti tajā pašā nosaukuma telpā, kur arī Tiller, kas nozīmēja, ka katra relīze bija "globāla" nosaukuma telpā; rezultātā nosaukumu varēja izmantot tikai vienā eksemplārā.

Helm 3 katra relīze ir saistīta ar vienu vai vairākiem release version secret’iem. Release object vienmēr apraksta pašreizējo relīzi, kas izvietota Kubernetes. Katrs release version secret apraksta tikai vienu šīs relīzes versiju. Atjaunināšana (upgrade), piemēram, izveidos jaunu release version secret un pēc tam mainīs release object, lai tas norādītu uz šo jauno versiju. Atgriešanās (rollback) gadījumā var izmantot iepriekšējos release version secret’us, lai atgrieztu relīzi iepriekšējā stāvoklī.

Pēc Tiller atteikšanās Helm 3 glabā relīzes datus vienā nosaukuma telpā ar relīzi. Šāda izmaiņa ļauj instalēt chart ar tādu pašu relīzes nosaukumu citā nosaukuma telpā, un dati tiek saglabāti starp atjauninājumiem/klastera restartiem etcd. Piemēram, var instalēt WordPress nosaukuma telpā "foo", un pēc tam nosaukuma telpā "bar", un abas relīzes var tikt sauktas par "wordpress".

Izmaiņas chart atkarībās

Chart, kas iepakoti (izmantojot helm package) lietošanai ar Helm 2 var instalēt ar Helm 3, tomēr grafiku izstrādes process ir pilnībā pārskatīts, tādēļ ir nepieciešamas dažas izmaiņas, lai turpinātu grafiku izstrādi ar Helm 3. Proti, ir mainījusies grafiku atkarību pārvaldības sistēma.

Grafiku atkarību pārvaldība ir pārgājusi no requirements.yaml un requirements.lock uz Chart.yaml un Chart.lock. Tas nozīmē, ka grafiki, kas izmantoja komandu helm dependency, prasa dažas konfigurācijas izmaiņas, lai strādātu Helm 3.

Paskatīsimies piemēru. Pievienosim atkarību grafikam Helm 2 un redzēsim, kas mainīsies, pārejot uz Helm 3.

Helm 2 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

Helm 3 tajā pašā atkarībā 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

Grafiki joprojām tiek ielādēti un novietoti direktorijā charts/, tādējādi apakšgrafiki (subcharts), kas atrodas katalogā charts/, turpinās darboties bez izmaiņām.

Iepazīstinām ar Library Charts

Helm 3 atbalsta grafiku veidu, ko sauc par bibliotēku grafikiem (library chart). Šis grafiks tiek izmantots citu grafiku, bet pats nenodod nevienu izlaiduma artefaktu. Library chart'ā var deklarēt tikai elementus define. Citi saturs tiek vienkārši ignorēts. Tas ļauj lietotājiem atkārtoti izmantot un apmainīties ar kodola fragmentiem, kurus var iekļaut daudzos grafikos, tādējādi izvairoties no dublēšanas un ievērojot principu DRY.

Bibliotēku grafiki tiek deklarēti sadaļā atkarības failā Chart.yaml. To uzstādīšana un pārvaldība neatšķiras no citiem grafikiem.

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

Mēs ar nepacietību gaidām iespējas, kuras šis komponents atklās grafiku izstrādātājiem, kā arī labāko praksi, kas var rasties pateicoties bibliotēku grafikām.

Kas tālāk?

Helm 3.0.0-alpha.1 ir pamats, uz kura mēs sākam veidot jauno Helm versiju. Rakstā es aprakstīju dažas interesantas Helm 3 iespējas. Daudzas no tām joprojām ir agrīnā izstrādes stadijā, un tas ir normāli; alfa izlaiduma būtība ir pārbaudīt ideju, vākt atsauksmes no pirmajiem lietotājiem un apstiprināt mūsu pieņēmumus.

Kad alfa versija tiks izlaista (atgādinām, ka tas jau ir noticis — piezīme tulkotājam), mēs sāksim pieņemt Helm 3 ielāpus no kopienas. Ir nepieciešams izveidot uzticamu pamatu, kas ļaus izstrādāt un pieņemt jaunas funkcionalitātes, un lietotāji varēs justies iesaistīti procesā, atverot biļetes un iesniedzot labojumus.

Rakstā es cenšos izcelt dažus nozīmīgus uzlabojumus, kas parādīsies Helm 3, tomēr šo sarakstu nekādā gadījumā nevar uzskatīt par izsmeļošu. Pilnīgs plāns Helm 3 ietver tādas inovācijas kā uzlabotas atjaunināšanas stratēģijas, dziļāka integrācija ar OCI reģistriem un JSON shēmu izmantošana chart vērtību validēšanai. Mēs arī plānojam attīrīt koda bāzi un atjaunināt tās daļas, kuras pēdējos trīs gadus palikušas bez uzmanības.

Ja jūtat, ka mēs kaut ko esam palaiduši garām, labprāt dzirdētu jūsu domas!

Pievienojieties diskusijai mūsu Slack kanālos:

#helm-users jautājumiem un vienkāršai saziņai ar kopienu;
#helm-dev diskusijām par pull requests, kodu un kļūdām.

Jūs arī varat sazināties mūsu nedēļas Public Developer Calls ceturtdienās plkst. 19:30 MSK. Sanāksmes ir veltītas tēmu apspriešanai, pie kurām strādā galvenie izstrādātāji un kopiena, kā arī nedēļas diskusiju tēmām. Ikviens var pievienoties un piedalīties sanāksmē. Saite ir pieejama Slack kanālā #helm-dev.

P.S. no tulka

Lasiet arī mūsu emuāra rakstos:

Avots: habr.com