🥇Helm 3:n esittely

Huomautus. käännös: 16. toukokuuta tänä vuonna on merkittävä virstanpylväs Kubernetes - Helmin pakettihallinnan kehittämisessä. Tänä päivänä esiteltiin projektin tulevan suuren version - 3.0 - ensimmäinen alfajulkaisu. Sen julkaisu tuo Helmiin merkittäviä ja kauan odotettuja muutoksia, joihin monilla Kubernetes-yhteisössä on suuria toiveita. Me itse olemme yksi näistä, koska käytämme Helmia aktiivisesti sovellusten käyttöönotossa: olemme integroineet sen CI/CD:n käyttöönottotyökaluumme. werf ja ajoittain annamme panoksemme alkupään kehittämiseen. Tämä käännös yhdistää seitsemän virallisen Helm-blogin muistiinpanoa, jotka on omistettu Helm 7:n ensimmäiselle alfajulkaisulle ja kertovat projektin historiasta ja Helm 3:n pääominaisuuksista. Niiden kirjoittaja on Matt "bacongobbler" Fisher, Microsoftin työntekijä ja yksi Helmin tärkeimmistä ylläpitäjistä.

15. lokakuuta 2015 projekti, joka tunnetaan nyt nimellä Helm, syntyi. Vain vuosi perustamisensa jälkeen Helm-yhteisö liittyi Kubernetesiin ja työskenteli aktiivisesti Helm 2:n parissa. Kesäkuussa 2018 Helm liittyi CNCF:ään kehittävänä (hautovana) hankkeena. Nopeasti eteenpäin nykyhetkeen, ja uuden Helm 3:n ensimmäinen alfajulkaisu on tulossa. (tämä julkaisu on jo tapahtunut toukokuun puolivälissä - n. käännös.).

Tässä kappaleessa puhun siitä, mistä kaikki alkoi, kuinka pääsimme nykyiseen tilanteeseen, esittelen joitain ainutlaatuisia ominaisuuksia, jotka ovat saatavilla Helm 3:n ensimmäisessä alfajulkaisussa, ja selitän, kuinka aiomme edetä.

yhteenveto:

Helmin luomisen historia;
hellät jäähyväiset Tillerille;
kaaviovarastot;
julkaisun hallinta;
muutokset kaavioiden riippuvuuksissa;
kirjastokaaviot;
mitä seuraavaksi?

Helmin historia

syntymä

Helm 1 aloitti Deisin luomana Open Source -projektina. Olimme pieni startup imeytyy Microsoft keväällä 2017. Toisella avoimen lähdekoodin projektillamme, myös nimeltään Deis, oli työkalu deisctl, jota käytettiin (muun muassa) Deis-alustan asentamiseen ja käyttämiseen Laivastoklusteri. Fleet oli tuolloin yksi ensimmäisistä konttiorkesterialustoista.

Vuoden 2015 puolivälissä päätimme muuttaa kurssia ja siirsimme Deisin (silloin Deis Workflow) Fleetistä Kubernetesiin. Yksi ensimmäisistä uudelleen suunnitelluista oli asennustyökalu. deisctl. Käytimme sitä Deis Workflow:n asentamiseen ja hallintaan Fleet-klusterissa.

Helm 1 luotiin kuuluisien pakettihaltijoiden, kuten Homebrew, apt ja yum, kuvaksi. Sen päätavoitteena oli yksinkertaistaa tehtäviä, kuten pakkaamista ja sovellusten asentamista Kubernetesille. Helm esiteltiin virallisesti vuonna 2015 KubeCon-konferenssissa San Franciscossa.

Ensimmäinen yritys Helmin kanssa toimi, mutta se ei ollut ilman vakavia rajoituksia. Hän otti joukon Kubernetes-luetteloita, jotka oli maustettu generaattoreilla johdanto-YAML-lohkoina (edessä asia)* ja latasi tulokset Kubernetesiin.

* Huomautus. käännös: Helmin ensimmäisestä versiosta lähtien YAML-syntaksi valittiin kuvaamaan Kubernetes-resursseja, ja Jinja-malleja ja Python-skriptejä tuettiin määrityksiä kirjoitettaessa. Kirjoitimme lisää tästä ja Helmin ensimmäisen version rakenteesta yleensä luvussa ”Helmin lyhyt historia” tätä materiaalia.

Esimerkiksi, jos haluat korvata kentän YAML-tiedostossa, sinun oli lisättävä luetteloon seuraava rakenne:

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

On hienoa, että mallimoottoreita on nykyään olemassa, eikö?

Monista syistä tämä varhainen Kubernetes-asennusohjelma vaati kovakoodatun luettelon luettelotiedostoista ja suoritti vain pienen, kiinteän tapahtumasarjan. Sen käyttö oli niin vaikeaa, että Deis Workflow T&K -tiimillä oli vaikeuksia, kun he yrittivät siirtää tuotteensa tälle alustalle – idean siemenet oli kuitenkin jo kylvetty. Ensimmäinen yrityksemme oli loistava oppimismahdollisuus: tajusimme, että olimme todella intohimoisia luomaan käytännöllisiä työkaluja, jotka ratkaisevat käyttäjiemme päivittäisiä ongelmia.

Aiempien virheiden kokemuksen perusteella aloimme kehittää Helm 2:ta.

Ruorin tekeminen 2

Google-tiimi otti meihin yhteyttä vuoden 2015 lopussa. He työskentelivät samanlaisen työkalun parissa Kubernetesille. Deployment Manager for Kubernetes oli portti olemassa olevalle työkalulle, jota käytettiin Google Cloud Platformissa. "Haluaisimmeko", he kysyivät, "käyttävämme muutaman päivän samankaltaisuuksista ja eroista?"

Tammikuussa 2016 Helm- ja Deployment Manager -tiimit tapasivat Seattlessa vaihtamaan ajatuksia. Neuvottelut päättyivät kunnianhimoiseen suunnitelmaan: yhdistää molemmat projektit Helm 2:n luomiseksi. Deisin ja Googlen ohella SkippBox (nyt osa Bitnamia - noin käännös), ja aloimme työskennellä Helm 2:n parissa.

Halusimme säilyttää Helmin helppokäyttöisyyden, mutta lisää seuraava:

kaaviomallit mukauttamiseen;
klusterin sisäinen hallinta ryhmiä varten;
maailmanluokan karttavarasto;
vakaa pakettimuoto allekirjoitusvaihtoehdolla;
vahva sitoutuminen semanttiseen versiointiin ja taaksepäin yhteensopivuuden ylläpitämiseen versioiden välillä.

Näiden tavoitteiden saavuttamiseksi Helmin ekosysteemiin on lisätty toinen elementti. Tämä klusterin sisäinen komponentti oli nimeltään Tiller, ja se vastasi Helm-kaavioiden asentamisesta ja hallinnasta.

Helm 2:n julkaisusta vuonna 2016 lähtien Kubernetes on lisännyt useita merkittäviä innovaatioita. Lisätty roolipohjainen pääsynhallinta (RBAC), joka lopulta korvasi Attribute-Based Access Control (ABAC). Uusia resurssityyppejä otettiin käyttöön (Deployments oli tuolloin vielä beta-vaiheessa). Mukautetut resurssien määritelmät (alun perin nimeltään Third Party Resources tai TPR) keksittiin. Ja mikä tärkeintä, joukko parhaita käytäntöjä on syntynyt.

Kaikkien näiden muutosten keskellä Helm jatkoi Kubernetes-käyttäjien palvelemista uskollisesti. Kolmen vuoden ja monien uusien lisäysten jälkeen oli selvää, että oli aika tehdä merkittäviä muutoksia koodikantaan varmistaakseen, että Helm pystyisi vastaamaan edelleen kehittyvän ekosysteemin kasvaviin tarpeisiin.

Hellät jäähyväiset Tillerille

Helm 2:n kehittämisen aikana esittelimme Tillerin osana integraatiotamme Googlen käyttöönottohallintaan. Tillerillä oli tärkeä rooli yhteisessä klusterissa työskenteleville tiimeille: se antoi infrastruktuuria käyttäville eri asiantuntijoille mahdollisuuden olla vuorovaikutuksessa samojen julkaisujen kanssa.

Koska roolipohjainen pääsynhallinta (RBAC) oli oletuksena käytössä Kubernetes 1.6:ssa, työskentely Tillerin kanssa tuotannossa vaikeutui. Mahdollisten suojauskäytäntöjen suuren määrän vuoksi kantamme on ollut tarjota oletusarvoisesti salliva kokoonpano. Tämä antoi aloittelijoille mahdollisuuden kokeilla Helmiä ja Kubernetesia ilman, että heidän tarvitsisi ensin sukeltaa suojausasetuksiin. Valitettavasti tämä käyttöoikeusmääritys voi antaa käyttäjälle liian laajan valikoiman käyttöoikeuksia, joita hän ei tarvinnut. DevOps- ja SRE-insinöörien oli opittava lisävaiheita, kun Tiller asennettiin usean vuokralaisen klusteriin.

Opimme kuinka yhteisö käytti Helmiä tietyissä tilanteissa, ymmärsimme, että Tillerin julkaisunhallintajärjestelmän ei tarvinnut luottaa klusterin sisäiseen komponenttiin ylläpitääkseen tilaa tai toimiakseen julkaisutietojen keskuskeskuksena. Sen sijaan voisimme yksinkertaisesti vastaanottaa tietoja Kubernetes API -palvelimelta, luoda kaavion asiakaspuolelle ja tallentaa asennuksen tietueen Kubernetesiin.

Tillerin päätavoite olisi voitu saavuttaa ilman Tilleriä, joten yksi ensimmäisistä päätöksistämme Helm 3:n suhteen oli Tillerin hylkääminen kokonaan.

Tillerin poistuttua Helmin turvallisuusmallia on yksinkertaistettu radikaalisti. Helm 3 tukee nyt kaikkia nykyisen Kubernetesin nykyaikaisia suojaus-, identiteetti- ja valtuutusmenetelmiä. Ruoriluvat määritetään käyttämällä kubeconfig-tiedosto. Klusterin järjestelmänvalvojat voivat rajoittaa käyttäjien oikeuksia mille tahansa tarkkuudelle. Julkaisut tallennetaan edelleen klusterin sisällä, ja muut Helmin toiminnot säilyvät ennallaan.

Kaaviovarastot

Korkealla tasolla kaaviovarasto on paikka, jossa kaavioita voidaan tallentaa ja jakaa. Helm-asiakas pakkaa ja lähettää kaaviot arkistoon. Yksinkertaisesti sanottuna kaaviovarasto on primitiivinen HTTP-palvelin, jossa on index.yaml-tiedosto ja joitain pakattuja kaavioita.

Vaikka Charts Repository API:lla on joitain etuja, jotka täyttävät useimmat perustallennusvaatimukset, siinä on myös muutamia haittoja:

Kaaviovarastot eivät ole yhteensopivia useimpien tuotantoympäristössä vaadittavien tietoturvatoteutusten kanssa. Standardinmukaisen API:n käyttö todennusta ja valtuutusta varten on erittäin tärkeää tuotantoskenaarioissa.
Helmin kaavion alkuperätyökalut, joita käytetään allekirjoittamiseen, kaavion eheyden ja alkuperän tarkistamiseen, ovat valinnainen osa kaavion julkaisuprosessia.
Usean käyttäjän skenaarioissa toinen käyttäjä voi ladata saman kaavion, mikä kaksinkertaistaa saman sisällön tallentamiseen tarvittavan tilan määrän. Tämän ongelman ratkaisemiseksi on kehitetty älykkäämpiä tietovarastoja, mutta ne eivät ole osa muodollista määritystä.
Yhden hakemistotiedoston käyttäminen etsimiseen, metatietojen tallentamiseen ja kaavioiden hakemiseen on vaikeuttanut turvallisten usean käyttäjän toteutusten kehittämistä.

Hanke Docker-jakelu (tunnetaan myös nimellä Docker Registry v2) on Docker Registryn seuraaja, ja se toimii lähinnä työkaluna Docker-kuvien pakkaamiseen, toimittamiseen, tallentamiseen ja toimittamiseen. Monet suuret pilvipalvelut tarjoavat jakelupohjaisia tuotteita. Tämän lisääntyneen huomion ansiosta Distribution-projekti on hyötynyt vuosien parannuksista, parhaista tietoturvakäytännöistä ja kenttätestauksista, jotka ovat tehneet siitä yhden avoimen lähdekoodin maailman menestyneimmistä laulamattomista sankareista.

Mutta tiesitkö, että Distribution Project oli suunniteltu jakamaan kaikenlaista sisältöä, ei vain säilökuvia?

Kiitos ponnisteluista Avaa Container Initiative (tai OCI), Helm-kaaviot voidaan sijoittaa mihin tahansa jakeluinstanssiin. Toistaiseksi tämä prosessi on kokeellinen. Kirjautumistuki ja muut täyden Helm 3:n tarvitsemat ominaisuudet ovat työn alla, mutta olemme innoissamme oppiessamme OCI- ja Distribution-tiimien vuosien varrella tekemistä löydöistä. Heidän mentorointinsa ja ohjauksensa avulla opimme, millaista on tarjota erittäin saatavilla olevaa palvelua laajassa mittakaavassa.

Tarkempi kuvaus joistakin tulevista muutoksista Helm-kaavion arkistoihin on saatavilla по ссылке.

Julkaisun hallinta

Helm 3:ssa sovelluksen tilaa seurataan klusterin sisällä objektiparilla:

julkaisuobjekti - edustaa sovellusesiintymää;
julkaisuversion salaisuus - edustaa sovelluksen haluttua tilaa tietyllä hetkellä (esimerkiksi uuden version julkaisu).

puhelu helm install luo julkaisuobjektin ja julkaisuversion salaisuuden. Puhelu helm upgrade vaatii julkaisuobjektin (jota se voi muuttaa) ja luo uuden julkaisuversion salaisuuden, joka sisältää uudet arvot ja valmistetun luettelon.

Release-objekti sisältää tietoja julkaisusta, jossa julkaisu on nimetyn kaavion ja arvojen erityinen asennus. Tämä objekti kuvaa julkaisun ylätason metatietoja. Julkaisuobjekti säilyy koko sovelluksen elinkaaren ajan ja on kaikkien julkaisuversioiden salaisuuksien sekä kaikkien Helm-kaavion suoraan luomien objektien omistaja.

Julkaisuversion salaisuus yhdistää julkaisun sarjaan versioita (asennus, päivitykset, palautukset, poisto).

Helm 2:ssa versiot olivat erittäin johdonmukaisia. Puhelu helm install luotu v1, myöhempi päivitys (päivitys) - v2 ja niin edelleen. Julkaisun ja julkaisuversion salaisuus on tiivistetty yhdeksi objektiksi, joka tunnetaan nimellä versio. Versiot tallennettiin samaan nimiavaruuteen kuin Tiller, mikä tarkoitti, että jokainen julkaisu oli "globaali" nimiavaruuden suhteen; tämän seurauksena vain yhtä nimen esiintymää voitiin käyttää.

Helm 3:ssa jokainen julkaisu liittyy yhteen tai useampaan julkaisuversion salaisuuteen. Julkaisuobjekti kuvaa aina nykyistä Kubernetesin käyttöönotettua julkaisua. Jokainen julkaisuversion salaisuus kuvaa vain yhtä versiota kyseisestä julkaisusta. Päivitys esimerkiksi luo uuden julkaisuversion salaisuuden ja muuttaa sitten julkaisuobjektin osoittamaan uuteen versioon. Jos kyseessä on palautus, voit käyttää edellisen version salaisuuksia palauttaaksesi julkaisun aikaisempaan tilaan.

Kun Tiller on hylätty, Helm 3 tallentaa julkaisutiedot samaan nimiavaruuteen kuin julkaisu. Tämän muutoksen avulla voit asentaa kaavion samalla julkaisunimellä eri nimiavaruuteen, ja tiedot tallennetaan klusteripäivitysten/uudelleenkäynnistysten välillä etcd:ssä. Voit esimerkiksi asentaa WordPressin "foo"-nimiavaruuteen ja sitten "bar"-nimiavaruuteen, ja molemmat julkaisut voidaan nimetä "wordpress".

Muutoksia kaavioiden riippuvuuksiin

Kaaviot pakattu (käyttäen helm package) käytettäväksi Helm 2:n kanssa voidaan asentaa Helm 3:n kanssa, mutta karttakehityksen työnkulku on täysin uusittu, joten joitain muutoksia on tehtävä, jotta kaavioiden kehitystä voidaan jatkaa Helm 3:lla. Erityisesti karttariippuvuuden hallintajärjestelmä on muuttunut.

Kaavion riippuvuuden hallintajärjestelmä on siirtynyt requirements.yaml и requirements.lock päälle Chart.yaml и Chart.lock. Tämä tarkoittaa, että komentoa käyttäneet kaaviot helm dependency, vaativat asennuksen toimiakseen Helm 3:ssa.

Katsotaanpa esimerkkiä. Lisätään riippuvuus Helm 2:n kaavioon ja katsotaan, mikä muuttuu, kun siirrytään Helm 3:een.

Ruorissa 2 requirements.yaml näytti tältä:

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

Helm 3:ssa sama riippuvuus heijastuu myös sinuun Chart.yaml:

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

Kaaviot ladataan edelleen ja sijoitetaan hakemistoon charts/, joten alikaavioita (alakaaviot), makaa luettelossa charts/, jatkaa toimintaansa ilman muutoksia.

Esittelyssä kirjastokaaviot

Helm 3 tukee taulukkoluokkaa, jota kutsutaan kirjastokaavioiksi (kirjastokaavio). Tätä kaaviota käyttävät muut kaaviot, mutta se ei luo yksinään julkaisuartefaktteja. Kirjastokaaviomallit voivat ilmoittaa vain elementtejä define. Muu sisältö jätetään huomiotta. Näin käyttäjät voivat käyttää uudelleen ja jakaa koodinpätkiä, joita voidaan käyttää useissa kaavioissa, jolloin vältetään päällekkäisyys ja säilytetään periaate. DRY.

Kirjastokaaviot on ilmoitettu osiossa dependencies tiedostossa Chart.yaml. Niiden asentaminen ja hallinta ei eroa muista kaavioista.

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

Olemme innoissamme käyttötapauksista, joita tämä komponentti avaa kaavioiden kehittäjille, sekä parhaista käytännöistä, joita kirjastokaavioista voi ilmetä.

Mitä seuraavaksi?

Helm 3.0.0-alpha.1 on perusta, jolle alamme rakentaa uutta Helm-versiota. Artikkelissa kuvailin Helm 3:n mielenkiintoisia ominaisuuksia. Monet niistä ovat vielä kehitysvaiheessa ja tämä on normaalia; Alfajulkaisun tarkoitus on testata ideaa, kerätä palautetta varhaisilta käyttäjiltä ja vahvistaa olettamuksemme.

Heti kun alfaversio julkaistaan (muista, että tämä on jo tapahtunut - noin käännös.), alamme vastaanottaa Helm 3:n korjaustiedostoja yhteisöltä. Sinun on luotava vahva perusta, joka mahdollistaa uusien toimintojen kehittämisen ja käyttöönoton, ja jotta käyttäjät voivat tuntea olevansa mukana prosessissa avaamalla lippuja ja tekemällä korjauksia.

Olen yrittänyt korostaa joitain Helm 3:een tulevia suuria parannuksia, mutta tämä luettelo ei ole mitenkään tyhjentävä. Helm 3:n täydellinen tiekartta sisältää ominaisuuksia, kuten parannetut päivitysstrategiat, syvemmän integroinnin OCI-rekistereihin ja JSON-skeemojen käytön kaavioarvojen vahvistamiseen. Suunnittelemme myös koodikannan siivoamista ja sen osien päivittämistä, jotka ovat olleet laiminlyötyjä viimeisen kolmen vuoden aikana.

Jos sinusta tuntuu, että olemme menettäneet jotain, kuulemme mielellämme ajatuksesi!

Liity meidän keskusteluun Hitaat kanavat:

#helm-users kysymyksiin ja yksinkertaiseen kommunikointiin yhteisön kanssa;
#helm-dev keskustellaksesi vetopyynnöistä, koodista ja virheistä.

Voit myös keskustella viikoittaisissa julkisissa kehittäjäpuheluissamme torstaisin klo 19 MSK. Kokoukset on omistettu keskustelemaan tärkeimpien kehittäjien ja yhteisön käsittelemistä asioista sekä viikon keskustelunaiheista. Kuka tahansa voi liittyä kokoukseen ja osallistua siihen. Linkki löytyy Slack-kanavalta #helm-dev.

PS kääntäjältä

Lue myös blogistamme:

Lähde: will.com

Esittelyssä Helm 3