🥇Introduktion till Helm 3

Obs. övers.: Den 16 maj i år markerar en betydande milstolpe i utvecklingen av paketchefer för Kubernetes - Helm. På denna dag presenterades den första alfa-versionen av det kommande stora projektet - 3.0. Utgivningen kommer att medföra betydande och efterlängtade förändringar i Helm, som många inom Kubernetes-gemenskapen har stora förhoppningar på. Vi själva räknas till dessa, eftersom vi aktivt använder Helm för distribution av applikationer: vi har integrerat det i vårt verktyg för att genomföra CI/CD. werf och från fall till fall bidrar vi med vårt strå till stacken i utvecklingen av upstream. Denna översättning sammanfattar 7 anteckningar från Helm's officiella blogg, som är kopplade till den första alfa-versionen av Helm 3 och berättar om projektets historia och de viktigaste funktionerna i Helm 3. Författaren är Matt "bacongobbler" Fisher, anställd på Microsoft och en av de centrala underhållarna av Helm.

Den 15 oktober 2015 föddes projektet som idag är känt som Helm. Bara ett år efter grundandet gick Helm-gemenskapen med i Kubernetes och arbetade aktivt med Helm 2. I juni 2018 blev Helm en del av CNCF som ett utvecklande (incubating) projekt. Låt oss hoppa till nutiden – och nu är den första alfa-versionen av nya Helm 3 på väg. (denna version har redan släppts i mitten av maj – red. anm.).

I detta material kommer jag att berätta om hur allt började, hur vi kom till den nuvarande fasen, presentera några unika funktioner som är tillgängliga i den första alfa-versionen av Helm 3, och förklara hur vi planerar att utvecklas vidare.

Sammanfattning:

historien om skapandet av Helm;
ett ömt avsked till Tiller;
chart-repositorier;
hantering av utgåvor;
ändringar i chart-beroenden;
bibliotekscharts;
vad gör du sedan?

Historien om skapandet av Helm

Födslen

Helm 1 började som ett Open Source-projekt, skapat av företaget Deis. Vi var en liten startup, uppköpt av Microsoft våren 2017. Vårt andra Open Source-projekt, också kallat Deis, hade ett verktyg deisctl, som användes (bland annat) för att installera och driva plattformen Deis i Fleet-klustret.. Vid den tiden var Fleet en av de första plattformarna för orkestrering av containrar.

I mitten av 2015 beslutade vi att byta kurs och flyttade Deis (vid den tiden omdöpt till Deis Workflow) från Fleet till Kubernetes. Som en av de första omarbetades installationsverktyget, deisctl. Vi använde det för installation och hantering av Deis Workflow i Fleet-klustret.

Helm 1 skapades med inspiration från kända paketförvaltare som Homebrew, apt och yum. Dess huvudsyfte var att förenkla uppgifter som paketering och installation av applikationer i Kubernetes. Helm presenterades officiellt 2015 på KubeCon-konferensen i San Francisco.

Vårt första försök med Helm fungerade, men det var inte utan allvarliga begränsningar. Det tog en uppsättning Kubernetes-manifest som kryddades av generatorer som indata YAML-block. (front-matter)*, och laddade resultaten till Kubernetes.

* Obs. övers.: Från och med den första versionen av Helm valdes YAML-syntax för att beskriva Kubernetes-resurser, och vid skrivning av konfigurationer stödde man Jinja-mallar och Python-skript. Mer om detta och hur den första versionen av Helm fungerade skrev vi i kapitlet "En kort historia om Helm" detta material.

Till exempel, för att ersätta ett fält i YAML-filen behövde man lägga till följande konstruktion i manifestet:

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

Det är fantastiskt att det idag finns mallmakare, eller hur?

Av många skäl krävde denna tidiga Kubernetes-installatör en fast lista med manifestfiler och utförde endast en liten fast sekvens av händelser. Att använda den var så svårt att Deis Workflows FoU-team hade det tufft när de försökte migrera sin produkt till denna plattform — men idéerna hade redan såtts. Vårt första försök blev en utmärkt möjlighet för lärande: vi insåg att vi verkligen brinner för att skapa pragmatiska verktyg som löser vardagliga problem för våra användare.

Med erfarenheten av tidigare misstag började vi utveckla Helm 2.

Skapandet av Helm 2

I slutet av 2015 kontaktade Google-teamet oss. De arbetade med ett liknande verktyg för Kubernetes. Deployment Manager för Kubernetes var en portering av ett befintligt verktyg som användes för Google Cloud Platform. "Vill vi inte," frågade de, "slösa några dagar på att diskutera likheterna och skillnaderna?"

I januari 2016 träffades teamen för Helm och Deployment Manager i Seattle för att utbyta idéer. Förhandlingarna avslutades med en ambitiös plan: att kombinera båda projekten för att skapa Helm 2. Tillsammans med Deis och Google anslöt sig killarna från SkippBox (numera en del av Bitnami — anm. övers.), och vi började arbetet med Helm 2.

Vi ville behålla enkelheten i Helm, men lägga till följande:

mallar för anpassning av diagram;
intra-cluster administration för team;
förstklassigt diagramarkiv;
stabilt paketformat med signeringsmöjlighet;
ett fast åtagande till semantisk versionering och bevarande av bakåtkompatibilitet mellan versioner.

För att uppnå dessa mål lades en andra komponent till Helm-ekosystemet. Denna intra-cluster komponent kallades Tiller och hanterade installation och administration av Helm-diagram.

Sedan Helm 2 lanserades 2016 har Kubernetes fått flera betydande nyheter. Rollen baserad åtkomstkontroll (RBAC), som slutligen ersatte attributbaserad åtkomstkontroll (ABAC). Nya typer av resurser presenterades (Deployments var fortfarande i beta-status). Custom Resource Definitions uppfanns (ursprungligen kallades de Third Party Resources eller TPRs). Och viktigast av allt – en uppsättning bästa praxis introducerades.

Mot bakgrund av alla dessa förändringar fortsatte Helm att tjäna Kubernetes-användare troget. Efter tre år och många nya tillägg blev det tydligt att det var dags att göra betydande förändringar i kodbasen så att Helm fortsatt kunde möta de växande behoven hos den utvecklande ekosystemet.

Ett ömt avsked från Tiller

Under utvecklingen av Helm 2 introducerade vi Tiller som en del av vår integration med Google's Deployment Manager. Tiller spelade en viktig roll för team som arbetade inom en delad kluster: den tillät olika specialister som driftsatte infrastrukturen att interagera med samma uppsättning releaser.

Eftersom rollbaserad åtkomstkontroll (RBAC) var aktiverad som standard i Kubernetes 1.6, blev det svårare att arbeta med Tiller i produktion. På grund av det stora antalet möjliga säkerhetspolicyer var vår position att erbjuda en tillåtande konfiguration som standard. Detta gjorde det möjligt för nykomlingar att experimentera med Helm och Kubernetes utan att först behöva dyka ner i säkerhetsinställningarna. Tyvärr kunde denna tillåtande konfiguration ge användaren ett för stort spann av behörigheter som de inte behövde. DevOps- och SRE-ingenjörer måste lära sig ytterligare driftsättningssteg när de installerade Tiller i en flermedarbetarkluster.

Genom att lära oss hur communityrepresentanter använder Helm i specifika situationer insåg vi att Tiller-releasesystemet inte behövde förlita sig på en inre klusterkomponent för att upprätthålla tillstånd eller fungera som en central hubb för releaseinformation. Istället skulle vi kunna få information direkt från Kubernetes API-server, generera chart på klientsidan och spara installationsposten i Kubernetes.

Tiller’s huvuduppgift kunde genomföras utan Tiller, så en av våra första lösningar beträffande Helm 3 var att helt avskaffa Tiller.

Med Tiller borta har Helm:s säkerhetsmodell radikalt förenklats. Helm 3 stöder nu alla moderna metoder för säkerhet, autentisering och auktorisering inom den nuvarande Kubernetes. Helm-behörigheter definieras med hjälp av kubeconfig-filen. Klusteradministratörer kan begränsa användarbehörigheter med valfri detaljgrad. Releases lagras fortfarande inom klustret, och Helm:s övriga funktionalitet bevaras.

Chartrepositorier

På en övergripande nivå är ett chartrepository en plats där man kan lagra och dela charts. Helm-klienten paketerar och skickar charts till repositoryt. Enkelt uttryckt är ett chartrepository en primitiv HTTP-server med en index.yaml-fil och några paketerade charts.

Även om det finns vissa fördelar med att chartrepositoryts API uppfyller de mest grundläggande kraven på lagring, finns det också några nackdelar:

Chart-repositorier är dåligt kompatibla med de flesta säkerhetsimplementeringar som krävs i produktionsmiljöer. Att ha ett standard-API för autentisering och auktorisering är avgörande i produktionsscenarier.
Helm-verktygen för att spåra ursprunget till chartet, som används för signering, integritetskontroll och ursprung av chartet, är en valfri del av publiceringsprocessen för chartet.
I fleranvändarscenarier kan samma chart laddas upp av en annan användare, vilket fördubblar lagringsutrymmet som krävs för samma innehåll. För att hantera detta problem har smartare repository-lösningar utvecklats, men de är inte en del av den formella specifikationen.
Användningen av en enda indexfil för att söka, lagra metadata och hämta charts har försvårat utvecklingen av säkra fleranvändartillämpningar.

Projektet Docker Distribution (även känd som Docker Registry v2) är efterträdaren till Docker Registry och fungerar faktiskt som en uppsättning verktyg för att paketera, skicka, lagra och leverera Docker-bilder. Många stora molntjänster erbjuder produkter baserade på Distribution. På grund av en ökad uppmärksamhet har projektet Distribution gynnats av flera års förbättringar, bästa säkerhetspraxis och tester i 'skarp' miljö, vilket har gjort det till en av de mest framgångsrika osjungna hjältarna inom Open Source.

Men visste du att projektet Distribution utvecklades för att distribuera alla former av innehåll, inte bara containerbilder?

Tack vare ansträngningarna Open Container Initiative (eller OCI), kan Helm-charts placeras på vilken Distribution-instans som helst. Även om denna process fortfarande är experimentell. Arbetet med att stödja inloggningar och andra funktioner som krävs för att Helm 3 ska fungera ordentligt är fortfarande inte avslutat, men vi är mycket glada över att kunna lära oss av de insikter som OCI och Distribution-team har gjort under åren. Med deras mentorskap och vägledning lär vi oss hur man driver en högav tillgänglig tjänst i stor skala.

En mer detaljerad beskrivning av några kommande förändringar i Helm-charts repositoryn finns tillgänglig. via länken.

Releasehantering

I Helm 3 spåras applikationens tillstånd inom kluster av ett par objekt:

release object — representerar en instans av applikationen;
release version secret — representerar det önskade tillståndet av applikationen vid en specifik tidpunkt (t.ex. lansering av en ny version).

Anrop helm install skapar release object och release version secret. Anropet helm upgrade kräver att det finns ett release object (som det kan ändra) och skapar en ny release version secret som innehåller nya värden och en förberedd manifest.

Release object innehåller information om releasen, där releasen är en specifik installation av det namngivna chartet och dess värden. Detta objekt beskriver metadatainformation på hög nivå om releasen. Release object sparas under hela applikationens livscykel och fungerar som ägare av alla release version secrets samt alla objekt som direkt skapas av Helm-charten.

Release version secret kopplar releasen till en serie revisioner (installationer, uppdateringar, återställningar, borttagningar).

I Helm 2 var revisioner helt och hållet sekventiella. Anropet helm install skapade v1, nästa uppdatering (upgrade) — v2, och så vidare. Release och release version secret sammanfogades till ett enda objekt, känt som revision. Revisioner sparades i samma namnrymd som Tiller, vilket innebar att varje release var "global" i termer av namnrymd; följaktligen kunde endast en instans av namnet användas.

I Helm 3 är varje release kopplad till en eller flera release version secrets. Release object beskriver alltid den aktuella releasen som är distribuerad i Kubernetes. Varje release version secret beskriver endast en version av denna release. En uppdatering (upgrade) skapar till exempel en ny release version secret och ändrar sedan release object så att det pekar på denna nya version. Vid en återställning (rollback) kan tidigare release version secrets användas för att återställa releasen till sitt tidigare tillstånd.

Efter avskaffandet av Tiller lagrar Helm 3 data om releasen i samma namnrymd som releasen. Denna förändring gör det möjligt att installera ett chart med samma namn som releasen i en annan namnrymd, och datan kvarstår mellan uppdateringar/omstarter av klustret i etcd. Till exempel kan WordPress installeras i namnrymden "foo" och sedan i namnrymden "bar", och båda releaserna kan kallas "wordpress".

Ändringar i chartens beroenden

Charten, paketerad (med hjälp av helm package) för användning med Helm 2 kan installeras med Helm 3, men arbetsflödet för chartutveckling har fullständigt omarbetats, så vissa ändringar måste göras för att fortsätta utveckla charts med Helm 3. Särskilt har systemet för beroendehantering av charts förändrats.

Beroendehanteringssystemet för chart har övergått till requirements.yaml och requirements.lock till Chart.yaml och Chart.lock. Det betyder att charts som använt kommandot helm dependency, kräver viss konfiguration för att fungera i Helm 3.

Låt oss titta på ett exempel. Låt oss lägga till ett beroende till ett chart i Helm 2 och se vad som förändras vid övergången till Helm 3.

I Helm 2 requirements.yaml såg ut som följer:

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

I Helm 3 kommer samma beroende att återspeglas i din Chart.yaml:

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

Charts laddas fortfarande ner och placeras i katalogen charts/, så subcharts (subcharts), som ligger i katalogen charts/, kommer att fortsätta fungera utan förändringar.

Vi presenterar Library Charts

Helm 3 stöder en klass av charts kallad bibliotekcharts (library chart). Denna chart används av andra charts, men skapar inga egen release artefakter. Mallar för library charts kan endast deklarera element define. Annan innehåll ignoreras helt enkelt. Detta gör det möjligt för användare att återanvända och dela kodfragment som kan användas i många charts, vilket undviker duplicering och följer principen om DRY.

Library charts deklareras i avsnittet dependencies i filen Chart.yaml. Installationen och hanteringen av dem skiljer sig inte från andra charts.

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

Vi ser fram emot de användningsmöjligheter som denna komponent kommer att öppna för chartutvecklare samt de bästa praxis som kan uppstå tack vare library charts.

Vad händer härnäst?

Helm 3.0.0-alpha.1 är grunden som vi bygger den nya versionen av Helm på. I artikeln har jag beskrivit några intressanta funktioner i Helm 3. Många av dem är fortfarande i ett tidigt utvecklingsstadium, och det är okej; syftet med alpha-releasen är att testa idén, samla feedback från tidiga användare och bekräfta våra antaganden.

Så snart alpha-versionen släpps (kom ihåg att detta redan har skett — anm. red.), vi kommer att börja ta emot patchar för Helm 3 från gemenskapen. Det är nödvändigt att skapa en stabil grund som möjliggör utveckling och acceptans av nya funktioner, så att användare kan känna sig involverade i processen genom att öppna biljetter och bidra med korrigeringar.

I artikeln har jag försökt belysa några av de stora förbättringar som kommer i Helm 3, men denna lista kan på intet sätt kallas uttömmande. Den fullständiga planen för Helm 3 inkluderar nyheter som förbättrade uppdateringsstrategier, djupare integration med OCI-register och användning av JSON-scheman för validering av chartvärden. Vi planerar också att städa upp kodbasen och uppdatera de delar som har fått lite uppmärksamhet de senaste tre åren.

Om du känner att vi har missat något, skulle vi gärna höra dina tankar!

Gå med i diskussionen i våra Slack-kanaler:

#helm-users för frågor och enkel kommunikation med gemenskapen;
#helm-dev för att diskutera pull requests, kod och buggar.

Du kan också delta i våra veckovisa offentliga utvecklarträffar på torsdagar klockan 19:30 MSK. Mötena ägnas åt att diskutera uppgifter som viktiga utvecklare och gemenskapen arbetar med, samt teman för veckans diskussion. Alla är välkomna att delta i mötet. Länken finns tillgänglig i Slack-kanalen. #helm-dev.

P.S. från översättaren

Läs även i vår blogg:

Källa: habr.com