🥇Innledning til Helm 3

Obs. overs.: 16. mai i år markerer en betydningsfull milepæl i utviklingen av pakkeadministratoren for Kubernetes – Helm. Denne dagen ble den første alpha-utgaven av den kommende større versjonen av prosjektet – 3.0 – presentert. Utgivelsen vil bringe betydelige og etterlengtede endringer til Helm, som mange i Kubernetes-samfunnet har store forventninger til. Vi er blant dem, siden vi aktivt bruker Helm for deploying av applikasjoner: vi har integrert den i vårt verktøy for implementering av CI/CD. werf og fra tid til annen bidrar vi til utviklingen av upstream. Denne oversettelsen samler 7 notater fra den offisielle bloggen til Helm, som er knyttet til den første alpha-utgaven av Helm 3 og forteller historien om prosjektet og de viktigste funksjonene i Helm 3. Forfatteren er Matt "bacongobbler" Fisher, ansatt i Microsoft og en av de sentrale vedlikeholderne av Helm.

15. oktober 2015 ble prosjektet, nå kjent som Helm, født. Bare ett år etter grunnleggelsen ble Helm-samfunnet med i Kubernetes, samtidig som de aktivt jobbet med Helm 2. I juni 2018 ble Helm en del av CNCF som et utviklende (incubating) prosjekt. La oss gå til nåtiden – og nå nærmer den første alpha-utgaven av nye Helm 3 seg. (denne utgivelsen fant allerede sted i midten av mai – overs. anm.).

I dette materialet vil jeg fortelle om hvordan alt begynte, hvordan vi kom hit, presentere noen unike funksjoner som er tilgjengelige i den første alpha-utgaven av Helm 3, og forklare hvordan vi planlegger å utvikle oss videre.

Sammendrag:

historien om opprettelsen av Helm;
et forsiktig farvel til Tiller;
chart-repositorier;
forvaltning av utgivelser;
endringer i chart-avhengigheter;
library charts;
hva nå?

Historien om opprettelsen av Helm

Fødselen

Helm 1 begynte som et åpen kildekode-prosjekt, skapt av firmaet Deis. Vi var et lite oppstartsselskap, som ble oppkjøpt av Microsoft våren 2017. Vårt andre åpne kildekode-prosjekt, også kalt Deis, hadde et verktøy deisctl, som ble brukt (blant annet) for å installere og drifte Deis-plattformen i Fleet-klyngen.På den tiden var Fleet en av de første plattformene for orkestrering av containere.

I midten av 2015 besluttet vi å endre kurs og migrere Deis (som da hadde fått navnet Deis Workflow) fra Fleet til Kubernetes. En av de første tingene som ble omarbeidet, var verktøyet for installasjon. deisctlVi brukte det til å installere og forvalte Deis Workflow i Fleet-klyngen.

Helm 1 ble utviklet med inspirasjon fra kjente pakkebehandlere som Homebrew, apt og yum. Hovedoppgaven var å forenkle oppgaver som pakking og installering av applikasjoner i Kubernetes. Helm ble offisielt lansert i 2015 under KubeCon-konferansen i San Francisco.

Vår første forsøk med Helm ga resultater, men det kom med betydelige begrensninger. Den tok en samling Kubernetes-manifester, beriket med generatorer som innledende YAML-blokker, (front-matter)*, og lastet resultatene inn i Kubernetes.

* Obs. overs.: Framsiden av Helm 1 valgte YAML-syntaks for å beskrive Kubernetes-ressurser, og ved konfigurasjonsskriving ble Jinja-maler og Python-skript støttet. Mer om dette og strukturen til Helm 1 generelt diskutert i kapitlet «Kort historie om Helm» dette materialet.

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

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

Det er fantastisk at vi i dag har malere, ikke sant?

Av mange grunner krevde denne tidlige Kubernetes-installasjonen en hardkodet liste med manifestfiler og utførte bare en liten fast sekvens av hendelser. Det var så vanskelig å bruke at R&D-teamet til Deis Workflow hadde det tøft når de forsøkte å portere produktet sitt til denne plattformen — men frøene til ideen var allerede sådd. Vår første forsøk ga en flott læringsmulighet: vi innså at vi virkelig er lidenskapelige for å lage pragmatiske verktøy som løser hverdagsproblemer for brukerne våre.

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

Utvikling av Helm 2

På slutten av 2015 kontaktet Googles team oss. De jobbet med et lignende verktøy for Kubernetes. Deployment Manager for Kubernetes var en portering av et eksisterende verktøy som ble brukt for Google Cloud Platform. «Vil vi bruke noen dager på å diskutere likhetene og forskjellene?» spurte de.

I januar 2016 møttes Helm- og Deployment Manager-teamene i Seattle for å dele ideer. Forhandlingene resulterte i en ambisiøs plan: å kombinere de to prosjektene for å lage Helm 2. Sammen med Deis og Google ble gutta fra SkippBox (nå en del av Bitnami — overs. anm.), og vi begynte arbeidet med Helm 2.

Vi ønsket å bevare brukervennligheten i Helm, men legge til følgende:

chart-maler for tilpasning;
intra-klyngeadministrasjon for team;
førsteklasses chart-repositorium;
et stabilt pakkeforum med signeringsmuligheter;
et solid engasjement for semantisk versjonering og opprettholdelse av bakoverkompatibilitet mellom versjoner.

For å oppnå disse målene ble et andre element lagt til Helm-økosystemet. Denne intra-klyngekomponenten ble kalt Tiller og hadde ansvar for installering og administrasjon av Helm-charts.

Siden lanseringen av Helm 2 i 2016 har Kubernetes fått flere betydelige nyvinninger. Det ble innført rollebasert tilgangskontroll (RBAC), som til slutt erstattet attributtbasert tilgangskontroll (ABAC). Nye ressurs typer ble introdusert (Deployments var fremdeles i beta-delen på den tiden). Det ble erfart om Custom Resource Definitions (opprinnelig kalt Third Party Resources eller TPRs). Og viktigst av alt — et sett med beste praksis ble utviklet.

I lys av alle disse endringene fortsatte Helm å være en pålitelig tjeneste for Kubernetes-brukere. Etter tre år og mange nye tillegg ble det klart at det var på tide med betydelige endringer i kodebasen for at Helm fortsatt skulle kunne oppfylle de voksende behovene til det utviklende økosystemet.

Et mildt farvel til Tiller

Under utviklingen av Helm 2 introduserte vi Tiller som en del av integrasjonen vår med Deployment Manager fra Google. Tiller spilte en viktig rolle for team som arbeidet i en delt klynge: det gjorde det mulig for ulike spesialister som drev infrastrukturen å samhandle med det samme settet av utgivelser.

Siden kontrollen for tilgang basert på roller (RBAC) ble aktivert som standard i Kubernetes 1.6, ble arbeidet med Tiller i produksjon mer komplisert. På grunn av det enorme antallet mulige sikkerhetspolitikk var vår posisjon å tilby en tillatelseskonfigurasjon som standard. Dette gjorde det mulig for nybegynnere å eksperimentere med Helm og Kubernetes uten å måtte gå inn i sikkerhetsinnstillingene først. Dessverre kunne denne tillatelseskonfigurasjonen gi brukeren for mye tilgang de ikke trengte. DevOps- og SRE-ingeniører måtte lære seg ekstra driftstrinn når de installerte Tiller i en flerbruker-klynge.

Da vi lærte hvordan medlemmer av fellesskapet bruker Helm i spesifikke situasjoner, innså vi at systemet for håndtering av utgivelser, Tiller, ikke trengte å stole på en intern klyngekomponent for å opprettholde tilstander eller fungere som et sentralt knutepunkt med informasjon om utgivelser. I stedet kunne vi bare hente informasjon fra Kubernetes API-server, generere chart på klientsiden og lagre installasjonsoppføring i Kubernetes.

Den primære oppgaven til Tiller kunne også utføres uten Tiller, så en av våre første beslutninger angående Helm 3 var å fullstendig fjerne Tiller.

Med fjerningen av Tiller har Helm sin sikkerhetsmodell blitt radikalt forenklet. Helm 3 støtter nå alle moderne metoder for sikkerhet, identifikasjon og autorisasjon i dagens Kubernetes. Tillatelser i Helm bestemmes ved hjelp av kubeconfig-filen.Klyngens administratorer kan begrense brukernes rettigheter med hvilken som helst grad av detaljer. Utgivelser lagres fortsatt inne i klyngen, og resten av Helm-funksjonaliteten er bevart.

Chart-repositorier

På et høyt nivå er et chart-repository et sted for lagring og deling av charts. Helm-klienten pakker og sender charts til repositoriet. Enkelt sagt, et chart-repository er en primitiv HTTP-server med en index.yaml-fil og noen pakket charts.

Selv om det er noen fordeler med at API-et til chart-repositoriet møter de mest grunnleggende kravene til lagring, har det også noen ulemper:

Chart-repositorier er dårlig kompatible med de fleste sikkerhetsimplementasjoner som er nødvendige i produksjonsmiljøer. Tilstedeværelsen av et standard API for autentisering og autorisasjon er avgjørende i produksjonsscenarier.
Helm-verktøyene for sporing av opprinnelse av charts, brukt for signering, integritetskontroll og opprinnelse av charts, er en valgfri del av Chart-publiseringsprosessen.
I flerbrukerscenarier kan det samme chart lastes opp av en annen bruker, noe som dobler plassen som kreves for lagring av det samme innholdet. For å løse dette problemet har smartere repositorier blitt utviklet, men de er ikke en del av den formelle spesifikasjonen.
Bruken av en enkelt indeksfil for å søke, lagre metadata og hente charts har komplisert utviklingen av sikre flerbruksimplementasjoner.

Prosjekt Docker Distribution (også kjent som Docker Registry v2) er etterfølgeren til Docker Registry og fungerer faktisk som et verktøysett for å pakke, sende, lagre og distribuere Docker-bilder. Mange store skytjenester tilbyr produkter basert på Distribution. Takket være denne økte oppmerksomheten har Distribution-prosjektet dratt nytte av mange års forbedringer, beste praksis innen sikkerhet og testing i "kamp"-miljøer, noe som har gjort det til en av de mest suksessrike usungne heltene i Open Source-verdenen.

Men visste du at Distribution-prosjektet ble utviklet for å distribuere enhver form for innhold, ikke bare containere?

Takket være innsatsen til Open Container Initiative (eller OCI) kan Helm-charts plasseres på enhver instans av Distribution. Så langt er denne prosessen eksperimentell. Arbeidet med å støtte pålogging og andre funksjoner som er nødvendig for en fullverdig Helm 3, er fortsatt ikke avsluttet, men vi er veldig glade for muligheten til å lære av oppdagelsene gjort av OCI- og Distribution-teamene i årenes løp. Og takket være deres veiledning lærer vi hva det vil si å drifte en høyt tilgjengelig tjeneste i stor skala.

En mer detaljert beskrivelse av noen kommende endringer i Helm-chart-repositoriene er tilgjengelig via lenken.

Utgivelsesadministrasjon

I Helm 3 spores applikasjonsstatus innen klyngen av et par objekter:

release object — representerer en instans av applikasjonen;
release version secret — representerer ønsket tilstand av applikasjonen på et bestemt tidspunkt (for eksempel utgivelsen av en ny versjon).

Kall helm install oppretter release object og release version secret. Kall helm upgrade krever eksistensen av release object (som den kan endre) og oppretter en ny release version secret som inneholder nye verdier og en forberedt manifest.

Release object inneholder informasjon om utgivelsen, hvor utgivelsen er en spesifikk installasjon av en navngitt chart og verdier. Dette objektet beskriver metadata på toppnivå om utgivelsen. Release object beholdes gjennom hele livssyklusen til applikasjonen og fungerer som eier av alle release version secret’er, samt alle objekter som direkte opprettes av Helm-chartet.

Release version secret binder utgivelsen til en serie revisjoner (installasjon, oppdateringer, tilbaketrekning, sletting).

I Helm 2 var revisjoner utelukkende sekvensielle. Kall helm install opprettet v1, etterfølgende oppdatering (upgrade) — v2, og så videre. Release og release version secret ble slått sammen til ett enkelt objekt kjent som revisjon. Revisjoner ble lagret i det samme navnerommet som Tiller, noe som betydde at hver utgivelse var "global" med hensyn til navnerom; som et resultat kunne det bare brukes én instans av navnet.

I Helm 3 er hver utgivelse knyttet til en eller flere release version secret’er. Release object beskriver alltid den gjeldende utgivelsen, distribuerte i Kubernetes. Hver release version secret beskriver bare én versjon av denne utgivelsen. En oppdatering (upgrade) vil for eksempel opprette en ny release version secret og deretter endre release object slik at det peker på denne nye versjonen. Ved tilbaketrekning (rollback) kan tidligere release version secret’er brukes til å rulle utgivelsen tilbake til en tidligere tilstand.

Etter avviklingen av Tiller lagrer Helm 3 utgivelsesdataene i det samme navnerommet som utgivelsen. Denne endringen tillater installasjon av en chart med samme utgivelsesnavn i et annet navnerom, og dataene beholdes mellom oppdateringer/restarts av klyngen i etcd. For eksempel kan WordPress installeres i navnerommet "foo", og deretter i navnerommet "bar", og begge utgivelsene kan hete "wordpress".

Endringer i chart-avhengigheter

Charts pakket (ved hjelp av helm package) for use with Helm 2, it can be installed with Helm 3, however, the chart development workflow has been completely revised, so some adjustments are necessary to continue chart development with Helm 3. In particular, the chart dependency management system has changed.

The chart dependency management system has transitioned from requirements.yaml og requirements.lock En funksjon har blitt Chart.yaml og Chart.lock. This means that the charts that used the command helm dependency, require some configuration to work in Helm 3.

Let's look at an example. We'll add a dependency to a chart in Helm 2 and see what changes when transitioning to Helm 3.

In Helm 2 requirements.yaml it looked like this:

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

In Helm 3, the same dependency will be reflected in your Chart.yaml:

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

Charts are still loaded and placed in the directory charts/, so the subcharts (subcharts), located in the directory charts/, will continue to work unchanged.

Introducing Library Charts

Helm 3 supports a class of charts called library charts (library chart). This chart is used by other charts but does not create any release artifacts on its own. Library chart templates can only declare elements define. Any other content is simply ignored. This allows users to reuse and share code snippets that can be utilized across many charts, thereby avoiding duplication and adhering to the principle of DRY.

Library charts are declared in the section avhengigheter in the file Chart.yaml. Installing and managing them is not different from other charts.

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

We eagerly anticipate the use cases that this component will unlock for chart developers, as well as the best practices that may arise thanks to library charts.

Hva skjer videre?

Helm 3.0.0-alpha.1 is the foundation upon which we begin to build a new version of Helm. In this article, I've outlined some interesting features of Helm 3. Many of them are still in the early stages of development, and that's okay; the essence of an alpha release is to test the idea, gather feedback from early users, and validate our assumptions.

Once the alpha version is released (let's remember that this has already happened – obs. overs.), vi begynner å akseptere patches for Helm 3 fra fellesskapet. Det er nødvendig å skape et solid grunnlag som tillater utvikling og aksept av nye funksjoner, samtidig som brukerne kan føle seg involvert i prosessen ved å åpne billetter og bidra med rettelser.

I artikkelen har jeg forsøkt å belyse noen betydelige forbedringer som vil komme i Helm 3, men denne listen kan absolutt ikke kalles uttømmende. Den omfattende planen for Helm 3 inkluderer nyvinninger som forbedrede oppdateringsstrategier, dypere integrasjon med OCI-registere og bruk av JSON-skjemaer for validering av chart-verdier. Vi planlegger også å rydde opp i kodebasen og oppdatere de delene som har vært neglisjert de siste tre årene.

Hvis du mener vi har oversett noe, vil vi gjerne høre tankene dine!

Bli med i diskusjonen i våre Slack-kanaler:

#helm-users for spørsmål og generell kommunikasjon med fellesskapet;
#helm-dev for diskusjon av pull requests, kode og feil.

Du kan også chatte i våre ukentlige Public Developer Calls på torsdager kl 19:30 MSK. Møtene er viet til diskusjon av oppgaver som nøkkelutviklere og fellesskapet jobber med, samt ukens diskusjonstemaer. Alle er velkomne til å delta på møtet. Lenken er tilgjengelig i Slack-kanalen #helm-dev.