🥇Introduktion til Helm 3

Bem. overs.: 16. maj i år markerede en vigtig milepæl i udviklingen af pakkemanageren til Kubernetes — Helm. På denne dag blev den første alfa-version af det kommende store projekt — 3.0 præsenteret. Dens udgivelse vil medføre betydelige og længe ventede ændringer i Helm, som mange i Kubernetes-fællesskabet sætter store forhåbninger til. Det inkluderer også os, da vi aktivt bruger Helm til deployment af applikationer: vi har integreret det i vores værktøj til implementering af CI/CD. werf Og fra tid til anden bidrager vi til udviklingen af upstream. Denne oversættelse samler 7 bemærkninger fra Helm's officielle blog, der er knyttet til den første alfa-udgivelse af Helm 3 og fortæller om projektets historie og de vigtigste funktioner i Helm 3. Forfatteren er Matt «bacongobbler» Fisher, medarbejder hos Microsoft og en af de centrale vedligeholdere af Helm.

15. oktober 2015 blev projektet, nu kendt som Helm, født. Kun et år efter grundlæggelsen sluttede Helm-fællesskabet sig til Kubernetes og arbejdede aktivt på Helm 2. I juni 2018 blev Helm en del af CNCF som et inkuberingsprojekt. Lad os hoppe til nutiden — og her nærmer den første alfa-udgivelse af den nye Helm 3 sig (denne udgivelse har allerede fundet sted i midten af maj — note fra oversætteren).

I dette materiale vil jeg fortælle om, hvordan det hele startede, hvordan vi nåede til den nuværende fase, præsentere nogle unikke funktioner, der er tilgængelige i den første alfa-udgivelse af Helm 3, og forklare, hvordan vi planlægger at udvikle os videre.

Resumé:

historien om Helm;
det blide farvel til Tiller;
repositoryer af charts;
administration af udgivelser;
ændringer i charts-afhængigheder;
library charts;
hvad nu?

Historien om Helm

Fødslen

Helm 1 startede som et Open Source-projekt skabt af Deis. Vi var en lille startup, der blev overtaget af Microsoft i foråret 2017. Vores andet Open Source-projekt, som også hed Deis, havde et værktøj deisctl, der blev brugt (blandt andet) til installation og drift af Deis-platformen i Fleet-klusteret.På det tidspunkt var Fleet en af de første platforme til orkestrering af containere.

I midten af 2015 besluttede vi at ændre kurs og flyttede Deis (som på det tidspunkt var omdøbt til Deis Workflow) fra Fleet til Kubernetes. Et af de første værktøjer, der blev revideret, deisctl. Vi brugte det til installation og administration af Deis Workflow i Fleet-klusteret.

Helm 1 blev skabt efter forbillederne fra kendte pakkemanager såsom Homebrew, apt og yum. Dets primære formål var at forenkle opgaver som pakning og installation af applikationer i Kubernetes. Helm blev officielt præsenteret i 2015 på KubeCon-konferencen i San Francisco.

Vores første forsøg med Helm lykkedes, men der var alvorlige begrænsninger. Det tog et sæt Kubernetes-manifester, tilsat generatorer som input YAML-blokke. (front-matter)*, og indlæste resultaterne i Kubernetes.

* Bem. overs.: Fra den første version af Helm blev YAML-syntax valgt til at beskrive Kubernetes-ressourcer, og når der blev skrevet konfigurationer, blev Jinja-skabeloner og Python-scripts understøttet. Mere om dette og strukturen i den første version af Helm generelt skrev vi i kapitlet "Kort historie om Helm" dette materiale.

For eksempel, for at erstatte et felt i YAML-filen, skulle man tilføje følgende konstruktion i manifestet:

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

Det er fantastisk, at der i dag findes skabelonværktøjer, ikke sandt?

Af mange grunde krævede denne tidlige Kubernetes-installationsprogram en hårdkodet liste over manifestfiler og udførte kun en lille fast sekvens af begivenheder. Det var så besværligt at bruge, at R&D-teamet i Deis Workflow havde det svært, da de forsøgte at flytte deres produkt til denne platform — dog var frøene til idéen allerede blevet sået. Vores første forsøg blev en fremragende mulighed for læring: vi indså, at vi virkelig brændte for at skabe pragmatiske værktøjer, der løser dagligdags problemer for vores brugere.

Med erfaring fra tidligere fejl indledte vi udviklingen af Helm 2.

Skabelsen af Helm 2

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

I januar 2016 mødtes Helm- og Deployment Manager-teamsne i Seattle for at udveksle idéer. Forhandlingerne resulterede i en ambitiøs plan: at kombinere begge projekter for at skabe Helm 2. Sammen med Deis og Google kom drengene fra SkippBox (som nu er en del af Bitnami — red.), og vi begyndte at arbejde på Helm 2.

Vi ønskede at bevare brugervenligheden af Helm, men tilføje følgende:

skabeloner til tilpasning af charts;
intern klyngeadministration for teams;
førsteklasses chart-repositorium;
et stabilt pakkeformat med mulighed for signering;
en fast forpligtelse til semantisk versionering og at bevare bagudkompatibilitet mellem versioner.

For at opnå disse mål blev der tilføjet et andet element til Helm-økosystemet. Denne interne komponent blev kaldt Tiller og håndterede installation og administration af Helm-charts.

Siden lanceringen af Helm 2 i 2016 har Kubernetes fået flere væsentlige nyheder. Der er kommet rollebaseret adgangskontrol (RBAC), som til sidst erstattede attributbaseret adgangskontrol (ABAC). Nye ressourcetyper blev introduceret (Deployments var stadig i beta på det tidspunkt). Der blev opfundet Custom Resource Definitions (oprindeligt kaldet Third Party Resources eller TPRs). Og vigtigst af alt - et sæt bedste praksisser blev etableret.

På baggrund af alle disse ændringer fortsatte Helm med at tjene Kubernetes-brugerne trofast. Efter tre år og mange nye tilføjelser blev det klart, at det var på tide at foretage betydelige ændringer i kodebasen, så Helm kunne fortsætte med at imødekomme de voksende behov i den udviklende økosystem.

En blid 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: han gjorde det muligt for forskellige specialister, der drev infrastrukturen, at interagere med det samme sæt af udgivelser.

Da kontrol med rollebased adgang (RBAC) blev aktivert som standard i Kubernetes 1.6, blev det sværere at arbejde med Tiller i produktion. På grund af det enorme antal mulige sikkerhedspolitikker var vores holdning, at vi som standard skulle tilbyde en tilladende konfiguration. 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 tilladende konfiguration give brugeren et for bredt spektrum af tilladelser, de ikke havde brug for. DevOps- og SRE-ingeniører var nødt til at lære yderligere driftstrin for at installere Tiller i en multi-tenant klynge.

Ved at lære, hvordan medlemmer af samfundet bruger Helm i specifikke situationer, indså vi, at Tiller's udgivelsesstyringssystem ikke behøver at stole på et intra-klyngekomponent for at opretholde tilstande eller fungere som et centralt hub for udgivelsesinformation. I stedet kunne vi blot hente information fra Kubernetes API-serveren, generere chartet på klientsiden og gemme installationsdatabasen i Kubernetes.

Hovedopgaven for Tiller kunne også udføres uden Tiller, så en af de første beslutninger, vi tog i forhold til Helm 3, var det fuldstændige fravær af Tiller.

Med Tiller's afgang er Helm's sikkerhedsmodel blevet radikalt forenklet. Helm 3 understøtter nu alle moderne metoder til sikkerhed, identifikation og autorisation i den nuværende Kubernetes. Helm-tilladelser defineres ved hjælp af kubeconfig-filen. Klyngeadministratorer kan begrænse brugerrettigheder med enhver grad af detalje. Udgivelser gemmes stadig inden for klyngen, og resten af Helm's funktionalitet bevares.

Chart-repositorier

På et højt niveau er chart-repositoriet et sted at gemme og dele charts. Helm-klienten pakker og sender charts til repositoriet. Kort sagt er chart-repositoriet en primitiv HTTP-server med en index.yaml-fil og nogle pakkerede charts.

Selvom der er nogle fordele ved, at chart-repositoriets API opfylder de grundlæggende krav til lager, har det også nogle ulemper:

Chart-repositorier er dårligt kompatible med de fleste sikkerhedsløsninger, der er nødvendige i produktionsmiljøer. En standard API til autentificering og autorisation er yderst vigtig i produktionsscenarier.
Helm-værktøjer til at spore oprindelsen af charts, der bruges til signering, integritetskontrol og oprindelsesanalyse, er en valgfri del af publiceringsprocessen af et chart.
I multi-bruger scenarier kan det samme chart blive uploadet af en anden bruger, hvilket fordobler den nødvendige lagerplads til det samme indhold. For at løse dette problem er der blevet udviklet smartere repositories, men de er ikke en del af den officielle specifikation.
Brugen af en enkelt indeksfil til at finde, opbevare metadata og hente charts har kompliceret udviklingen af sikre multi-bruger implementeringer.

Projekt Docker Distribution (også kendt som Docker Registry v2) er efterfølgeren til Docker Registry og repræsenterer i virkeligheden et værktøjssæt til pakning, overførsel, opbevaring og levering af Docker-images. Mange store cloud-tjenester tilbyder produkter baseret på Distribution. Denne ekstra opmærksomhed har givet projektet Distribution fordel af mange års forbedringer, bedste sikkerhedspraksis og test i 'kamp'-miljøer, hvilket har gjort det til en af de mest succesrige, oversete helte i Open Source-verdenen.

Men vidste du, at Distribution-projektet blev udviklet til distribution af enhver form for indhold, ikke kun containerimages?

Takket være indsatsen fra Open Container Initiative (eller OCI) kan Helm-charts placeres på enhver Distribution-instans. Mens denne proces stadig er eksperimentel. Arbejdet med at understøtte login og andre funktioner, der er nødvendige for fuld Helm 3, er endnu ikke afsluttet, men vi er meget glade for muligheden for at lære af de opdagelser, som OCI- og Distribution-teams har gjort gennem årene. Takket være deres vejledning og mentoring lærer vi, hvad det kræver at drive en højt tilgængelig service i stor skala.

En mere detaljeret beskrivelse af nogle kommende ændringer i Helm-chart-repositories er tilgængelig via linket.

Udgivelseshåndtering

I Helm 3 spores applikationens tilstand inden for klyngen af et par objekter:

release object — repræsenterer en instans af applikationen;
release version secret — repræsenterer den ønskede tilstand af applikationen på et bestemt tidspunkt (for eksempel udgivelse af en ny version).

Kald helm install opretter release object og release version secret. Kaldet helm upgrade kræver tilstedeværelsen af release object (som det kan ændre) og opretter en ny release version secret, der indeholder nye værdier og det forberedte manifest.

Release object indeholder information om udgivelsen, hvor udgivelsen er en specifik installation af det navngivne chart og værdier. Dette objekt beskriver metadata på højt niveau om udgivelsen. Release object opbevares gennem hele applikationens livscyklus og fungerer som ejer af alle release version secrets samt alle objekter, der direkte oprettes af Helm-chartet.

Release version secret forbinder udgivelsen med en serie revisioner (installation, opdateringer, tilbagesendelse, sletning).

I Helm 2 var revisioner udelukkende sekventielle. Kaldet helm install oprettede v1, efterfølgende opdatering (upgrade) — v2, og så videre. Release og release version secret blev slået sammen til et enkelt objekt, kendt som revision. Revisioner blev opbevaret i samme namespace som Tiller, hvilket betød, at hver udgivelse var 'global' med hensyn til namespace; som følge heraf kunne der kun anvendes én instans af navnet.

I Helm 3 er hver udgivelse knyttet til en eller flere release version secrets. Release object beskriver altid den aktuelle udgivelse, der er implementeret i Kubernetes. Hver release version secret beskriver kun én version af denne udgivelse. En opdatering (upgrade) vil for eksempel skabe en ny release version secret og derefter ændre release object, så det peger på denne nye version. Ved tilbagesendelse (rollback) kan tidligere release version secrets bruges til at gendanne udgivelsen til en tidligere tilstand.

Efter afskaffelsen af Tiller opbevarer Helm 3 data om udgivelsen i et enkelt namespace sammen med udgivelsen. En sådan ændring gør det muligt at installere et chart med samme udgivelsesnavn i et andet namespace, og dataene bevares mellem opdateringer/genstart af klyngen i etcd. For eksempel kan WordPress installeres i namespace 'foo', og derefter i namespace 'bar', og begge udgivelser kan kaldes 'wordpress'.

Ændringer i chart-afhængigheder

Charts, der er pakket (ved hjælp af helm package) til brug med Helm 2 kan installeres med Helm 3. Men udviklingsarbejdsprocessen for charts er blevet fuldstændig revideret, så der skal foretages nogle ændringer for fortsat at kunne udvikle charts med Helm 3. Især er systemet til håndtering af chartafhængigheder ændret.

Systemet til håndtering af afhængigheder for charts er gået fra requirements.yaml og requirements.lock og få en fungerende kommando. Chart.yaml og Chart.lock. Dette betyder, at charts, der brugte kommandoen helm dependency, kræver nogle tilpasninger for at fungere i Helm 3.

Lad os tage et eksempel. Vi tilføjer en afhængighed til et chart i Helm 2 og ser, hvad der ændres ved overgangen til Helm 3.

I Helm 2 requirements.yaml sådan 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 afspejles i dit Chart.yaml:

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

Charts indlæses stadig og placeres i mappen charts/, så subcharts (subcharts), der ligger i kataloget charts/, vil fortsætte med at fungere uden ændringer.

Præsenterer Library Charts

Helm 3 understøtter en klasse charts, der kaldes library charts (library chart).Dette chart bruges af andre charts, men skaber ikke selv nogen udgivelsesartefakter. Skabeloner for library charts kan kun erklære elementer define. Andet indhold ignoreres simpelthen. Dette gør det muligt for brugerne at genbruge og dele kodefragmenter, som kan anvendes på tværs af mange charts og dermed undgå duplikering og følge princippet DRY.

Library charts erklæres i sektionen dependencies i filen Chart.yaml. Installation og håndtering af dem adskiller sig ikke fra andre charts.

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

Vi ser frem til de anvendelsesmuligheder, som denne komponent åbner for chartudviklere, samt de bedste praksisser, der kan opstå takket være library charts.

Hvad nu?

Helm 3.0.0-alpha.1 er grundlaget, som vi begynder at bygge den nye version af Helm på. I denne artikel har jeg beskrevet nogle interessante funktioner i Helm 3. Mange af dem er stadig i de tidlige udviklingsstadier, og det er okay; essensen af en alpha-udgivelse er at teste idéen, samle feedback fra de første brugere og bekræfte vores antagelser.

Når alpha-versionen er frigivet (lad os minde om, at dette allerede er sket — red. anm.), vi vil begynde at modtage patches til Helm 3 fra fællesskabet. Det er nødvendigt at skabe et solidt fundament, der muliggør udvikling og modtagelse af nye funktionaliteter, og brugerne vil kunne føle sig involveret i processen ved at åbne tickets og indsende rettelser.

I artiklen har jeg forsøgt at belyse nogle væsentlige forbedringer, der vil blive tilgængelige i Helm 3, men denne liste kan på ingen måde betragtes som udtømmende. Den omfattende plan for Helm 3 inkluderer nyheder som forbedrede opgraderingsstrategier, dybere integration med OCI-repositorier og brug af JSON-skemaer til validering af chartværdier. Vi planlægger også at rydde op i kodebasen og opdatere de dele, der har været ignoreret i de sidste tre år.

Hvis du føler, at vi har overset noget, vil vi gerne høre dine tanker!

Deltag i diskussionen i vores Slack-kanaler:

#helm-users til spørgsmål og almindelig kommunikation med fællesskabet;
#helm-dev til diskussion af pull requests, kode og bugs.

Du kan også deltage i vores ugentlige Public Developer Calls hver torsdag kl. 19:30 MSK. Møderne er dedikeret til diskussion af opgaver, som de centrale udviklere og fællesskabet arbejder på, samt ugens diskussionsemner. Alle er velkomne til at deltage i mødet. Linket er tilgængeligt i Slack-kanalen #helm-dev.

P.S. fra oversætteren

Læs også på vores blog:

Kilde: habr.com