Vi introduserer Helm 3

Merk. overs.: 16. mai i år markerer en betydelig milepæl i utviklingen av pakkeansvarlig for Kubernetes - Helm. På denne dagen ble den første alfa-utgivelsen av den fremtidige hovedversjonen av prosjektet - 3.0 - presentert. Utgivelsen vil bringe betydelige og etterlengtede endringer til Helm, som mange i Kubernetes-samfunnet har store forhåpninger til. Vi er selv en av disse, siden vi aktivt bruker Helm for applikasjonsdistribusjon: vi har integrert det i vårt verktøy for implementering av CI/CD werf og fra tid til annen gir vi vårt bidrag til utviklingen av oppstrøms. Denne oversettelsen kombinerer 7 notater fra den offisielle Helm-bloggen, som er dedikert til den første alfa-utgivelsen av Helm 3 og snakker om historien til prosjektet og hovedtrekkene til Helm 3. Forfatteren deres er Matt "bacongobbler" Fisher, en Microsoft-ansatt og en av de viktigste vedlikeholderne av Helm.

15. oktober 2015 ble prosjektet kjent som Helm født. Bare et år etter grunnleggelsen ble Helm-fellesskapet med i Kubernetes, mens de jobbet aktivt med Helm 2. I juni 2018 ble Helm sluttet seg til CNCF som et utviklende (inkuberende) prosjekt. Spol frem til nåtiden, og den første alfa-utgivelsen av nye Helm 3 er på vei. (denne utgivelsen har allerede funnet sted i midten av mai - ca. oversett.).

I dette stykket skal jeg snakke om hvor det hele begynte, hvordan vi kom dit vi er i dag, introdusere noen av de unike funksjonene som er tilgjengelige i den første alfa-utgivelsen av Helm 3, og forklare hvordan vi planlegger å gå videre.

Sammendrag:

• historien om opprettelsen av Helm;
• et ømt farvel til Tiller;
• kartlagre;
• utgivelsesstyring;
• endringer i diagramavhengigheter;
• bibliotek diagrammer;
• hva blir det neste?

Helms historie

fødsel

Helm 1 startet som et åpen kildekode-prosjekt laget av Deis. Vi var en liten startup absorbert Microsoft våren 2017. Vårt andre Open Source-prosjekt, også kalt Deis, hadde et verktøy deisctl, som ble brukt (blant annet) til å installere og betjene Deis-plattformen i Flåteklynge. På den tiden var Fleet en av de første containerorkestreringsplattformene.

I midten av 2015 bestemte vi oss for å endre kurs og flyttet Deis (den gang omdøpt til Deis Workflow) fra Fleet til Kubernetes. En av de første som ble redesignet var installasjonsverktøyet. deisctl. Vi brukte den til å installere og administrere Deis Workflow i Fleet-klyngen.

Helm 1 ble laget i bildet av kjente pakkeforvaltere som Homebrew, apt og yum. Hovedmålet var å forenkle oppgaver som å pakke og installere applikasjoner på Kubernetes. Helm ble offisielt introdusert i 2015 på KubeCon-konferansen i San Francisco.

Vårt første forsøk med Helm fungerte, men det var ikke uten noen alvorlige begrensninger. Han tok et sett med Kubernetes-manifester, smaksatt med generatorer som innledende YAML-blokker (frontsak)*, og lastet resultatene inn i Kubernetes.

* Merk. overs.: Fra den første versjonen av Helm ble YAML-syntaks valgt for å beskrive Kubernetes-ressurser, og Jinja-maler og Python-skript ble støttet ved skriving av konfigurasjoner. Vi skrev mer om dette og strukturen til den første versjonen av Helm generelt i kapittelet "A Brief History of Helm" dette materialet.

For å erstatte et felt i en YAML-fil, måtte du for eksempel legge til følgende konstruksjon i manifestet:

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

Det er flott at malmotorer eksisterer i dag, er det ikke?

Av mange grunner krevde dette tidlige Kubernetes-installasjonsprogrammet en hardkodet liste over manifestfiler og utførte bare en liten, fast sekvens av hendelser. Det var så vanskelig å bruke at Deis Workflow R&D-teamet hadde det vanskelig da de prøvde å overføre produktet sitt til denne plattformen – men frøene til ideen var allerede sådd. Vårt første forsøk var en stor læringsmulighet: vi innså at vi virkelig var lidenskapelig opptatt av å lage pragmatiske verktøy som løser hverdagsproblemer for brukerne våre.

Basert på erfaringene fra tidligere feil begynte vi å utvikle Helm 2.

Lage Helm 2

På slutten av 2015 tok Google-teamet kontakt med oss. De jobbet med et lignende verktøy for Kubernetes. Deployment Manager for Kubernetes var en port av et eksisterende verktøy som ble brukt for Google Cloud Platform. "Vil vi," spurte de, "å bruke noen dager på å diskutere likheter og forskjeller?"

I januar 2016 møttes teamene for Helm og Deployment Manager i Seattle for å utveksle ideer. Forhandlingene endte med en ambisiøs plan: å kombinere begge prosjektene for å lage Helm 2. Sammen med Deis og Google har gutta fra SkippBox (nå en del av Bitnami - ca. overs.), og vi begynte å jobbe med Helm 2.

Vi ønsket å beholde Helms brukervennlighet, men legg til følgende:

• diagrammaler for tilpasning;
• intra-cluster management for team;
• kartlager i verdensklasse;
• stabilt pakkeformat med signaturalternativ;
• et sterkt engasjement for semantisk versjonering og opprettholdelse av bakoverkompatibilitet mellom versjoner.

For å nå disse målene er et annet element lagt til Helm-økosystemet. Denne intra-cluster-komponenten ble kalt Tiller og var ansvarlig for å installere og administrere Helm-kart.

Siden utgivelsen av Helm 2 i 2016 har Kubernetes lagt til flere store innovasjoner. Lagt til rollebasert tilgangskontroll (RBAC), som til slutt erstattet Attribut-Based Access Control (ABAC). Nye ressurstyper ble introdusert (Deployments var fortsatt i beta på den tiden). Egendefinerte ressursdefinisjoner (opprinnelig kalt tredjepartsressurser eller TPR-er) ble oppfunnet. Og viktigst av alt, et sett med beste praksis har dukket opp.

Midt i alle disse endringene fortsatte Helm å betjene Kubernetes-brukere trofast. Etter tre år og mange nye tillegg, var det klart at det var på tide å gjøre betydelige endringer i kodebasen for å sikre at Helm kunne fortsette å møte de økende behovene til et økosystem i utvikling.

Et ømt farvel til Tiller

Under utviklingen av Helm 2 introduserte vi Tiller som en del av vår integrasjon med Googles Deployment Manager. Tiller spilte en viktig rolle for team som jobbet innenfor en felles klynge: den tillot forskjellige spesialister som opererte infrastrukturen til å samhandle med det samme settet med utgivelser.

Siden rollebasert tilgangskontroll (RBAC) ble aktivert som standard i Kubernetes 1.6, ble det vanskeligere å jobbe med Tiller i produksjonen. På grunn av det store antallet mulige sikkerhetspolicyer, har vår posisjon vært å tilby en tillatt konfigurasjon som standard. Dette tillot nybegynnere å eksperimentere med Helm og Kubernetes uten å måtte dykke inn i sikkerhetsinnstillingene først. Dessverre kan denne tillatelseskonfigurasjonen gi brukeren et for bredt spekter av tillatelser som de ikke trengte. DevOps- og SRE-ingeniører måtte lære ytterligere operasjoneltrinn når de installerte Tiller i en klynge med flere leietakere.

Etter å ha lært hvordan fellesskapet brukte Helm i spesifikke situasjoner, innså vi at Tillers utgivelsesstyringssystem ikke trengte å stole på en intra-klyngekomponent for å opprettholde tilstanden eller fungere som et sentralt knutepunkt for utgivelsesinformasjon. I stedet kunne vi ganske enkelt motta informasjon fra Kubernetes API-serveren, generere et diagram på klientsiden og lagre en oversikt over installasjonen i Kubernetes.

Tillers hovedmål kunne vært oppnådd uten Tiller, så en av våre første avgjørelser angående Helm 3 var å forlate Tiller fullstendig.

Med Tiller borte har Helms sikkerhetsmodell blitt radikalt forenklet. Helm 3 støtter nå alle moderne sikkerhets-, identitets- og autorisasjonsmetoder til nåværende Kubernetes. Hjelmtillatelser bestemmes ved hjelp av kubeconfig-filen. Klyngeadministratorer kan begrense brukerrettigheter til ethvert granularitetsnivå. Utgivelser er fortsatt lagret i klyngen, og resten av Helms funksjonalitet forblir intakt.

Kartlagre

På et høyt nivå er et kartlager et sted der diagrammer kan lagres og deles. Helm-klienten pakker og sender diagrammene til depotet. Enkelt sagt er et diagramlager en primitiv HTTP-server med en index.yaml-fil og noen pakkede diagrammer.

Selv om det er noen fordeler med at Charts Repository API oppfyller de fleste grunnleggende lagringskrav, er det også noen ulemper:

• Kartlagre er ikke kompatible med de fleste sikkerhetsimplementeringer som kreves i et produksjonsmiljø. Å ha en standard API for autentisering og autorisasjon er ekstremt viktig i produksjonsscenarier.
• Helms kartherkomstverktøy, som brukes til å signere, bekrefte integriteten og herkomsten til et diagram, er en valgfri del av diagrampubliseringsprosessen.
• I flerbruksscenarier kan det samme diagrammet lastes opp av en annen bruker, noe som dobler mengden plass som kreves for å lagre det samme innholdet. Smartere depoter er utviklet for å løse dette problemet, men de er ikke en del av den formelle spesifikasjonen.
• Bruk av én enkelt indeksfil for søk, lagring av metadata og henting av diagrammer har gjort det vanskelig å utvikle sikre flerbrukerimplementeringer.

Prosjekt Docker-distribusjon (også kjent som Docker Registry v2) er etterfølgeren til Docker Registry og fungerer i hovedsak som et sett med verktøy for pakking, frakt, lagring og levering av Docker-bilder. Mange store skytjenester tilbyr distribusjonsbaserte produkter. Takket være denne økte oppmerksomheten, har distribusjonsprosjektet dratt nytte av årevis med forbedringer, beste sikkerhetspraksis og felttesting som har gjort det til en av de mest vellykkede ubesungne heltene i Open Source-verdenen.

Men visste du at distribusjonsprosjektet ble designet for å distribuere enhver form for innhold, ikke bare containerbilder?

Takket være innsatsen Åpne Container Initiative (eller OCI), kan rordiagrammer plasseres på en hvilken som helst distribusjonsforekomst. Foreløpig er denne prosessen eksperimentell. Påloggingsstøtte og andre funksjoner som trengs for en full Helm 3 er et arbeid som pågår, men vi er glade for å lære av oppdagelsene OCI- og distribusjonsteamene har gjort gjennom årene. Og gjennom deres veiledning og veiledning lærer vi hvordan det er å drive en høytilgjengelig tjeneste i stor skala.

En mer detaljert beskrivelse av noen kommende endringer i Helm-kartlagrene er tilgjengelig по ссылке.

Utgivelseshåndtering

I Helm 3 spores applikasjonstilstand i klyngen av et par objekter:

• release object - representerer en applikasjonsforekomst;
• utgivelsesversjon hemmelig - representerer ønsket tilstand for applikasjonen på et bestemt tidspunkt (for eksempel utgivelsen av en ny versjon).

samtale helm install oppretter et utgivelsesobjekt og en utgivelsesversjonshemmelighet. Anrop helm upgrade krever et utgivelsesobjekt (som det kan endre) og oppretter en ny utgivelsesversjonshemmelighet som inneholder de nye verdiene og et forberedt manifest.

Utgivelsesobjekt inneholder informasjon om utgivelsen, der utgivelse er en spesifikk installasjon av et navngitt diagram og verdier. Dette objektet beskriver metadataene på toppnivå om utgivelsen. Utgivelsesobjektet vedvarer gjennom hele programmets livssyklus og er eier av alle utgivelsesversjonshemmeligheter, så vel som alle objekter som er direkte opprettet av Helm-diagrammet.

Utgivelsesversjonshemmelighet knytter en utgivelse til en rekke revisjoner (installasjon, oppdateringer, tilbakeføringer, sletting).

I Helm 2 var revisjoner ekstremt konsekvente. Anrop helm install opprettet v1, den påfølgende oppdateringen (oppgraderingen) - v2, og så videre. Hemmeligheten for utgivelse og utgivelsesversjon har blitt slått sammen til et enkelt objekt kjent som revisjon. Revisjoner ble lagret i samme navneområde som Tiller, noe som gjorde at hver utgivelse var "global" når det gjaldt navneområde; som et resultat, kunne bare én forekomst av navnet brukes.

I Helm 3 er hver utgivelse assosiert med en eller flere utgivelsesversjonshemmeligheter. Utgivelsesobjektet beskriver alltid den gjeldende utgivelsen som er distribuert til Kubernetes. Hver utgivelsesversjonshemmelighet beskriver bare én versjon av den utgivelsen. En oppgradering vil for eksempel opprette en ny utgivelsesversjonshemmelighet og deretter endre utgivelsesobjektet til å peke til den nye versjonen. Ved tilbakeføring kan du bruke hemmeligheter for tidligere utgivelsesversjon for å tilbakestille utgivelsen til en tidligere tilstand.

Etter at Tiller er forlatt, lagrer Helm 3 utgivelsesdata i samme navneområde som utgivelsen. Denne endringen lar deg installere et diagram med samme utgivelsesnavn i et annet navneområde, og dataene lagres mellom klyngeoppdateringer/omstarter i etcd. For eksempel kan du installere WordPress i «foo»-navneområdet og deretter i «bar»-navneområdet, og begge utgivelsene kan hete «wordpress».

Endringer i kartavhengigheter

Diagrammer pakket (ved hjelp av helm package) for bruk med Helm 2 kan installeres med Helm 3, men arbeidsflyten for kartutvikling har blitt fullstendig overhalt, så noen endringer må gjøres for å fortsette kartutviklingen med Helm 3. Spesielt har kartavhengighetsstyringssystemet endret seg.

Diagrammets avhengighetsstyringssystem har flyttet fra requirements.yaml и requirements.lock på Chart.yaml и Chart.lock. Dette betyr at diagrammene som brukte kommandoen helm dependency, krever noe oppsett for å fungere i Helm 3.

La oss se på et eksempel. La oss legge til en avhengighet til diagrammet i Helm 2 og se hva som endres når vi flytter til Helm 3.

I Helm 2 requirements.yaml så slik ut:

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

I Helm 3 vil den samme avhengigheten gjenspeiles i din Chart.yaml:

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

Diagrammer er fortsatt lastet ned og plassert i katalogen charts/, så underdiagrammer (underdiagrammer), som ligger i katalogen charts/, vil fortsette å fungere uten endringer.

Vi introduserer bibliotekskart

Helm 3 støtter en klasse med diagrammer kalt bibliotekskart (bibliotekskart). Dette diagrammet brukes av andre diagrammer, men lager ingen utgivelsesartefakter alene. Bibliotekskartmaler kan bare deklarere elementer define. Annet innhold blir rett og slett ignorert. Dette lar brukere gjenbruke og dele kodebiter som kan brukes på tvers av flere diagrammer, og dermed unngå duplisering og overholde prinsippet TØRR.

Bibliotekskart er deklarert i seksjonen dependencies i fil Chart.yaml. Installering og administrasjon av dem er ikke forskjellig fra andre diagrammer.

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

Vi er begeistret for brukstilfellene denne komponenten vil åpne opp for kartutviklere, så vel som de beste praksisene som kan dukke opp fra bibliotekkart.

Hva blir det neste?

Helm 3.0.0-alpha.1 er grunnlaget som vi begynner å bygge en ny versjon av Helm på. I artikkelen beskrev jeg noen interessante trekk ved Helm 3. Mange av dem er fortsatt i de tidlige utviklingsstadiene og dette er normalt; Poenget med en alfa-utgivelse er å teste ideen, samle tilbakemeldinger fra tidlige brukere og bekrefte våre antakelser.

Så snart alfaversjonen er utgitt (husk at dette er allerede skjedd — ca. oversett.), vil vi begynne å godta patcher for Helm 3 fra fellesskapet. Du må skape et sterkt grunnlag som gjør at ny funksjonalitet kan utvikles og ta i bruk, og for at brukerne skal føle seg involvert i prosessen ved å åpne billetter og gjøre rettelser.

Jeg har prøvd å fremheve noen av de store forbedringene som kommer til Helm 3, men denne listen er på ingen måte uttømmende. Det fullstendige veikartet for Helm 3 inkluderer funksjoner som forbedrede oppdateringsstrategier, dypere integrasjon med OCI-registre og bruk av JSON-skjemaer for å validere kartverdier. Vi planlegger også å rydde opp i kodebasen og oppdatere deler av den som har blitt neglisjert de siste tre årene.

Hvis du føler at vi har gått glipp av noe, vil vi gjerne høre dine tanker!

Bli med i diskusjonen på vår Slakke kanaler:

• #helm-users for spørsmål og enkel kommunikasjon med samfunnet;
• #helm-dev for å diskutere pull-forespørsler, kode og feil.

Du kan også chatte i våre ukentlige offentlige utviklersamtaler på torsdager kl. 19:30 MSK. Møtene er dedikert til å diskutere saker som sentrale utviklere og fellesskapet jobber med, samt diskusjonstemaer for uken. Alle kan være med og delta på møtet. Link tilgjengelig i Slack-kanalen #helm-dev.

PS fra oversetter

Les også på bloggen vår:

• «Pakkebehandler for Kubernetes - Helm: fortid, nåtid, fremtid";
• «Et nøkternt blikk på Helm 2: "Dette er hva det er..."";
• «Praktisk introduksjon til pakkeansvarlig for Kubernetes - Helm";
• «Kubernetes tips og triks: overføring av ressurser som kjører i en klynge til Helm 2-administrasjon";
• «Øv med dapp. Del 2. Distribuere Docker-bilder til Kubernetes ved hjelp av Helm'.

Kilde: www.habr.com