🥇Introduktion til Helm 3

Bemærk. overs.: 16. maj i år markerer en væsentlig milepæl i udviklingen af pakkehåndteringen til Kubernetes - Helm. På denne dag blev den første alfa-udgivelse af den fremtidige større version af projektet - 3.0 - præsenteret. Dens udgivelse vil medføre betydelige og længe ventede ændringer til Helm, som mange i Kubernetes-samfundet har store forhåbninger til. Vi er selv en af disse, da vi aktivt bruger Helm til applikationsimplementering: vi har integreret det i vores værktøj til implementering af CI/CD werf og fra tid til anden yder vi vores bidrag til udviklingen af upstream. Denne oversættelse kombinerer 7 noter fra den officielle Helm-blog, som er dedikeret til den første alfa-udgivelse af Helm 3 og taler om projektets historie og hovedfunktionerne i Helm 3. Deres forfatter er Matt "bacongobbler" Fisher, en Microsoft-medarbejder og en af de vigtigste vedligeholdere af Helm.

Den 15. oktober 2015 blev projektet nu kendt som Helm født. Blot et år efter grundlæggelsen sluttede Helm-fællesskabet sig til Kubernetes, mens de arbejdede aktivt på Helm 2. I juni 2018 blev Helm sluttede sig til CNCF som et udviklende (inkuberende) projekt. Spol frem til nutiden, og den første alfa-udgivelse af den nye Helm 3 er på vej. (denne udgivelse allerede har fundet sted i midten af maj - ca. oversættelse).

I dette stykke vil jeg tale om, hvor det hele begyndte, hvordan vi nåede dertil, hvor vi er i dag, introducere nogle af de unikke funktioner, der er tilgængelige i den første alfa-udgivelse af Helm 3, og forklare, hvordan vi planlægger at komme videre.

Resumé:

historien om skabelsen af Helm;
et kærligt farvel til Tiller;
diagramlagre;
frigivelsesstyring;
ændringer i diagramafhængigheder;
biblioteksdiagrammer;
hvad er det næste?

Helms historie

fødsel

Helm 1 startede som et Open Source-projekt skabt af Deis. Vi var en lille startup absorberet Microsoft i foråret 2017. Vores andet Open Source-projekt, også kaldet Deis, havde et værktøj deisctl, som blev brugt (blandt andet) til at installere og betjene Deis platformen i Flåde klynge. På det tidspunkt var Fleet en af de første containerorkestreringsplatforme.

I midten af 2015 besluttede vi at ændre kurs og flyttede Deis (på det tidspunkt omdøbt til Deis Workflow) fra Fleet til Kubernetes. En af de første, der blev redesignet, var installationsværktøjet. deisctl. Vi brugte det til at installere og administrere Deis Workflow i Fleet-klyngen.

Helm 1 blev skabt i billedet af berømte pakkeadministratorer som Homebrew, apt og yum. Dets hovedmål var at forenkle opgaver såsom pakning og installation af applikationer på Kubernetes. Helm blev officielt introduceret i 2015 på KubeCon-konferencen i San Francisco.

Vores første forsøg med Helm virkede, men det var ikke uden nogle alvorlige begrænsninger. Han tog et sæt Kubernetes-manifester, smagt til med generatorer som indledende YAML-blokke (front-sag)*, og indlæste resultaterne i Kubernetes.

* Bemærk. overs.: Fra den første version af Helm blev YAML-syntaks valgt til at beskrive Kubernetes-ressourcer, og Jinja-skabeloner og Python-scripts blev understøttet ved skrivning af konfigurationer. Vi skrev mere om dette og strukturen af den første version af Helm generelt i kapitlet "A Brief History of Helm" dette materiale.

For eksempel, for at erstatte et felt i en YAML-fil, skulle du tilføje følgende konstruktion til manifestet:

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

Det er dejligt, at skabelonmotorer eksisterer i dag, er det ikke?

Af mange grunde krævede dette tidlige Kubernetes-installationsprogram en hårdkodet liste over manifestfiler og udførte kun en lille, fast sekvens af begivenheder. Det var så svært at bruge, at Deis Workflow R&D-teamet havde det svært, da de forsøgte at overføre deres produkt til denne platform – dog var kimen til ideen allerede sået. Vores første forsøg var en fantastisk læringsmulighed: vi indså, at vi virkelig brændte for at skabe pragmatiske værktøjer, der løser hverdagens problemer for vores brugere.

Baseret på erfaringerne fra tidligere fejl, begyndte vi at udvikle Helm 2.

Fremstilling af Helm 2

I slutningen af 2015 kontaktede Google-teamet os. De arbejdede på et lignende værktøj til Kubernetes. Deployment Manager for Kubernetes var en port af et eksisterende værktøj, der blev brugt til Google Cloud Platform. "Vil vi gerne," spurgte de, "at bruge et par dage på at diskutere ligheder og forskelle?"

I januar 2016 mødtes Helm- og Deployment Manager-teamene i Seattle for at udveksle ideer. Forhandlingerne endte med en ambitiøs plan: at kombinere begge projekter for at skabe Helm 2. Sammen med Deis og Google er fyrene fra SkippBox (nu en del af Bitnami - ca. oversættelse), og vi begyndte at arbejde på Helm 2.

Vi ønskede at bevare Helms brugervenlighed, men tilføje følgende:

diagramskabeloner til tilpasning;
intra-cluster management for teams;
diagramlager i verdensklasse;
stabilt pakkeformat med signaturmulighed;
et stærkt engagement i semantisk versionering og opretholdelse af bagudkompatibilitet mellem versioner.

For at nå disse mål er der tilføjet et andet element til Helm-økosystemet. Denne intra-cluster-komponent blev kaldt Tiller og var ansvarlig for at installere Helm-kort og administrere dem.

Siden udgivelsen af Helm 2 i 2016 har Kubernetes tilføjet flere store innovationer. Tilføjet rollebaseret adgangskontrol (RBAC), som til sidst erstattede Attribut-Based Access Control (ABAC). Nye ressourcetyper blev introduceret (implementeringer var stadig i beta på det tidspunkt). Brugerdefinerede ressourcedefinitioner (oprindeligt kaldet tredjepartsressourcer eller TPR'er) blev opfundet. Og vigtigst af alt er der dukket et sæt bedste praksis op.

Midt i alle disse ændringer fortsatte Helm med at betjene Kubernetes-brugere trofast. Efter tre år og mange nye tilføjelser var det klart, at det var på tide at foretage væsentlige ændringer i kodebasen for at sikre, at Helm kunne fortsætte med at opfylde de voksende behov i et økosystem i udvikling.

Et kærligt farvel til Tiller

Under udviklingen af Helm 2 introducerede vi Tiller som en del af vores integration med Googles Deployment Manager. Tiller spillede en vigtig rolle for teams, der arbejdede inden for en fælles klynge: det gjorde det muligt for forskellige specialister, der betjener infrastrukturen, at interagere med det samme sæt udgivelser.

Da rollebaseret adgangskontrol (RBAC) var aktiveret som standard i Kubernetes 1.6, blev det vanskeligere at arbejde med Tiller i produktionen. På grund af det store antal mulige sikkerhedspolitikker har vores holdning været at tilbyde en tilladelig konfiguration som standard. Dette gjorde det muligt for nybegyndere at eksperimentere med Helm og Kubernetes uden først at skulle dykke ned i sikkerhedsindstillingerne. Desværre kunne denne tilladelseskonfiguration give brugeren et for bredt udvalg af tilladelser, som de ikke havde brug for. DevOps- og SRE-ingeniører skulle lære yderligere operationelle trin, når de installerede Tiller i en klynge med flere lejere.

Efter at have lært, hvordan fællesskabet brugte Helm i specifikke situationer, indså vi, at Tillers frigivelsesstyringssystem ikke behøvede at stole på en intra-cluster-komponent for at opretholde tilstand eller fungere som et centralt knudepunkt for udgivelsesinformation. I stedet kunne vi blot modtage information fra Kubernetes API-serveren, generere et diagram på klientsiden og gemme en registrering af installationen i Kubernetes.

Tillers hovedmål kunne have været opnået uden Tiller, så en af vores første beslutninger vedrørende Helm 3 var helt at opgive Tiller.

Med Tiller væk, er Helms sikkerhedsmodel blevet radikalt forenklet. Helm 3 understøtter nu alle de moderne sikkerheds-, identitets- og godkendelsesmetoder fra nuværende Kubernetes. Hjelmtilladelser bestemmes ved hjælp af kubeconfig fil. Klyngeadministratorer kan begrænse brugerrettigheder til ethvert granularitetsniveau. Udgivelser gemmes stadig i klyngen, og resten af Helms funktionalitet forbliver intakt.

Diagramdepoter

På et højt niveau er et diagramlager et sted, hvor diagrammer kan gemmes og deles. Helm-klienten pakker og sender diagrammerne til depotet. Kort sagt er et diagramlager en primitiv HTTP-server med en index.yaml-fil og nogle pakkede diagrammer.

Selvom der er nogle fordele ved, at Charts Repository API opfylder de fleste grundlæggende opbevaringskrav, er der også et par ulemper:

Diagramlagre er ikke kompatible med de fleste sikkerhedsimplementeringer, der kræves i et produktionsmiljø. At have en standard API til godkendelse og godkendelse er ekstremt vigtigt i produktionsscenarier.
Helms værktøj til at underskrive, verificere integriteten og herkomsten af et diagram, er en valgfri del af diagramudgivelsesprocessen.
I scenarier med flere brugere kan det samme diagram uploades af en anden bruger, hvilket fordobler mængden af plads, der kræves for at gemme det samme indhold. Smartere repositories er blevet udviklet til at løse dette problem, men de er ikke en del af den formelle specifikation.
Brug af en enkelt indeksfil til søgning, lagring af metadata og hentning af diagrammer har gjort det vanskeligt at udvikle sikre flerbrugerimplementeringer.

Projekt Docker distribution (også kendt som Docker Registry v2) er efterfølgeren til Docker Registry og fungerer i det væsentlige som et sæt værktøjer til emballering, forsendelse, lagring og levering af Docker-billeder. Mange store cloud-tjenester tilbyder distributionsbaserede produkter. Takket være denne øgede opmærksomhed har distributionsprojektet nydt godt af mange års forbedringer, bedste sikkerhedspraksis og felttest, der har gjort det til en af de mest succesfulde ubesungne helte i Open Source-verdenen.

Men vidste du, at distributionsprojektet var designet til at distribuere enhver form for indhold, ikke kun containerbilleder?

Takket være indsatsen Åbn Container Initiative (eller OCI), kan Helm-diagrammer placeres på enhver distributionsforekomst. Indtil videre er denne proces eksperimentel. Login-support og andre funktioner, der er nødvendige for en fuld Helm 3, er et igangværende arbejde, men vi er glade for at lære af de opdagelser, som OCI- og distributionsholdene har gjort gennem årene. Og gennem deres mentorskab og vejledning lærer vi, hvordan det er at drive en yderst tilgængelig service i stor skala.

En mere detaljeret beskrivelse af nogle kommende ændringer til Helm-kortlagrene er tilgængelig по ссылке.

Udgivelsesstyring

I Helm 3 spores applikationstilstand i klyngen af et par objekter:

frigivelsesobjekt - repræsenterer en applikationsforekomst;
release version secret - repræsenterer den ønskede tilstand af applikationen på et bestemt tidspunkt (f.eks. frigivelsen af en ny version).

opkald helm install opretter et frigivelsesobjekt og frigivelsesversionshemmelighed. Opkald helm upgrade kræver et udgivelsesobjekt (som det kan ændre) og opretter en ny udgivelsesversionshemmelighed indeholdende de nye værdier og et forberedt manifest.

Frigivelsesobjekt indeholder information om udgivelsen, hvor udgivelse er en specifik installation af et navngivet diagram og værdier. Dette objekt beskriver metadata på øverste niveau om udgivelsen. Frigivelsesobjektet består i hele applikationens livscyklus og er ejer af alle udgivelsesversionshemmeligheder, såvel som alle objekter, der er direkte oprettet af Helm-diagrammet.

Release version secret associerer en release med en række revisioner (installation, opdateringer, rollbacks, sletning).

I Helm 2 var revisionerne ekstremt konsekvente. Opkald helm install oprettet v1, den efterfølgende opdatering (opgradering) - v2, og så videre. Udgivelses- og udgivelsesversionens hemmelige er blevet sammenklappet til et enkelt objekt kendt som revision. Revisioner blev gemt i samme navneområde som Tiller, hvilket betød, at hver udgivelse var "global" med hensyn til navneområde; som følge heraf kunne kun én forekomst af navnet bruges.

I Helm 3 er hver udgivelse forbundet med en eller flere udgivelsesversionshemmeligheder. Frigivelsesobjektet beskriver altid den aktuelle udgivelse, der er implementeret til Kubernetes. Hver udgivelsesversionshemmelighed beskriver kun én version af denne udgivelse. En opgradering vil f.eks. oprette en ny udgivelsesversionshemmelighed og derefter ændre udgivelsesobjektet til at pege på den nye version. I tilfælde af en tilbagerulning kan du bruge hemmeligheder til tidligere udgivelsesversioner til at rulle udgivelsen tilbage til en tidligere tilstand.

Efter Tiller er forladt, gemmer Helm 3 udgivelsesdata i samme navneområde som udgivelsen. Denne ændring giver dig mulighed for at installere et diagram med det samme udgivelsesnavn i et andet navneområde, og dataene gemmes mellem klyngeopdateringer/genstarter i etcd. For eksempel kan du installere WordPress i "foo"-navneområdet og derefter i "bar"-navnerummet, og begge udgivelser kan få navnet "wordpress".

Ændringer i diagramafhængigheder

Diagrammer pakket (ved hjælp af helm package) til brug med Helm 2 kan installeres med Helm 3, dog er diagramudviklingens arbejdsgang blevet fuldstændig eftersyn, så der skal foretages nogle ændringer for at fortsætte diagramudviklingen med Helm 3. Især diagramafhængighedsstyringssystemet er ændret.

Diagrammets afhængighedsstyringssystem er flyttet fra requirements.yaml и requirements.lock på Chart.yaml и Chart.lock. Det betyder, at de diagrammer, der brugte kommandoen helm dependency, kræver en vis opsætning for at fungere i Helm 3.

Lad os se på et eksempel. Lad os tilføje en afhængighed til diagrammet i Helm 2 og se, hvad der ændrer sig, når vi flytter til Helm 3.

I Helm 2 requirements.yaml så sådan her ud:

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 afhængighed afspejle sig i din Chart.yaml:

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

Diagrammer downloades stadig og placeres i biblioteket charts/, så underdiagrammer (underdiagrammer), der ligger i kataloget charts/, vil fortsætte med at arbejde uden ændringer.

Introduktion til bibliotekskort

Helm 3 understøtter en klasse af diagrammer kaldet bibliotekskort (biblioteksoversigt). Dette diagram bruges af andre diagrammer, men opretter ingen udgivelsesartefakter alene. Biblioteksdiagramskabeloner kan kun erklære elementer define. Andet indhold ignoreres simpelthen. Dette giver brugerne mulighed for at genbruge og dele kodestykker, der kan bruges på tværs af flere diagrammer, og derved undgå duplikering og overholdelse af princippet TØR.

Bibliotekskort er deklareret i afsnittet dependencies i fil Chart.yaml. Installation og styring af dem adskiller sig ikke fra andre diagrammer.

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

Vi er begejstrede for de use cases, som denne komponent vil åbne for diagramudviklere, såvel som den bedste praksis, der kan fremkomme fra biblioteksdiagrammer.

Hvad er det næste?

Helm 3.0.0-alpha.1 er grundlaget, hvorpå vi begynder at bygge en ny version af Helm. I artiklen beskrev jeg nogle interessante træk ved Helm 3. Mange af dem er stadig i de tidlige udviklingsstadier, og det er normalt; Pointen med en alfa-udgivelse er at teste ideen, indsamle feedback fra tidlige brugere og bekræfte vores antagelser.

Så snart alfa-versionen er frigivet (husk at dette er allerede sket - ca. oversættelse), begynder vi at acceptere patches til Helm 3 fra fællesskabet. Du skal skabe et stærkt fundament, der gør det muligt at udvikle og implementere ny funktionalitet, og for at brugerne kan føle sig involveret i processen ved at åbne billetter og lave rettelser.

Jeg har forsøgt at fremhæve nogle af de store forbedringer, der kommer til Helm 3, men denne liste er på ingen måde udtømmende. Den fulde køreplan for Helm 3 inkluderer funktioner såsom forbedrede opdateringsstrategier, dybere integration med OCI-registre og brugen af JSON-skemaer til at validere diagramværdier. Vi planlægger også at rydde op i kodebasen og opdatere dele af den, som er blevet forsømt i de sidste tre år.

Hvis du føler, at vi er gået glip af noget, vil vi meget gerne høre dine tanker!

Deltag i diskussionen på vores Sløse kanaler:

#helm-users for spørgsmål og enkel kommunikation med samfundet;
#helm-dev at diskutere pull-anmodninger, kode og fejl.

Du kan også chatte i vores ugentlige offentlige udvikleropkald om torsdagen kl. 19:30 MSK. Møderne er dedikeret til at diskutere emner, som nøgleudviklere og fællesskabet arbejder på, såvel som ugens diskussionsemner. Alle kan være med og deltage i mødet. Link tilgængeligt i Slack kanal #helm-dev.

PS fra oversætteren

Læs også på vores blog:

Kilde: www.habr.com

Introduktion til Helm 3