🥇Inleiding tot Roer 3

Let wel. vertaal.: 16 Mei vanjaar is 'n belangrike mylpaal in die ontwikkeling van die pakketbestuurder vir Kubernetes - Helm. Op hierdie dag is die eerste alfa-vrystelling van die toekomstige hoofweergawe van die projek - 3.0 - aangebied. Die vrystelling daarvan sal aansienlike en langverwagte veranderinge aan Helm bring, waarvoor baie in die Kubernetes-gemeenskap groot verwagtinge het. Ons self is een hiervan, aangesien ons Helm aktief gebruik vir toepassingsimplementering: ons het dit geïntegreer in ons instrument vir die implementering van CI/CD werf en van tyd tot tyd lewer ons ons bydrae tot die ontwikkeling van stroomop. Hierdie vertaling kombineer 7 notas van die amptelike Helm-blog, wat gewy is aan die eerste alfa-vrystelling van Helm 3 en praat oor die geskiedenis van die projek en die hoofkenmerke van Helm 3. Hul skrywer is Matt "bacongobbler" Fisher, 'n Microsoft-werknemer en een van die sleutelonderhouers van Helm.

Op 15 Oktober 2015 is die projek wat nou bekend staan as Helm gebore. Net 'n jaar ná sy stigting het die Helm-gemeenskap by Kubernetes aangesluit terwyl hulle aktief aan Helm 2 gewerk het. In Junie 2018 het Helm by die CNCF aangesluit as 'n ontwikkelende (inkuberende) projek. Vinnig vorentoe na die hede, en die eerste alfa-vrystelling van die nuwe Helm 3 is op pad. (hierdie vrystelling reeds plaasgevind het middel Mei - ongeveer. vertaal.).

In hierdie artikel sal ek praat oor waar dit alles begin het, hoe ons gekom het waar ons vandag is, sommige van die unieke kenmerke bekendstel wat beskikbaar is in die eerste alfa-vrystelling van Helm 3, en verduidelik hoe ons beplan om verder te ontwikkel.

opsomming:

die geskiedenis van die skepping van Helm;
'n tere afskeid van Tiller;
kaartbewaarplekke;
vrystellingsbestuur;
veranderinge in grafiekafhanklikhede;
biblioteekkaarte;
wat is volgende?

Die geskiedenis van Helm

geboorte

Helm 1 het begin as 'n oopbronprojek wat deur Deis geskep is. Ons was 'n klein beginner geabsorbeer Microsoft in die lente van 2017. Ons ander oopbronprojek, ook genaamd Deis, het 'n hulpmiddel gehad deisctl, wat (onder andere) gebruik is om die Deis-platform in te installeer en te bedryf Vlootgroepering. Destyds was Fleet een van die eerste houerorkestrasieplatforms.

In die middel van 2015 het ons besluit om van koers te verander en Deis (destyds herdoop tot Deis Workflow) van Fleet na Kubernetes geskuif. Een van die eerstes wat herontwerp is, was die installasie-instrument. deisctl. Ons het dit gebruik om Deis Workflow in die Fleet-kluster te installeer en te bestuur.

Helm 1 is geskep in die beeld van bekende pakketbestuurders soos Homebrew, apt en yum. Sy hoofdoel was om take soos verpakking en installering van toepassings op Kubernetes te vereenvoudig. Helm is amptelik in 2015 by die KubeCon-konferensie in San Francisco bekendgestel.

Ons eerste poging met Helm het gewerk, maar dit was nie sonder ernstige beperkings nie. Hy het 'n stel Kubernetes-manifeste geneem, gegeur met kragopwekkers as inleidende YAML-blokke (voorkant)*, en die resultate in Kubernetes gelaai.

* Let wel. vertaal.: Vanaf die eerste weergawe van Helm is YAML-sintaksis gekies om Kubernetes-hulpbronne te beskryf, en Jinja-sjablone en Python-skrifte is ondersteun tydens die skryf van konfigurasies. Ons het meer hieroor en die struktuur van die eerste weergawe van Helm in die algemeen geskryf in die hoofstuk "A Brief History of Helm" hierdie materiaal.

Byvoorbeeld, om 'n veld in 'n YAML-lêer te vervang, moes jy die volgende konstruk by die manifes voeg:

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

Dit is wonderlik dat sjabloonenjins vandag bestaan, is dit nie?

Om baie redes het hierdie vroeë Kubernetes-installeerder 'n hardgekodeerde lys van manifeslêers vereis en slegs 'n klein, vaste volgorde van gebeure uitgevoer. Dit was so moeilik om te gebruik dat die Deis Workflow R&D-span 'n moeilike tyd gehad het toe hulle probeer het om hul produk na hierdie platform oor te dra – die saadjies van die idee was egter reeds gesaai. Ons eerste poging was 'n wonderlike leergeleentheid: ons het besef ons is werklik passievol daaroor om pragmatiese gereedskap te skep wat alledaagse probleme vir ons gebruikers oplos.

Gebaseer op die ervaring van vorige foute, het ons begin om Helm 2 te ontwikkel.

Maak Roer 2

Aan die einde van 2015 het die Google-span ons gekontak. Hulle het gewerk aan 'n soortgelyke instrument vir Kubernetes. Ontplooiingsbestuurder vir Kubernetes was 'n poort van 'n bestaande nutsding wat vir Google Wolkplatform gebruik is. "Wil ons graag," het hulle gevra, "'n paar dae spandeer om die ooreenkomste en verskille te bespreek?"

In Januarie 2016 het die Helm- en Ontplooiingsbestuurder-spanne in Seattle vergader om idees uit te ruil. Die onderhandelinge het geëindig met 'n ambisieuse plan: om albei projekte te kombineer om Helm 2 te skep. Saam met Deis en Google het die ouens van SkipBox (nou deel van Bitnami - ongeveer vertaal.), en ons het aan Helm 2 begin werk.

Ons wou Helm se gebruiksgemak behou, maar voeg die volgende by:

grafieksjablone vir aanpassing;
intraklusterbestuur vir spanne;
wêreldklas kaartbewaarplek;
stabiele pakketformaat met handtekeningopsie;
'n sterk verbintenis tot semantiese weergawe en die handhawing van terugwaartse versoenbaarheid tussen weergawes.

Om hierdie doelwitte te bereik, is 'n tweede element by die Helm-ekosisteem gevoeg. Hierdie intra-kluster-komponent is Tiller genoem en was verantwoordelik vir die installering van Helm-kaarte en die bestuur daarvan.

Sedert die vrystelling van Helm 2 in 2016, het Kubernetes verskeie groot innovasies bygevoeg. Bygevoeg rolgebaseerde toegangsbeheer (RBAC), wat uiteindelik Attribuut-Based Access Control (ABAC) vervang het. Nuwe hulpbrontipes is ingestel (Ontplooiings was toe nog in beta). Pasgemaakte hulpbrondefinisies (oorspronklik genoem Derdepartyhulpbronne of TPR's) is uitgevind. En die belangrikste is dat 'n stel beste praktyke na vore gekom het.

Te midde van al hierdie veranderinge het Helm voortgegaan om Kubernetes-gebruikers getrou te dien. Na drie jaar en baie nuwe toevoegings, was dit duidelik dat dit tyd was om beduidende veranderinge aan die kodebasis aan te bring om te verseker dat Helm kan voortgaan om aan die groeiende behoeftes van 'n ontwikkelende ekosisteem te voldoen.

’n Sagte afskeid van Tiller

Tydens die ontwikkeling van Helm 2 het ons Tiller bekendgestel as deel van ons integrasie met Google se Ontplooiingsbestuurder. Tiller het 'n belangrike rol gespeel vir spanne wat binne 'n gemeenskaplike groepering werk: dit het verskillende spesialiste wat die infrastruktuur bedryf, toegelaat om met dieselfde stel vrystellings te werk.

Aangesien rolgebaseerde toegangsbeheer (RBAC) by verstek in Kubernetes 1.6 geaktiveer is, het dit moeiliker geword om met Tiller in produksie te werk. As gevolg van die groot aantal moontlike sekuriteitsbeleide, is ons standpunt om by verstek 'n permissiewe opstelling aan te bied. Dit het beginners in staat gestel om met Helm en Kubernetes te eksperimenteer sonder om eers na sekuriteitsinstellings te hoef duik. Ongelukkig kan hierdie toestemmingkonfigurasie die gebruiker 'n te wye reeks toestemmings gee wat hulle nie nodig het nie. DevOps- en SRE-ingenieurs moes bykomende operasionele stappe leer wanneer Tiller in 'n multi-huurder-kluster geïnstalleer word.

Nadat ons geleer het hoe die gemeenskap Helm in spesifieke situasies gebruik het, het ons besef dat Tiller se vrystellingbestuurstelsel nie op 'n intra-kluster-komponent hoef staat te maak om toestand te handhaaf of as 'n sentrale spilpunt vir vrystellingsinligting te funksioneer nie. In plaas daarvan kan ons eenvoudig inligting van die Kubernetes API-bediener ontvang, 'n grafiek aan die kliëntkant genereer en 'n rekord van die installasie in Kubernetes stoor.

Tiller se hoofdoel kon bereik gewees het sonder Tiller, so een van ons eerste besluite rakende Helm 3 was om Tiller heeltemal te laat vaar.

Met Tiller weg, is Helm se sekuriteitsmodel radikaal vereenvoudig. Helm 3 ondersteun nou al die moderne sekuriteits-, identiteits- en magtigingsmetodes van huidige Kubernetes. Roertoestemmings word bepaal deur gebruik te maak van kubeconfig-lêer. Klusteradministrateurs kan gebruikersregte beperk tot enige vlak van granulariteit. Vrystellings word steeds binne die groep gestoor, en die res van Helm se funksionaliteit bly ongeskonde.

Grafiekbewaarplekke

Op 'n hoë vlak is 'n kaartbewaarplek 'n plek waar kaarte gestoor en gedeel kan word. Die Helm-kliënt verpak en stuur die kaarte na die bewaarplek. Eenvoudig gestel, 'n kaartbewaarplek is 'n primitiewe HTTP-bediener met 'n index.yaml-lêer en 'n paar verpakte kaarte.

Alhoewel daar 'n paar voordele is aan die Charts Repository API wat aan die meeste basiese bergingsvereistes voldoen, is daar ook 'n paar nadele:

Grafiekbewaarplekke is nie versoenbaar met die meeste sekuriteitsimplementerings wat in 'n produksie-omgewing vereis word nie. Om 'n standaard API vir verifikasie en magtiging te hê, is uiters belangrik in produksiescenario's.
Helm se kaartherkomsinstrumente, wat gebruik word om die integriteit en herkoms van 'n grafiek te onderteken, te verifieer, is 'n opsionele deel van die grafiekpubliseringsproses.
In multigebruikerscenario's kan dieselfde grafiek deur 'n ander gebruiker opgelaai word, wat die hoeveelheid spasie wat benodig word om dieselfde inhoud te stoor verdubbel. Slimmer bewaarplekke is ontwikkel om hierdie probleem op te los, maar dit is nie deel van die formele spesifikasie nie.
Die gebruik van 'n enkele indekslêer vir soek, berging van metadata en herwinning van kaarte het dit moeilik gemaak om veilige multi-gebruiker implementerings te ontwikkel.

Project Docker-verspreiding (ook bekend as Docker Registry v2) is die opvolger van Docker Registry en dien in wese as 'n stel gereedskap vir verpakking, versending, berging en aflewering van Docker-beelde. Baie groot wolkdienste bied verspreidingsgebaseerde produkte aan. Danksy hierdie verhoogde aandag het die verspreidingsprojek baat gevind by jare se verbeterings, beste sekuriteitspraktyke en veldtoetsing wat dit een van die suksesvolste onbesonge helde van die oopbronwêreld gemaak het.

Maar het jy geweet dat die verspreidingsprojek ontwerp is om enige vorm van inhoud te versprei, nie net houerprente nie?

Danksy die pogings Open Container Initiative (of OCI), Roerkaarte kan op enige verspreidingsinstansie geplaas word. Vir nou is hierdie proses eksperimenteel. Aanmelding-ondersteuning en ander kenmerke wat nodig is vir 'n volledige Helm 3 is 'n werk aan die gang, maar ons is opgewonde om te leer uit die ontdekkings wat die OCI- en Distribusie-spanne oor die jare gemaak het. En deur hul mentorskap en leiding leer ons hoe dit is om 'n hoogs beskikbare diens op skaal te bedryf.

'n Meer gedetailleerde beskrywing van sommige komende veranderinge aan die Helm-kaartbewaarplekke is beskikbaar по ссылке.

Vrystellingsbestuur

In Helm 3 word toepassingstatus binne die groep opgespoor deur 'n paar voorwerpe:

vrystelling voorwerp - verteenwoordig 'n toepassing instansie;
vrystelling weergawe geheim - verteenwoordig die verlangde toestand van die toepassing op 'n spesifieke tydstip (byvoorbeeld die vrystelling van 'n nuwe weergawe).

oproep helm install skep 'n vrystelling-objek en vrystelling weergawe geheim. Bel helm upgrade vereis 'n vrystelling-objek (wat dit kan verander) en skep 'n nuwe weergawe-weergawe geheim wat die nuwe waardes en 'n voorbereide manifes bevat.

Vrystelling-objek bevat inligting oor die vrystelling, waar vrystelling 'n spesifieke installasie van 'n benoemde grafiek en waardes is. Hierdie voorwerp beskryf die topvlak-metadata oor die vrystelling. Die vrystelling-objek bly dwarsdeur die toepassing se lewensiklus en is die eienaar van alle vrystellingweergawe-geheime, sowel as alle voorwerpe wat direk deur die Helm-grafiek geskep word.

Vrystelling weergawe geheim assosieer 'n vrystelling met 'n reeks hersienings (installasie, opdaterings, terugskrywings, verwydering).

In Helm 2 was hersienings uiters konsekwent. Bel helm install geskep v1, die daaropvolgende opdatering (opgradering) - v2, ensovoorts. Vrystelling en vrystelling weergawe geheim is ineengevou in 'n enkele voorwerp bekend as hersiening. Hersienings is in dieselfde naamruimte as Tiller gestoor, wat beteken het dat elke vrystelling "globaal" was in terme van naamruimte; gevolglik kon slegs een instansie van die naam gebruik word.

In Helm 3 word elke vrystelling geassosieer met een of meer vrystelling weergawe geheime. Die vrystelling-objek beskryf altyd die huidige vrystelling wat na Kubernetes ontplooi is. Elke vrystelling weergawe geheim beskryf slegs een weergawe van daardie vrystelling. 'n Opgradering sal byvoorbeeld 'n nuwe weergawe-weergawe-geheim skep en dan die vrystelling-voorwerp verander om na daardie nuwe weergawe te wys. In die geval van terugrol, kan jy vorige weergawe weergawe geheime gebruik om die vrystelling terug te rol na 'n vorige toestand.

Nadat Tiller verlaat is, stoor Helm 3 vrystellingdata in dieselfde naamruimte as die vrystelling. Hierdie verandering laat jou toe om 'n grafiek met dieselfde vrystellingnaam in 'n ander naamruimte te installeer, en die data word gestoor tussen groepopdaterings/herlaai in etcd. Byvoorbeeld, jy kan WordPress installeer in die "foo" naamruimte en dan in die "bar" naamruimte, en beide vrystellings kan "wordpress" genoem word.

Veranderinge aan grafiekafhanklikhede

Kaarte verpak (met helm package) vir gebruik met Helm 2 kan met Helm 3 geïnstalleer word, maar die grafiekontwikkelingswerkvloei is heeltemal hersien, so 'n paar veranderinge moet aangebring word om grafiekontwikkeling met Helm 3 voort te sit. Die kaartafhanklikheidbestuurstelsel het veral verander.

Die grafiek se afhanklikheidsbestuurstelsel het verskuif vanaf requirements.yaml и requirements.lock op Chart.yaml и Chart.lock. Dit beteken dat die kaarte wat die opdrag gebruik het helm dependency, vereis 'n mate van opstelling om in Helm 3 te werk.

Kom ons kyk na 'n voorbeeld. Kom ons voeg 'n afhanklikheid by die grafiek in Helm 2 en kyk wat verander wanneer jy na Helm 3 beweeg.

In Roer 2 requirements.yaml het so gelyk:

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

In Helm 3 sal dieselfde afhanklikheid in jou weerspieël word Chart.yaml:

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

Kaarte word steeds afgelaai en in die gids geplaas charts/, dus subkaarte (subkaarte), wat in die katalogus lê charts/, sal sonder veranderings aanhou werk.

Bekendstelling van Biblioteekkaarte

Helm 3 ondersteun 'n klas kaarte wat biblioteekkaarte genoem word (biblioteekkaart). Hierdie grafiek word deur ander kaarte gebruik, maar skep geen vrystellingsartefakte op sy eie nie. Biblioteekkaartsjablone kan slegs elemente verklaar define. Ander inhoud word eenvoudig geïgnoreer. Dit stel gebruikers in staat om kodebrokkies te hergebruik en te deel wat oor verskeie kaarte gebruik kan word, en sodoende duplisering vermy en die beginsel nakom DRY.

Biblioteekkaarte word in die afdeling verklaar dependencies in lêer Chart.yaml. Die installering en bestuur daarvan verskil nie van ander kaarte nie.

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

Ons is opgewonde oor die gebruiksgevalle wat hierdie komponent vir kaartontwikkelaars sal oopmaak, sowel as die beste praktyke wat uit biblioteekkaarte kan voortspruit.

Wat is volgende?

Helm 3.0.0-alpha.1 is die grondslag waarop ons begin om 'n nuwe weergawe van Helm te bou. In die artikel het ek 'n paar interessante kenmerke van Helm 3 beskryf. Baie van hulle is nog in die vroeë stadiums van ontwikkeling en dit is normaal; Die punt van 'n alfa-vrystelling is om die idee te toets, terugvoer van vroeë gebruikers in te samel en ons aannames te bevestig.

Sodra die alfa-weergawe vrygestel is (Onthou dat dit is het reeds gebeur - ongeveer. vertaal.), sal ons pleisters vir Helm 3 van die gemeenskap begin aanvaar. Jy moet 'n sterk fondament skep wat dit moontlik maak om nuwe funksionaliteit te ontwikkel en aan te neem, en vir gebruikers om betrokke te voel by die proses deur kaartjies oop te maak en regstellings te maak.

Ek het probeer om 'n paar van die belangrikste verbeterings wat na Helm 3 kom, uit te lig, maar hierdie lys is geensins volledig nie. Die volledige padkaart vir Helm 3 bevat kenmerke soos verbeterde opdateringstrategieë, dieper integrasie met OCI-registers, en die gebruik van JSON-skemas om grafiekwaardes te valideer. Ons beplan ook om die kodebasis skoon te maak en dele daarvan op te dateer wat die afgelope drie jaar verwaarloos is.

As jy voel dat ons iets gemis het, sal ons graag jou gedagtes hoor!

Sluit aan by die bespreking op ons Slap kanale:

#helm-users vir vrae en eenvoudige kommunikasie met die gemeenskap;
#helm-dev trekversoeke, kode en foute te bespreek.

Jy kan ook op Donderdae om 19:30 MSK in ons weeklikse openbare ontwikkelaaroproepe gesels. Vergaderings word gewy aan die bespreking van kwessies waaraan sleutelontwikkelaars en die gemeenskap werk, sowel as onderwerpe van bespreking vir die week. Enigiemand kan aansluit en aan die vergadering deelneem. Skakel beskikbaar in Slack-kanaal #helm-dev.

Inleiding tot Roer 3