🥇Sissejuhatus Helm 3

Märge. tõlge: Selle aasta 16. mai tähistab olulist verstaposti Kubernetese paketihalduri - Helmi arendamisel. Sel päeval esitleti projekti tulevase suurversiooni - 3.0 - esimest alfaväljalaset. Selle vabastamine toob Helmile kaasa olulisi ja kauaoodatud muudatusi, millele paljud Kubernetese kogukonnas suured lootused on. Oleme ise üks neist, kuna kasutame Helmi aktiivselt rakenduste juurutamiseks: oleme selle integreerinud oma CI/CD juurutamise tööriista. werf ja aeg-ajalt anname oma panuse ülesvoolu arengusse. See tõlge ühendab Helmi ametliku ajaveebi 7 märget, mis on pühendatud Helm 3 esimesele alfaväljaandele ja räägivad projekti ajaloost ja Helm 3 põhifunktsioonidest. Nende autor on Microsofti töötaja Matt “bacongobbler” Fisher. ja Helmi üks peamisi hooldajaid.

15. oktoobril 2015 sündis praegu Helmi nime all tuntud projekt. Vaid aasta pärast asutamist liitus Helmi kogukond Kubernetesega, töötades samal ajal aktiivselt Helm 2 kallal. 2018. aasta juunis sai Helm liitus CNCF-iga areneva (inkubeeriva) projektina. Kiirelt olevikku ja uue Helm 3 esimene alfaväljalase on teel. (see väljaanne on juba toimunud mai keskel - u. tõlge.).

Selles tükis räägin sellest, millest see kõik alguse sai, kuidas me jõudsime praeguseni, tutvustan mõningaid unikaalseid funktsioone, mis on saadaval Helm 3 esimeses alfaväljaandes, ja selgitan, kuidas kavatseme edasi liikuda.

Kokkuvõte:

Helmi loomise ajalugu;
hell hüvastijätt Tilleriga;
diagrammihoidlad;
vabastamise juhtimine;
muutused diagrammi sõltuvustes;
raamatukogu graafikud;
mis järgmiseks?

Helmi ajalugu

Sündi

Helm 1 sai alguse Deisi loodud avatud lähtekoodiga projektist. Olime väike startup imendunud Microsoft kevadel 2017. Meie teisel avatud lähtekoodiga projektil, mille nimi oli ka Deis, oli tööriist deisctl, mida kasutati (muu hulgas) Deisi platvormi paigaldamiseks ja käitamiseks Laevastiku klaster. Sel ajal oli Fleet üks esimesi konteinerite orkestreerimisplatvorme.

2015. aasta keskel otsustasime kurssi muuta ja kolisime Deisi (tol ajal ümbernimetatud Deis Workflow) Fleetist Kubernetesesse. Üks esimesi, mida muudeti, oli installitööriist. deisctl. Kasutasime seda Deis Workflow installimiseks ja haldamiseks Fleet-klastris.

Helm 1 loodi kuulsate paketihaldurite, nagu Homebrew, apt ja yum, näo järgi. Selle peamine eesmärk oli lihtsustada ülesandeid, nagu näiteks rakenduste pakkimine ja installimine Kubernetesesse. Helmi tutvustati ametlikult 2015. aastal KubeConi konverentsil San Franciscos.

Meie esimene katse Helmiga toimis, kuid see ei olnud tõsiste piiranguteta. Ta võttis sissejuhatavateks YAML-plokkideks generaatoritega maitsestatud Kubernetese manifestide komplekti (eesmine asi)* ja laadis tulemused Kubernetesesse.

* Märge. tõlge: Helmi esimesest versioonist valiti Kubernetese ressursside kirjeldamiseks YAML-i süntaks ning konfiguratsioonide kirjutamisel toetati Jinja malle ja Pythoni skripte. Sellest ja Helmi esimese versiooni ülesehitusest üldiselt kirjutasime lähemalt peatükis “Helmi lühiajalugu” seda materjali.

Näiteks YAML-failis välja asendamiseks tuli manifestile lisada järgmine konstruktsioon:

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

See on suurepärane, et mallimootorid on tänapäeval olemas, kas pole?

Paljudel põhjustel nõudis see varajane Kubernetese installija manifestifailide kõvakodeeritud loendit ja käivitas ainult väikese fikseeritud sündmuste jada. Seda oli nii raske kasutada, et Deis Workflow R&D meeskonnal oli raskusi, kui nad üritasid oma toodet sellele platvormile üle kanda – idee seeme oli aga juba külvatud. Meie esimene katse oli suurepärane õppimisvõimalus: mõistsime, et oleme tõeliselt kirglikud luua pragmaatilisi tööriistu, mis lahendavad meie kasutajate igapäevaseid probleeme.

Varasemate vigade kogemuse põhjal alustasime Helm 2 arendamist.

Helmi valmistamine 2

2015. aasta lõpus võttis Google'i tiim meiega ühendust. Nad töötasid Kubernetese jaoks sarnase tööriista kallal. Kubernetese juurutushaldur oli olemasoleva tööriista port, mida kasutati Google Cloud Platformi jaoks. Nad küsisid: "Kas me tahaksime veeta paar päeva sarnasuste ja erinevuste üle arutlemiseks?"

2016. aasta jaanuaris kohtusid tüürimeeskonna ja juurutusjuhi meeskonnad Seattle'is, et mõtteid vahetada. Läbirääkimised lõppesid ambitsioonika plaaniga: ühendada mõlemad projektid, et luua Helm 2. Koos Deisi ja Google'iga löövad tüübid SkippBox (nüüd Bitnami osa – umbes tõlge)ja alustasime tööd Helm 2 kallal.

Tahtsime säilitada Helmi kasutusmugavuse, kuid lisage järgmine:

diagrammimallid kohandamiseks;
klastrisisene juhtimine meeskondadele;
maailmatasemel graafikute hoidla;
stabiilne paketivorming koos allkirjavalikuga;
tugev pühendumus semantilisele versioonile ja versioonide tagasiühilduvuse säilitamisele.

Nende eesmärkide saavutamiseks on Helmi ökosüsteemi lisatud teine element. Selle klastrisisese komponendi nimi oli Tiller ja see vastutas Helmi diagrammide installimise ja nende haldamise eest.

Alates Helm 2 ilmumisest 2016. aastal on Kubernetes lisanud mitmeid olulisi uuendusi. Lisatud rollipõhine juurdepääsu kontroll (RBAC), mis lõpuks asendas atribuudipõhise juurdepääsu juhtimise (ABAC). Kasutusele võeti uued ressursitüübid (juurutamine oli sel ajal veel beetaversioonis). Mõeldi välja kohandatud ressursside määratlused (algselt nimega Third Party Resources või TPR-id). Ja mis kõige tähtsam, on välja kujunenud parimate tavade kogum.

Kõigi nende muudatuste keskel jätkas Helm Kubernetese kasutajate ustavat teenindamist. Pärast kolme aastat ja paljusid uusi täiendusi oli selge, et on aeg teha koodibaasi olulisi muudatusi tagamaks, et Helm suudab jätkuvalt vastata areneva ökosüsteemi kasvavatele vajadustele.

Õrn hüvastijätt Tilleriga

Helm 2 arendamise käigus tutvustasime Tilleri osana oma integratsioonist Google'i juurutushalduriga. Tiller mängis olulist rolli ühises klastris töötavate meeskondade jaoks: see võimaldas erinevatel infrastruktuuri haldavatel spetsialistidel suhelda samade väljaannetega.

Kuna rollipõhine juurdepääsukontroll (RBAC) oli Kubernetes 1.6-s vaikimisi lubatud, muutus Tilleriga töötamine tootmises keerulisemaks. Võimalike turvapoliitikate arvukuse tõttu on meie seisukoht olnud pakkuda vaikimisi lubavat konfiguratsiooni. See võimaldas algajatel katsetada Helmi ja Kubernetesega, ilma et oleks pidanud esmalt turvaseadetesse sukelduma. Kahjuks võib see lubade konfiguratsioon anda kasutajale liiga suure hulga õigusi, mida ta ei vajanud. DevOpsi ja SRE insenerid pidid Tilleri mitme rentniku klastris installimisel õppima täiendavaid toiminguid.

Olles õppinud, kuidas kogukond Helmi konkreetsetes olukordades kasutab, mõistsime, et Tilleri väljalaskehaldussüsteem ei pea toetuma klastrisisesele komponendile, et säilitada olekut ega toimida väljalasketeabe keskse jaoturina. Selle asemel võiksime lihtsalt saada teavet Kubernetes API serverist, genereerida kliendi poolel diagrammi ja salvestada Kubernetesesse installimise kirje.

Tilleri põhieesmärk oleks võinud olla saavutatud ka ilma Tillerita, nii et üks meie esimesi otsuseid Helm 3 osas oli Tillerist täielikult loobuda.

Tilleri lahkumisega on Helmi turvamudel radikaalselt lihtsustatud. Helm 3 toetab nüüd kõiki praeguse Kubernetese kaasaegseid turbe-, identiteedi- ja autoriseerimismeetodeid. Helmi load määratakse kasutades kubeconfig fail. Klastrite administraatorid saavad piirata kasutajaõigusi mis tahes detailsuse tasemeni. Väljalasked salvestatakse endiselt klastris ja ülejäänud Helmi funktsioonid jäävad puutumata.

Diagrammihoidlad

Kõrgel tasemel on diagrammihoidla koht, kus saab diagramme salvestada ja jagada. Helmi klient pakendab ja saadab diagrammid hoidlasse. Lihtsamalt öeldes on diagrammihoidla primitiivne HTTP-server, millel on fail index.yaml ja mõned pakendatud diagrammid.

Kuigi enamikule põhilistele salvestusnõuetele vastaval diagrammihoidla API-l on mõned eelised, on sellel ka mõned puudused.

Diagrammihoidlad ei ühildu enamiku tootmiskeskkonnas nõutavate turberakendustega. Standardse API olemasolu autentimiseks ja autoriseerimiseks on tootmisstsenaariumide puhul äärmiselt oluline.
Helmi diagrammi päritolu tööriistad, mida kasutatakse diagrammi allkirjastamiseks, terviklikkuse ja päritolu kontrollimiseks, on diagrammi avaldamisprotsessi valikuline osa.
Mitme kasutajaga stsenaariumide korral saab sama diagrammi üles laadida teine kasutaja, mis kahekordistab sama sisu salvestamiseks vajalikku ruumi. Selle probleemi lahendamiseks on välja töötatud nutikamad hoidlad, kuid need ei kuulu ametliku spetsifikatsiooni alla.
Ühe registrifaili kasutamine otsimiseks, metaandmete salvestamiseks ja diagrammide toomiseks on muutnud turvalise mitme kasutajaga rakenduste väljatöötamise keeruliseks.

Projekt Dockeri levitamine (tuntud ka kui Docker Registry v2) on Dockeri registri järglane ja toimib sisuliselt Dockeri piltide pakendamise, tarnimise, salvestamise ja kohaletoimetamise tööriistade komplektina. Paljud suured pilveteenused pakuvad levitamispõhiseid tooteid. Tänu sellele suurenenud tähelepanule on levitamisprojekt saanud kasu aastatepikkustest täiustustest, turvalisuse parimatest tavadest ja välikatsetest, mis on teinud sellest avatud lähtekoodiga maailma ühe edukaima laulmata kangelase.

Kuid kas teadsite, et levitamisprojekt oli mõeldud igasuguse sisu levitamiseks, mitte ainult konteinerpiltide levitamiseks?

Tänu pingutustele Avage konteinerite algatus (või OCI), Helm diagrammid saab paigutada mis tahes distributsiooni eksemplari. Praegu on see protsess eksperimentaalne. Sisselogimistugi ja muud täieliku Helm 3 jaoks vajalikud funktsioonid on pooleli, kuid meil on hea meel õppida avastustest, mida OCI ja levitamismeeskonnad on aastate jooksul teinud. Nende juhendamise ja juhendamise kaudu saame teada, mis tunne on pakkuda laiaulatuslikku kõrgetasemelist teenust.

Saadaval on Helmi diagrammihoidlates tulevaste muudatuste üksikasjalikum kirjeldus по ссылке.

Väljalaske haldamine

Helm 3-s jälgitakse rakenduse olekut klastris objektipaari abil:

vabastamise objekt – esindab rakenduse eksemplari;
väljalaske versiooni saladus – tähistab rakenduse soovitud olekut konkreetsel ajahetkel (näiteks uue versiooni väljalaskmine).

Väljakutse helm install loob väljalaskeobjekti ja väljalaske versiooni saladuse. Helistama helm upgrade nõuab väljalaskeobjekti (mida see võib muuta) ja loob uue versiooni versiooni saladuse, mis sisaldab uusi väärtusi ja ettevalmistatud manifesti.

Väljalaskeobjekt sisaldab teavet väljalaske kohta, kus väljalase on nimega diagrammi ja väärtuste konkreetne installimine. See objekt kirjeldab väljalaske ülataseme metaandmeid. Väljalaskeobjekt püsib kogu rakenduse elutsükli jooksul ja on kõigi väljalaskeversiooni saladuste omanik, aga ka kõigi Helmi diagrammiga otse loodud objektide omanik.

Väljalaske versiooni saladus seostab väljalase rea muudatustega (installimine, värskendused, tagasipööramised, kustutamine).

Helm 2-s olid muudatused äärmiselt järjepidevad. Helistama helm install loodud v1, järgnev värskendus (uuendus) - v2 jne. Väljalaske ja väljalaske versiooni saladus on ahendatud üheks objektiks, mida nimetatakse redaktsiooniks. Redaktsioonid salvestati Tilleriga samasse nimeruumi, mis tähendas, et iga väljalase oli nimeruumi poolest "globaalne"; selle tulemusena sai kasutada ainult ühte nime eksemplari.

Helm 3-s on iga väljalase seotud ühe või mitme versiooni versiooni saladusega. Väljalaskeobjekt kirjeldab alati praegust Kubernetesesse juurutatud versiooni. Iga väljalase versiooni saladus kirjeldab ainult selle versiooni ühte versiooni. Täiendus loob näiteks uue versiooni versiooni saladuse ja muudab seejärel väljalaskeobjekti, et osutada sellele uuele versioonile. Tagasipööramise korral saate versiooni eelmisesse olekusse tagasipööramiseks kasutada eelmise versiooni versiooni saladusi.

Pärast Tilleri hülgamist salvestab Helm 3 väljalaskeandmed väljalaskega samas nimeruumis. See muudatus võimaldab installida sama väljalaskenimega diagrammi teise nimeruumi ja andmed salvestatakse klastri värskenduste/taaskäivituste vahel jne. Näiteks saate installida WordPressi nimeruumi "foo" ja seejärel nimeruumi "bar" ning mõlema väljalase saab nimetada "wordpress".

Muudatused diagrammi sõltuvustes

Diagrammid pakitud (kasutades helm package) kasutamiseks koos Helm 2-ga saab installida koos Helm 3-ga, kuid diagrammi arendamise töövoog on täielikult uuendatud, seega tuleb teha mõned muudatused, et jätkata diagrammi arendamist Helm 3-ga. Eelkõige on muutunud diagrammi sõltuvuse haldussüsteem.

Diagrammi sõltuvushaldussüsteem on kolinud requirements.yaml и requirements.lock edasi Chart.yaml и Chart.lock. See tähendab, et käsku kasutanud diagrammid helm dependency, vajavad Helm 3 töötamiseks teatud seadistust.

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

Roolis 2 requirements.yaml nägi välja selline:

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

Helm 3 puhul kajastub sama sõltuvus ka teie puhul Chart.yaml:

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

Diagrammid laaditakse endiselt alla ja paigutatakse kataloogi charts/, seega alamdiagrammid (alamdiagrammid), asub kataloogis charts/, jätkab tööd muudatusteta.

Tutvustame raamatukogu diagramme

Helm 3 toetab diagrammide klassi, mida nimetatakse raamatukogu diagrammideks (raamatukogu tabel). Seda diagrammi kasutavad teised diagrammid, kuid see ei loo üksi väljalaskeartefakte. Teegi diagrammimallid saavad deklareerida ainult elemente define. Muu sisu lihtsalt ignoreeritakse. See võimaldab kasutajatel uuesti kasutada ja jagada koodilõike, mida saab kasutada mitmes diagrammis, vältides sellega dubleerimist ja järgides põhimõtet. DRY.

Jaotises on deklareeritud raamatukogu diagrammid dependencies failis Chart.yaml. Nende installimine ja haldamine ei erine teistest diagrammidest.

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

Oleme põnevil, milliste kasutusjuhtudega see komponent diagrammiarendajatele avab, ning ka parimate tavade üle, mis teegidiagrammidest ilmnevad.

Mis edasi?

Helm 3.0.0-alpha.1 on aluseks, millele hakkame ehitama Helmi uut versiooni. Artiklis kirjeldasin mõningaid Helm 3 huvitavaid omadusi. Paljud neist on alles arengu algstaadiumis ja see on normaalne; Alfaväljaande mõte on idee testimine, varasemate kasutajate tagasiside kogumine ja meie eelduste kinnitamine.

Niipea, kui alfaversioon välja tuleb (pidage meeles, et see on juba juhtunud - u. tõlge.), hakkame kogukonnalt Helm 3 plaastreid vastu võtma. Peate looma tugeva aluse, mis võimaldab uute funktsionaalsuste väljatöötamist ja kasutuselevõttu ning kasutajad tunnevad end protsessis kaasatuna, avades pileteid ja tehes parandusi.

Olen püüdnud esile tuua mõningaid Helm 3 peamisi täiustusi, kuid see nimekiri pole kaugeltki ammendav. Helm 3 täielik tegevuskava sisaldab selliseid funktsioone nagu täiustatud värskendusstrateegiad, sügavam integratsioon OCI registritega ja JSON-skeemide kasutamine diagrammi väärtuste kinnitamiseks. Samuti plaanime puhastada koodibaasi ja värskendada selle osi, mis on viimased kolm aastat tähelepanuta jäetud.

Kui tunned, et oleme millestki ilma jäänud, kuulame hea meelega sinu mõtteid!

Liituge meie aruteluga Lõdvad kanalid:

#helm-users küsimuste ja lihtsa suhtluse eest kogukonnaga;
#helm-dev tõmbetaotluste, koodi ja vigade arutamiseks.

Samuti saate vestelda meie iganädalaste avalike arendajakõnedega neljapäeviti kell 19 MSK. Koosolekud on pühendatud probleemide arutamisele, mille kallal võtmearendajad ja kogukond tegelevad, ning nädala aruteluteemasid. Kõik võivad koosolekuga liituda ja sellest osa võtta. Link saadaval Slacki kanalis #helm-dev.

PS tõlkijalt

Loe ka meie blogist:

Allikas: www.habr.com

Tutvustame Helm 3