🥇Tutvumine Helm 3

Märk. tõlge.: 16. mai sel aastal on tähistav oluline verstapost Kubernetes'i pakihaldur - Helm. Sel päeval esitleti projekti tulevase suurversiooni - 3.0 - esimest alpha-väljaannet. Selle väljalaskmine toob Helmi olulisi ja kauaoodatud muudatusi, millele paljud Kubernetes'i kogukonna liikmed loodavad. Meie kuulume nende hulka, kuna kasutame aktiivselt Helmi rakenduste juurutamiseks: oleme integreerinud selle oma CI/CD tööriistadesse. werf ja toome aeg-ajalt oma panuse upstream'i arendamisse. See tõlge ühendab 7 märkust Helmi ametlikust blogist, mis on seotud Helmi 3 esimesest alpha-väljaandest ja räägivad projekti ajaloost ja Helmi 3 peamistest omadustest. Nende autor on Matt «bacongobbler» Fisher, Microsofti töötaja ja üks Helmi võtmehoidjatest.

15. oktoobril 2015 käivitati projekt, mis tänapäeval tuntud kui Helm. Ainult aasta pärast asutamist liitus Helmi kogukond Kubernetes'ega, töötades samas aktiivselt Helmi 2 kallal. Juuni 2018. aastal liitus Helm CNCF-i areneva (incubating) projektina. Liigume tagasi tänapäeva - ja siin on juba lähenemas Helmi 3 esimene alpha-väljaanne (see väljalaskmine on juba toimunud mai keskpaiku — tõlke märkus).

Selles artiklis räägin ma sellest, kuidas kõik algas, kuidas me oleme jõudnud tänasesse etappi, esitan mõned ainulaadsed omadused, mis on saadaval Helm 3 esimeses alpha-versioonis, ja selgitan, kuidas me plaanime edasi areneda.

Kokkuvõte:

Helmi loomise ajalugu;
soojad hüvastijätud Tilleriga;
chartide hoidlad;
väljalaskehaldus;
muudatused chartide sõltuvustes;
raamatukogu chartid;
Mis edasi?

Helmi loomise ajalugu

Sünnihetk

Helm 1 algas kui avatud lähtekoodiga projekt, mille lõi ettevõte Deis. Olime väike idufirma, mis omandati Microsofti poolt 2017. aasta kevadel. Meie teisel avatud lähtekoodiga projektil, millel oli samuti nimi Deis, oli tööriist deisctl, mida kasutati (lisaks muule) Deisi platvormi installimiseks ja haldamiseks Fleet'i klastris.Tollal oli Fleet üks esimesi konteinerite orkestreerimise platvorme.

Kuna 2015. aasta keskpaiku otsustasime suunda muuta ja tõime Deisi (tol ajal Deis Workflow'iks ümber nimetatud) Fleet'ilt Kubernetes'ile. Üks esimesi asju, mida tegime, oli installimistööriista ümbertegemine. deisctlKasutame seda Deis Workflow' installimiseks ja haldamiseks Fleet'i klastris.

Helm 1 loodi tuntud paketihaldurite, nagu Homebrew, apt ja yum eeskujul. Selle peamine ülesanne oli lihtsustada selliseid ülesandeid nagu rakenduste pakkimine ja installimine Kuberneteses. Helm esitati ametlikult 2015. aastal KubeCon konverentsil San Franciscos.

Meie esimene katse Helmiga õnnestus, kuid tõsiste piirangutega. See võttis komplekti Kubernetes'e manifestidest, millele olid lisatud generaatorid sisendina YAML-plokkidena. (front-matter)*, ja laadis tulemused Kubernetesesse.

* Märk. tõlge.: Esimese versiooni Helmiga valiti Kubernetes'e ressursside kirjeldamiseks YAML-süntaks ning konfiguratsioonide kirjutamisel toetati Jinja malle ja Python-skripte. Üksikasjalikumalt selle ja esimese versiooni Helmi struktuuri kohta rääkisime peatükis "Helmi lühiajalugu". selles materjalis.

Näiteks, et asendada väli YAML-failis, tuli manifesti lisada järgmine struktuur:

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

Lahe, et tänapäeval on olemas mallemootorid, ei ole nii?

Mitmeti põhjustel nõudis see varajane Kubernetes'i installija rangelt määratletud manifestifailide nimekirja ja täitis vaid väikest fikseeritud sündmuste jada. Selle kasutamine oli sedavõrd keeruline, et Deis Workflow R&D meeskond pidi oma toote selle platvormile viimise katsetamisel taluma raskusi — siiski olid idee seemned juba külvatud. Meie esimene katse osutus suurepäraseks õpikogemuseks: mõistsime, et oleme tõeliselt pühendunud praktiliste tööriistade loomisele, mis lahendavad meie kasutajate igapäevaseid probleeme.

Kasutades möödunud vigadest saadud kogemust, alustasime Helm 2 arendamist.

Helm 2 loomine

2015. aasta lõpus võtsid meiega ühendust Google'i meeskond. Nad töötasid sarnase tööriista kallal Kubernetes'i jaoks. Deployment Manager Kubernetes'i jaoks oli olemasoleva tööriista port, mida kasutati Google Cloud Platformis. „Kas me ei sooviks,” küsisid nad, „kulutada paar päeva sarnasuste ja erinevuste arutamiseks?”

Jaanuaris 2016 kohtusid Helm'i ja Deployment Manager'i meeskonnad Seattles, et ideeid vahetada. Läbirääkimised lõppesid ambitsioonika plaaniga: ühendada kaks projekti, et luua Helm 2. Koos Deise ja Google'iga, liitusid arendajate meeskonnaga ka poisid SkippBox’ist SkippBox (nüüd osa Bitnami'ist — tõlke märk.), ja me asusime tööle Helm 2 kallal.

Soovisime säilitada Helm'i kasutusmugavust, kuid lisada järgmist:

mallid kohandamiseks;
sisemine haldus meeskondadele;
esmaklassiline chartide hoidla;
stabiilne pakettide formaat allkirjastamise võimalusega;
kindel pühendumus semantilisele versioonihaldamisele ja tagasipöörduvuse säilitamisele versioonide vahel.

Nende eesmärkide saavutamiseks lisati Helm'i ökosüsteemi teine komponent. See siseklastri komponent nimetati Tilleriks ja see haldas Helm chartide paigaldamist ja haldamist.

Alates Helm 2 väljatöötamisest 2016. aastal on Kubernetes saanud mitmeid tõsiseid uuendusi. Kasutusel on juurdepääsukontroll, mis põhineb rollidel (RBAC), mis lõpuks asendas atribuutide põhjal põhineva juurdepääsu kontrolli (ABAC). Esitati uued ressursitüübid (Deployments olid tol ajal endiselt beetaversioonis). Leiutati kohandatud ressursimääratlemised (alguses nimetati neid kolmandate osapoolte ressurssideks ehk TPR-ideks). Ja mis kõige tähtsam — ilmus parimate praktikate kogum.

Kõigi nende muudatuste taustal jätkas Helm usaldusväärselt Kubernetes'i kasutajate teenimist. Pärast kolme aastat ja hulgaliselt uusi täiendusi sai selgeks, et on aeg teha olulisi muudatusi koodibaasis, et Helm saaks jätkuvalt rahuldada areneva ökosüsteemi kasvavaid vajadusi.

Soodne hüvasti Tilleriga

Helm 2 arendamise käigus tutvustasime Tillert osana meie integratsioonist Google'i Deployment Manageriga. Tiller mängis olulist rolli meeskondade jaoks, kes töötasid ühises klusteris: see võimaldas erinevatel infrastruktuuri spetsialistidel suhelda sama vabastamise kogumi kaudu.

Kuna rollipõhine juurdepääsukontroll (RBAC) oli Kubernetes 1.6-s vaikimisi sisse lülitatud, muutus Tilleriga töötamine tootmises keerulisemaks. Suure hulga võimalike turvapoliitikate tõttu otsustasime vaikimisi pakkuda lubavaid konfiguratsioone. See võimaldas algajatel katsetada Helmi ja Kubernetesega, ilma et nad peaksid esmalt süvenema turvalisuse seadistustesse. Kahjuks võis see lubav konfiguratsioon anda kasutajale liiga laia loakogumi, mis talle ei olnud vajalik. DevOps- ja SRE-insenerid pidid õppima täiendavaid käitusmeetmeid, et installida Tiller mitme kasutaja (multi-tenant) klastrisse.

Saades aru, kuidas kogukonna liikmed kasutavad Helmi konkreetsetes olukordades, mõistsime, et Tilleri väljalaskehaldusüsteem ei pea toetuma siseklassifitseeritavale komponendile, et hooldada olekuid või toimida kesksena väljalaskeinfoga. Selle asemel võiksime lihtsalt saada teavet Kubernetes API-serverilt, genereerida klientpoolt chart’i ja salvestada installatsiooni kirje Kubernetesesse.

Peamisi Tilleri ülesandeid oleks saanud täita ka ilma Tilleri, seega oli üks meie esimesi otsuseid Helmi 3 osas Tillerist täielikult loobuda.

Tilleri lahkumisega lihtsus Helm'i turvamudel oli radikaalselt paranenud. Helm 3 toetab nüüd kõiki tänapäevaseid turvameetodeid, autentimist ja volitamist, mis on olemasolevas Kuberneteses. Helmi õigusi määratletakse kasutades kubeconfig faili.Klastri administraatorid saavad piirata kasutajate õigusi mistahes detailitase. Väljalasked jäävad endiselt klastrisse, kogu muu Helmi funktsionaalsus jääb alles.

Chartide repod

Kõrgel tasemel on chartide hoidla koht, kus saab salvestada ja jagada chart-e. Helm'i klient pakib ja saadab chart-e hoidlasse. Lihtsalt öeldes on chartide hoidla primitiivne HTTP server, millel on fail index.yaml ja mõned pakitud chartid.

Kuigi hoidla API-l on teatud eelised, mis vastavad kõige põhivajadustele, on sel ka mitmeid puudusi:

Chartide hoidlad on halvasti ühilduvad enamikuga tootmisvõrkude turvimplementatsioonist. Standardsest API-st autentimise ja autoriseerimise jaoks on tootmisstsenaariumites äärmiselt oluline.
Helm'i tööriistad chartide päritolu jälgimiseks, mida kasutatakse chartide allkirjastamiseks, terviklikkuse kontrollimiseks ja päritolu kindlakstegemiseks, on chartide avaldamise protsessi valikuline osa.
Mitme kasutaja stsenaariumides võib üks ja sama diagramm olla teiste kasutajate poolt laaditud, suurendades seeläbi kaks korda ruumi, mis on vajalik sama sisu salvestamiseks. Selle probleemi lahendamiseks on välja töötatud nutikamad hoidlad, kuid need ei kuulu ametlikku spetsifikatsiooni.
Ühe indeksi faili kasutamine otsimiseks, metandmete salvestamiseks ja diagrammide saamiseks on raskendanud turvaliste mitme kasutaja rakenduste arendamist.

Projekt Docker Distribution (tuntud ka kui Docker Registry v2) on Docker Registry järeltulija ja tegelikult komplekt tööriistu Docker'i piltide pakendamiseks, edastamiseks, ladustamiseks ja tarnimiseks. Paljud suured pilveteenused pakuvad Distribution põhinevaid tooteid. Tänu sellele suurenenud tähelepanule on Distribution projekt kasu saanud aastatepikkustest täiustustest, parimatest turbepraktikatest ja 'laiaulatusliku' testimise kogemusest, muutes selle üheks kõige edukamaks avatud lähtekoodiga kangelaseks.

Aga kas teate, et Distribution projekt loodi igasuguste sisu levitamiseks, mitte ainult konteineripiltide jaoks?

Tänu jõupingutustele Open Container Initiative (või OCI), Helm-chartid võivad olla paigutatud igasse Distributioni näidikusse. Praegu on see protsess veel katsetamisjärgus. Töö sisselogimise ja teiste Helm 3 täisfunktsionaalsuseks vajalike omaduste toetamise osas ei ole veel lõppenud, kuid me oleme väga rõõmsad, et saame õppida OCI ja Distributioni meeskondade aastate jooksul tehtud avastustest. Aitäh nende juhendamise ja toetamiste eest saame aru, mis on kõrge kergendusega teenuste haldamine suurel skaalal.

Helm-chartide reposte tulevaste muudatuste üksikasjalikum kirjeldus on saadaval lingi kaudu.

Väljaande haldamine

Helm 3-s jälgitakse rakenduse olekult klastris paar objekti:

release object — esindab rakenduse eksemplari;
release version secret — esindab rakenduse soovitud olekut kindlal ajal (nt uue versiooni vabastamine).

Kutse helm install loob release object'i ja release version secret'i. Kutsumine helm upgrade nõuab release object'i (mida ta saab muuta) ja loob uue release version secret'i, millel on uued väärtused ja ettevalmistatud manifeste.

Release objekt sisaldab teavet väljaande kohta, kus väljaanne on konkreetne installeerimine nimelise chart'i ja väärtuste jaoks. See objekt kirjeldab pealsetasandi metaandmeid väljaande kohta. Release objekt säilib kogu rakenduse elutsükli jooksul ja omab kõiki release version saladusi, samuti kõiki objekte, mis on otseselt loodud Helm chart'iga.

Release version saladus seob väljaande revisjonide seeriaga (installeerimine, uuendused, tagasivõtmised, kustutamine).

Helm 2-s olid revisjonid rangelt järjestikused. Kutsumine helm install tõi esile v1, sellele järgnev uuendus (upgrade) - v2, ja nii edasi. Release ja release version saladus on kokku pandud üheks objektiks, mida tuntakse kui revision. Revision'id salvestati samas nimede ruumis, kus oli Tiller, mis tähendas, et iga väljaanne oli nimede ruumi seisukohalt "globaalne"; seetõttu sai kasutada ainult ühte nime eksemplari.

Helm 3-s iga versioon on seotud ühe või mitme release version secret’iga. Release objekt kirjeldab alati praegust versiooni, mis on Kuberneteses rakendatud. Iga release version secret kirjeldab ainult ühte versiooni sellest release'ist. Uuendus (upgrade) loob näiteks uue release version secret'i ja seejärel muudab release objekti, et see viitaks sellele uuele versioonile. Tagasivõtmise (rollback) korral saab kasutada varasemaid release version secret'e, et taastada release eelmisse olekusse.

Pärast Tiller'ist loobumist salvestab Helm 3 andmed release kohta ühte nimekirja koos release'iga. Selline muudatus võimaldab installida chart'i sama nimega release'iga teise nimekirja, ja andmed säilitavad end värskenduste/klastri taaskäivituste vahel etcd's. Näiteks saab installida WordPress'i nimekirjas 'foo', seejärel aga nimekirjas 'bar', ning mõlemat release'i saab nimetada 'wordpress'.

Muutused chartide sõltuvustes

Pakendatud chart'id (kaudu helm package) Helm 2-ga kasutamiseks saab paigaldada ka Helm 3, kuid chartide arendamise töövoog on täielikult üle vaadatud, mistõttu tuleb teha mõned muudatused, et jätkata chartide arendamist Helm 3-ga. Eriti on muutunud chartide sõltuvuste haldamise süsteem.

Charti sõltuvuste haldamine on läinud requirements.yaml ja requirements.lock järgnevaga Chart.yaml ja Chart.lock. See tähendab, et chartid, mis kasutasid käsku helm dependency, vajavad mõningast seadistamist, et töötada Helm 3-ga.

Vaatame näidet. Lisame sõltuvuse chartile Helm 2-s ja vaatame, mis muutub Helm 3-le üleminekul.

Helm 2-s requirements.yaml nägi välja järgmine:

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

Helm 3-s peegelduv sama sõltuvus teie Chart.yaml:

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

Chartid laaditakse endiselt ja paigutatakse kausta charts/, seega subchartid (subcharts), mis asuvad kaustas charts/, jätkavad tööd muutumatult.

Esitleme Library Charts

Helm 3 toetab class chart'e, mida nimetatakse raamatukogude chart'ideks (library chart). Selle diagrammi võivad kasutada teised diagrammid, kuid see ei loo iseseisvalt mingeid versioon artefakte. Raamatukogu diagrammide mallid saavad kuulutada ainult elemente. määrata. Teisi sisu lihtsalt ignoreeritakse. See võimaldab kasutajatel taaskasutada ja jagada koodilõike, mida saab kasutada mitmetes diagrammides, vältides seeläbi dubleerimist ja järgides printsiipi DRY.

Raamatukogu diagrammid kuulutatakse jaotises sõltuvused failis Chart.yaml. Nende paigaldamine ja haldamine ei erine teistest diagrammidest.

sõltuvused:
  - nimi: mylib
    versioon: 1.x.x
    hoidla: quay.io

Ootame põnevusega rakendusi, mida see komponent avab diagrammi arendajatele, samuti parimaid praktikaid, mis võivad tekkida raamatukogu diagrammide tõttu.

Mis edasi?

Helm 3.0.0-alpha.1 — alus, millele toetudes alustame uue Helm versiooni loomist. Artiklis kirjeldasin mõningaid huvitavaid võimalusi Helm 3. Paljud neist on endiselt arenduse algstaadiumis ja see on normaalne; alfa-väljaande mõte on proovida ideed, koguda tagasisidet varajastelt kasutajatelt ja kinnitada meie hüpoteese.

Kui alfa-versioon on välja antud (tuletame meelde, et see on juba juhtunud — kt. tõlge), hakkame võtma vastu Helm 3 kogukonna patše. Oluline on luua usaldusväärne alus, mis võimaldab arendada ja vastu võtta uusi funktsioone, samas kui kasutajad saavad tunda end kaasatuna protsessi, avades piletid ja esitades parandusi.

Artiklis pidasin silmas mitmeid olulisi täiustusi, mis ilmuvad Helm 3-s, kuid seda loetelu ei saa kindlasti pidada ammendavaks. Helm 3 täieulatuslik plaan sisaldab selliseid uuendusi nagu paremad värskendamise strateegiad, sügavam integreerimine OCI registritega ja JSON-skeemide kasutamine chartide väärtuste valideerimiseks. Plaanime samuti puhastada koodibaasi ja värskendada neid osi, mis on viimase kolme aasta jooksul tähelepanuta jäänud.

Kui arvate, et oleme midagi olulist unustanud, oleks meil hea meel kuulda teie mõtteid!

Liituge aruteluga meie Slack kanalites:

#helm-users küsimuste ja lihtsa suhtlemise jaoks kogukonnaga;
#helm-dev pull requestide, koodi ja vigade arutamiseks.

Saate osaleda ka meie iganädalastes Public Developer Calls neljapäeviti kell 19:30 MSK. Kohtumised keskenduvad võtmeprogrammejate ja kogukonna töötavate ülesannete arutamisele, samuti nädala aruteluteemadele. Igaüks on tere tulnud liituma ja kohtumisel osalema. Link on saadaval Slacki kanalites. #helm-dev.