Tutvumine Helm 3-ga

Märkus tõlke kohta.: 16. mai sel aastal oli oluline verstapost Kubernetes’i paketihalduri - Helm arenduses. Sel päeval esitati projekti tulevase suure versiooni - 3.0 esimene alfa-väljaanne. Selle saabumine toob Helmi märkimisväärseid ja kauaoodatud muudatusi, millele paljud Kubernetes’i kogukonnas loodavad. Ka meie kuulume nende hulka, kuna kasutame Helmi aktiivselt rakenduste seadistamiseks: oleme selle integreerinud oma CI/CD rakendustesse. werf ja vahel teeme oma panuse upstreami arendamisse. See tõlge koondab 7 märki Helmi ametlikust blogist, mis seondub Helmi 3.0 esimese alfa-väljaande esitamisega ning räägib projekti ajaloost ja Helmi 3.0 põhifunktsioonidest. Nende autor on Matt «bacongobbler» Fisher, Microsofti töötaja ja üks Helmi peamistest hooldajatest.

15. oktoobril 2015 sündis projekt, mis nüüd on tuntud kui Helm. Ainult aasta pärast asutamist liitus Helmi kogukond Kubernetes’ega, samal ajal töötades aktiivselt Helmi 2 kallal. Juunis 2018 liitus Helm CNCF-iga. kui arenev projekt. Liigume tänapäeva - ja siin on juba tulemas Helmi 3 esimene alfa-väljaanne. (see väljalase toimus juba mai keskpaiku - tõlkija märkus.) Selles materjalis tutvustan, kuidas kõik algas, kuidas me praegusesse etappi jõudsime, tutvustan mõningaid ainulaadseid omadusi, mis on saadaval Helmi 3 esimeses alfa-väljaandes, ning selgitan, kuidas me plaanime edasi liikuda. Helmi loomise ajalugu;.

kala hüvastijätmine Tiller’iga;

Kokkuvõte:

• chartide registrid;
• väljaannete haldamine;
• chartide sõltuvused;
• library charts;
• Helmi loomise ajalugu
• Helm 1 alustas kui avatud koodiga projekt, mille lõi Deis. Olime väike idufirma,
• mis edasi?

mis omandati

Sünnipäev

Microsofti poolt 2017. aasta kevadel. Meie teisel avatud koodiga projektil, mis samuti kandis nime Deis, oli tööriist deisctl , mida kasutati (lisaks teistele) Deis platvormi seadistamiseks ja haldamiseks Fleet klastris.Sel ajal oli Fleet üks esimesi konteinerite orkestreerimise platvorme. 2015. aasta keskel otsustasime kurssi muuta ja viisime Deisi (toona nimetatud Deis Workflow) Fleetilt Kubernetes’ile. Üks esimesi ülesandeid oli seadistustööriista uuendamine.Me kasutasime seda Deis Workflow’i seadistamiseks ja haldamiseks Fleet klastris.

. Fleet klastris..

Helm 1 loodi tuntud pakihaldurite, nagu Homebrew, apt ja yum, eeskujul. Selle peamine eesmärk oli lihtsustada selliseid ülesandeid nagu rakenduste pakkimine ja installimine Kuberneteses. Helm esitlemine toimus ametlikult 2015. aastal KubeCon konverentsil San Franciscos.

Meie esimene katse Helmiga läks korda, kuid tõsiste piiranguteta ei saanud siiski läbi. See võttis komplekti Kubernetes manifestidest, millele generaatoreid oli lisatud sisend YAML-plokkidena. (front-matter)*, ja laadis tulemused Kubernetesesse.

* Märkus tõlke kohta.: Helm esimese versiooni jaoks valiti Kubernetes ressursside kirjeldamiseks YAML süntaks ning konfiguratsioonide kirjutamisel toetas see Jinja malle ja Python-skripte. Selle kohta ja Helm esimese versiooni ülesehitusest rääkisime peatükis „Helmi lühiajalugu“ selles materjalis..

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

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

Väga tore, et täna on olemas malle tootjad, kas pole?

Paljuski põhjustel nõudis see varajane Kubernetes'i paigaldaja rangelt määratletud nimekirja manifest-failidest ja täitis ainult väikest fikseeritud sündmuste jada. Selle kasutamine oli nii keeruline, et Deis Workflow R&D meeskonnal oli raskusi, kui nad püüdsid oma toodet sellele platvormile üle viia; siiski olid idee seemned juba külvatud. Meie esimene katse osutus suurepäraseks õpikogemuseks: saime aru, et oleme tõeliselt pühendunud praktiliste tööriistade loomisele, mis lahendavad meie kasutajate igapäevaseid probleeme.

Kogemustest, mille kandsime varasemate vigade põhjal, asusime Helm 2 arendama.

Helm 2 loomine

2015. aasta lõpuks võttis meiega ühendust Google'i meeskond. Nad töötasid sarnase tööriista kallal Kubernetesesse. Kubernetes Deployment Manager oli olemasoleva tööriista port, mida kasutati Google Cloud Platformil. „Kas me ei tahaks,” küsisid nad, „veeta paar päeva sarnasuste ja erinevuste arutamiseks?”

2016. aasta jaanuaris kohtusid Helm ja Deployment Manageri meeskonnad Seattle'is, et ideid vahetada. Läbirääkimised lõppesid ambitsioonika plaaniga: ühendada mõlemad projektid, et luua Helm 2. Koos Deis'i ja Google'iga liitus arendajate meeskonnaga veel poisid SkippBox (mis on nüüd osa Bitnami'st — toimetaja märkus), ja asusime tööle Helm 2 kallal.

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

• chartide mallid kohandamiseks;
• klusteresisene haldamine meeskondade jaoks;
• esmaklassiline chartide hoidla;
• stabiilne paketi formaat koos allkirjastamise võimalusega;
• kindel pühendumus semantilisele versioonihaldamisele ja tagasipöörduva ühilduvuse säilitamisele versioonide vahel.

Nende eesmärkide saavutamiseks lisati Helm'i ökosüsteemi teine element. See klusteresisene komponent nimetati Tilleriks ja see vastutas Helm chartide installimise ja haldamise eest.

Alates Helm 2 väljalaskmisest 2016. aastal on Kubernetes saanud mitmeid olulisi uuendusi. Tuli rollide põhine juurdepääsu haldamine (RBAC), mis lõpuks asendas atribuutide põhise juurdepääsu juhtimise (ABAC). Uued ressursitüübid (Deployments olid sel ajal endiselt beetaversioonis). Leiutati Custom Resource Definitions (alguses tuntud kui Third Party Resources või TPR-d). Ja kõige olulisem - ilmusid parimad praktikud.

Kuna kõik need muudatused toimusid, jätkas Helm Kubernetes'i kasutajatele ustav teenimine. Pärast kolme aastat ja palju uusi lisandeid sai selgeks, et on aeg teha olulisi muudatusi koodibaasis, et Helm saaks jätkuvalt rahuldada areneva ökosüsteemi kasvavaid vajadusi.

Hellitus hüvastijätt Tillersist

Helm 2 arendamise käigus tutvustasime Tillerit kui osa meie integreerimisest Google'i Deployment Manager'iga. Tiller mängis olulist rolli meeskondadele, kes töötasid ühise klastriga: see võimaldas erinevatel infrastruktuuri spetsialistidel suhelda sama väljundite kogumiga.

Kuna rollipõhine juurdepääsukontroll (RBAC) on Kubernetes 1.6 vaikimisi lubatud, muutus Tilleriga töö tegemine tootmisrežiimis keerulisemaks. Suure arvu võimalike turvapoliitikate tõttu oli meie seisukoht pakkuda vaikimisi lubavat konfiguratsiooni. See võimaldas algajatel katsetada Helmiga ja Kubernetesega ilma et oleks vaja kõigepealt turvaseadetesse süveneda. Kahjuks võis see lubav konfiguratsioon anda kasutajale liiga laiad õigused, mida tal ei olnud vaja. DevOps ja SRE insenerid pidid õppima täiendavaid tegevusi, paigaldades Tilleri mitme kasutaja (multi-tenant) klastrisse.

Saades teada, kuidas kogukonna liikmed kasutavad Helmi konkreetses olukorras, mõistsime, et Tilleri väljalaskesüsteem ei pea toetuma klastrisisesele komponendile olekute haldamiseks või toimima keskse sõlmena väljalaskeinfo osas. Selle asemel võiksime saada teavet Kubernetes API serverilt, genereerida charti kliendi poolel ja salvestada installatsiooni kirje Kubernetesesse.

Tilleri põhifunktsiooni oli võimalik täita ka ilma Tillerita, seega oli meie esimene otsus Helm 3 kohta Tilleri täielik kõrvaldamine.

Tilleri lahkumisega muutus Helmi turvamudel radikaalselt lihtsamaks. Helm 3 toetab nüüd kõiki kaasaegseid turbe, autentimise ja autoriseerimise viise, mis on olemas tänapäeva Kuberneteses. Helmi õigused määratakse kubeconfig faili. Klastri administraatorid saavad kasutajate õigusi piirata mis tahes detailitasemel. Väljalasked salvestatakse endiselt klastrisse, samas kui Helmi muu funktsionaalsus säilib.

Charti allikad

Üldiselt on chartide lähtekohaks koht, kus on võimalik charte hoida ja jagada. Helm klient pakib ja saadab chardid repositorysse. Lihtsustatult öeldes on chartide repository primitiivne HTTP-server, millel on index.yaml fail ja mõned pakendatud chardid.

Kuigi chartide repository API-l on mõned eelised, et vastata kõige põhilisematele ladustamise nõuetele, on sellel ka mitmeid puudusi:

• Chartide hoidmine on halvasti ühilduv enamikuga turvalisuse rakendustest, mis on vajalikud tootmisümbruses. Standardse API olemasolu autentimiseks ja autoriseerimiseks on tootmisstsenaariumites äärmiselt oluline.
• Helm'i tööriistad, mis jälgivad chartide päritolu ja neid kasutatakse allkirjastamiseks, terviklikkuse kontrollimiseks ning chartide päritolu määramiseks, on publikatsiooniprotsessi valikuline osa.
• Mitme kasutaja stsenaariumites võib sama chart olla üles laaditud teise kasutaja poolt, kahekordistades selle sisu salvestamiseks vajaliku ruumi. Selle probleemi lahendamiseks on välja töötatud nutikamad hoidlad, kuid need ei ole ametlikus spetsifikatsioonis osa.
• Ühe indeksi faili kasutamine chartide otsimiseks, metadate salvestamiseks ja chartide hankimiseks on keerukust suurendanud ohutute mitme kasutaja rakenduste väljatöötamisel.

Projekt Docker Distribution (tuntud ka kui Docker Registry v2) on Docker Registry järglane ja tegelikult on see komplekt tööriistu Docker-i piltide pakkimiseks, saatmiseks, salvestamiseks ja tarnimiseks. Paljud suuremad pilveteenused pakuvad Distributioni põhjal põhinevaid tooteid. Suure tähelepanu tõttu on Distribution projekt kasu saanud pikaleveninud täiustustest, parimatest turvapraktikatest ja katsetamisest looduslikes tingimustes, muutes selle üheks edukaimaks, kuid vähe tuntud kangelaseks avatud allika maailmas.

Aga kas sa tead, et Distributioni projekt on loodud mis tahes vormi sisu levitamiseks, mitte ainult konteineripiltide jaoks?

Tänu pingutustele Open Container Initiative (või OCI), saavad Helm chartid olla paigutatud igasse Distributioni instantsi. Praegu on see protsess eksperimentaalne. Tööd sisselogimise ja teiste funktsioonide toetamiseks, mis on vajalikud täielikuks Helm 3 kasutamiseks, pole veel lõpetatud, kuid oleme väga põnevil õppimisvõimaluse üle, mida OCI ja Distributioni meeskonnad on aastate jooksul avastanud. Ja tänu nende juhendamisele ja suunamisele saame aru, mis on kõrge kättesaadavusega teenuse haldamine suures ulatuses.

Rohkem teavet mõnede eelseisvate muudatuste kohta Helm chartide hoidlates on saadaval linki pidi.

Väljaandmise haldamine

Helm 3-s jälgitakse rakenduse seisundit klastris paari objekti abil:

• release object — esindab rakenduse eksemplari;
• release version secret — esindab soovitud rakenduse olekut konkreetsel ajahetkel (näiteks uue versiooni väljaandmine).

Kutsumine helm install loodab release objekti ja release version secret. Kutsumine helm upgrade nõuab release objekti olemasolu (mida ta võib muuta) ja loob uue release version secret, mis sisaldab uusi väärtusi ja ettevalmistatud manifesti.

Release object sisaldab teavet väljaande kohta, kus väljaanne on nimetatud charti ja väärtuste konkreetne paigaldus. See objekt kirjeldab väljaande ülalt alla metaandmeid. Release object säilib kogu rakenduse eluea ning on kõigi release version secret’ide ja kõikide objektide omanikud, mis on otseselt loodud Helm-chartiga.

Release version secret seob väljaande revision sarjaga (paigaldamine, uuendused, tagasipöördumised, kustutamine).

Helm 2-s olid revisjonid rangelt järjestikused. Kutsumine helm install loonud v1, järgneva uuendamise (upgrade) — v2 ja nii edasi. Release ja release version secret olid kokku pandud üheks objektiks, mida tuntakse kui revision. Revision'id salvestati samasse nimekavasse, mis Tiller, mis tähendas, et iga väljaanne oli „globaalne“ nimekava osas; seetõttu oli võimalik kasutada ainult ühte eksemplari nimega.

Helm 3-s on iga väljaanne seotud ühe või mitme release version secret’iga. Release object kirjeldab alati praegust väljaannet, mis on Kuberneteses juurutatud. Iga release version secret kirjeldab ainult ühe versiooni sellest väljaandest. Uuendamine (upgrade) loob näiteks uue release version secret'i ja seejärel muudab release object'it, et see viitaks sellele uuele versioonile. Tagasipöördumise (rollback) korral on võimalik kasutada eelnevaid release version secret'e, et tagasi minna väljaande eelmisse olekusse.

Pärast Tillerist loobumist salvestab Helm 3 väljaande andmed sama nimekava alla. Selline muudatus võimaldab installida chart'i sama väljaande nimega teise nimekavasse, ning andmed säilivad värskenduste/klastri taaskäivituste vahel etcd's. Näiteks võib WordPressi installida nimekavasse „foo”, ning seejärel teise nimekavasse „bar”, ja mõlemad väljaanded võivad nimetuda „wordpress”.

Muutused chartide sõltuvustes

Pakitud chart'id (kasutades helm package) Helm 2 kasutamiseks saab installeerida Helm 3, kuid chartide arendustööd on täielikult üle vaadatud, seetõttu tuleb mõned muudatused teha, et jätkata chartide arendamist heli 3-ga. Eelkõige on muutunud chartide sõltuvuste haldamise süsteem.

Chartide sõltuvuste haldamise süsteem on üle läinud requirements.yaml ja requirements.lock . Tundub, et Chart.yaml ja Chart.lock. See tähendab, et helm 2-s kasutatud chartide korral helm dependency, on vajalik teatud seadistamine, 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 requirements.yaml nägi välja järgmiselt:

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

Helm 3-s peegeldub 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 ning paigutatakse katalooge charts/, seega subchartid (subcharts), mis asuvad kaustas charts/, jätkavad töötamist muutumatuna.

Tutvustame Library Charts

Helm 3 toetab chartide klassi, mida nimetatakse raamatukogude chartideks (library chart). See chart kasutatakse teiste chartide poolt, kuid ei loo iseseisvalt ühtegi versiooni artefakti. Library chartide malli võib deklareerida ainult elemendid. Muud sisu ignoreeritakse. See võimaldab kasutajatel taaskasutada ja jagada koodijuppe, mida saab kasutada mitmetes chartides, vältides seeläbi dubleerimist ja järgides põhimõtet define. Teine sisu jäetakse lihtsalt kõrvale. See võimaldab kasutajatel taaskasutada ja jagada koodifragmente, mis võivad olla kasutuses mitmes chartis, vältides seega dubleerimist ja järgides põhimõtet DRY.

Raamatukogu chartide deklareerimine toimub jaotis sõltuvused failis Chart.yaml. Nende installimine ja haldamine ei erine teistest chartidest.

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

Ootame põnevusega rakendusvõimalusi, mida see komponent arendajatele avab, samuti parimaid praktikaid, mis võivad tuleneda raamatukogude chartidest.

Mis edasi?

Helm 3.0.0-alpha.1 — alus, millega alustame uue Helm versiooni loomist. Artiklis tutvustasin mõned huvitavad võimalused, mis Helm 3-l on. Paljud neist on endiselt varajases arengufaasis ja see on normaalne; alfa versiooni eesmärk on ideed testida, saada esimestelt kasutajatelt tagasisidet ning kinnitada meie oletusi.

Niipea kui alfa versioon on välja antud (tuletame meelde, et see on juba juhtunud — toimetaja märkus), me alustan võtma Helm 3 seoseid kogukonnalt. On oluline luua usaldusväärne alus, mis võimaldab arendada ja võtta kasutusele uusi funktsioone, samas saavad kasutajad olla kaasatud protsessi, avades piletid ja tehes parandusi.

Artiklis püüdsin käsitleda mõningaid olulisi täiustusi, mis ilmuvad Helm 3-s, kuid seda nimekirja ei saa kuidagi pidada ammendavaks. Helm 3 jaoks on kogu plaanis sellised uuendused nagu parandatud värskendamisstrateegiad, sügavam integratsioon OCI registritega ja JSON- skeemide kasutamine chartide väärtuste valideerimiseks. Samuti plaanime koodibaasi puhastada ja uuendada neid osi, mis on viimased kolm aastat tähelepanuta jäänud.

Kui teil on tunne, et oleme midagi tähele pannud, siis oleksime tänulikud teie mõtete kuulmise eest!

Liituge aruteluga meie Slack-kanalites:

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

Saate ka suhelda meie iga nädal toimuvatel Public Developer Calls, mis toimuvad neljapäeviti kell 19:30 MSK. Kohtumised on pühendatud arutamisele probleemide üle, millega töötavad võtme arendajad ja kogukond, samuti nädalase arutelu teemadele. Igaühel on võimalus liituda ja osaleda kohtumisel. Lingid on saadaval Slack-kanalis #helm-dev.

P.S. tõlkijalt

Lugege ka meie blogist:

• «Pakettide haldur Kubernetesile — Helm: minevik, olevik, tulevik»;
• «Objektiivne pilk Helm 2-le: „Selline, nagu on...”»;
• «Praktiline tutvumine Kubernetes'e paketihalduriga — Helm»;
• «Kubernetesi nipid ja trikid: tööriistade tõlkimine klastris Helm 2 halduse alla»;
• «Praktika dappiga. Osa 2. Docker-piltide juurutamine Kubernetesesse Helm abil».

Allikas: habr.com