🥇Introduktion till Helm 3

Notera. transl.: 16 maj i år markerar en betydande milstolpe i utvecklingen av pakethanteraren för Kubernetes - Helm. Den här dagen presenterades den första alfaversionen av den framtida större versionen av projektet - 3.0. Dess release kommer att medföra betydande och efterlängtade förändringar i Helm, som många i Kubernetes-gemenskapen har stora förhoppningar på. Vi är själva en av dessa, eftersom vi aktivt använder Helm för applikationsdistribution: vi har integrerat det i vårt verktyg för implementering av CI/CD werf och från tid till annan gör vi vårt bidrag till utvecklingen av upstream. Den här översättningen kombinerar 7 anteckningar från den officiella Helm-bloggen, som är dedikerade till den första alfaversionen av Helm 3 och talar om projektets historia och huvuddragen i Helm 3. Deras författare är Matt "bacongobbler" Fisher, en Microsoft-anställd och en av de viktigaste underhållarna av Helm.

Den 15 oktober 2015 föddes projektet som nu kallas Helm. Bara ett år efter grundandet gick Helm-communityt med i Kubernetes, samtidigt som de aktivt arbetade med Helm 2. I juni 2018, Helm gick med i CNCF som ett utvecklande (inkuberande) projekt. Spola framåt till nuet, och den första alfaversionen av nya Helm 3 är på väg. (denna utgåva har redan ägt rum i mitten av maj - ca. översätta.).

I den här artikeln ska jag prata om var allt började, hur vi kom dit vi är idag, introducera några av de unika funktionerna som finns tillgängliga i den första alfaversionen av Helm 3 och förklara hur vi planerar att utvecklas vidare.

Sammanfattning:

historien om skapandet av Helm;
ett ömt farväl till Tiller;
diagramförråd;
frigivningshantering;
förändringar i diagramberoenden;
biblioteksdiagram;
vad kommer härnäst?

Helms historia

födelse

Helm 1 började som ett Open Source-projekt skapat av Deis. Vi var en liten startup absorberas Microsoft våren 2017. Vårt andra Open Source-projekt, även kallat Deis, hade ett verktyg deisctl, som användes (bland annat) för att installera och driva Deis-plattformen i Flotta kluster. På den tiden var Fleet en av de första containerorkestreringsplattformarna.

I mitten av 2015 bestämde vi oss för att ändra kurs och flyttade Deis (då omdöpt till Deis Workflow) från Fleet till Kubernetes. En av de första som gjordes om var installationsverktyget. deisctl. Vi använde den för att installera och hantera Deis Workflow i Fleet-klustret.

Helm 1 skapades i bilden och likheten av kända pakethanterare som Homebrew, apt och yum. Dess huvudsakliga mål var att förenkla uppgifter som paketering och installation av applikationer på Kubernetes. Helm introducerades officiellt 2015 på KubeCon-konferensen i San Francisco.

Vårt första försök med Helm fungerade, men det var inte utan några allvarliga begränsningar. Han tog en uppsättning Kubernetes-manifest, smaksatta med generatorer som inledande YAML-block (front-materia)* och laddade in resultaten i Kubernetes.

* Notera. transl.: Från den första versionen av Helm valdes YAML-syntax för att beskriva Kubernetes-resurser, och Jinja-mallar och Python-skript stöddes när konfigurationer skrevs. Vi skrev mer om detta och strukturen i den första versionen av Helm i allmänhet i kapitlet "A Brief History of Helm" detta material.

Till exempel, för att ersätta ett fält i en YAML-fil, var du tvungen att lägga till följande konstruktion till manifestet:

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

Det är bra att mallmotorer finns idag, eller hur?

Av många anledningar krävde detta tidiga Kubernetes-installerare en hårdkodad lista med manifestfiler och körde bara en liten, fast sekvens av händelser. Det var så svårt att använda att Deis Workflow FoU-teamet hade svårt när de försökte överföra sin produkt till den här plattformen - men idén hade redan såtts. Vårt första försök var en fantastisk möjlighet att lära sig: vi insåg att vi verkligen brinner för att skapa pragmatiska verktyg som löser vardagliga problem för våra användare.

Baserat på erfarenheten av tidigare misstag började vi utveckla Helm 2.

Gör Helm 2

I slutet av 2015 kontaktade Google-teamet oss. De arbetade på ett liknande verktyg för Kubernetes. Deployment Manager för Kubernetes var en port av ett befintligt verktyg som användes för Google Cloud Platform. "Skulle vi vilja," frågade de, "tillbringa några dagar med att diskutera likheter och skillnader?"

I januari 2016 träffades teamen Helm och Deployment Manager i Seattle för att utbyta idéer. Förhandlingarna slutade med en ambitiös plan: att kombinera båda projekten för att skapa Helm 2. Tillsammans med Deis och Google, killarna från SkippBox (nu en del av Bitnami - cirka översättning), och vi började arbeta med Helm 2.

Vi ville behålla Helms användarvänlighet, men lägger till följande:

diagrammallar för anpassning;
ledning inom kluster för team;
sjökortsförråd i världsklass;
stabilt paketformat med signaturalternativ;
ett starkt engagemang för semantisk versionshantering och upprätthållande av bakåtkompatibilitet mellan versioner.

För att uppnå dessa mål har ett andra element lagts till i Helm-ekosystemet. Denna komponent inom kluster kallades Tiller och ansvarade för att installera Helm-diagram och hantera dem.

Sedan släppet av Helm 2 2016 har Kubernetes lagt till flera stora innovationer. Lade till rollbaserad åtkomstkontroll (RBAC), som så småningom ersatte Attribute-Based Access Control (ABAC). Nya resurstyper introducerades (Deployments var fortfarande i beta vid den tiden). Anpassade resursdefinitioner (ursprungligen kallade tredjepartsresurser eller TPR) uppfanns. Och viktigast av allt, en uppsättning bästa praxis har dykt upp.

Mitt i alla dessa förändringar fortsatte Helm att betjäna Kubernetes-användare troget. Efter tre år och många nya tillägg stod det klart att det var dags att göra betydande förändringar i kodbasen för att säkerställa att Helm kunde fortsätta att möta de växande behoven hos ett ekosystem i utveckling.

Ett ömt farväl till Tiller

Under utvecklingen av Helm 2 introducerade vi Tiller som en del av vår integration med Googles Deployment Manager. Tiller spelade en viktig roll för team som arbetade inom ett gemensamt kluster: det gjorde det möjligt för olika specialister som skötte 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 produktionen. På grund av det stora antalet möjliga säkerhetspolicyer har vår ståndpunkt varit att erbjuda en tillåten konfiguration som standard. Detta gjorde det möjligt för nybörjare att experimentera med Helm och Kubernetes utan att behöva dyka in i säkerhetsinställningarna först. Tyvärr kan denna behörighetskonfiguration ge användaren ett för stort antal behörigheter som de inte behövde. DevOps och SRE-ingenjörer var tvungna att lära sig ytterligare operativa steg när de installerade Tiller i ett kluster med flera hyresgäster.

Efter att ha lärt oss hur communityn använde Helm i specifika situationer insåg vi att Tillers versionshanteringssystem inte behövde förlita sig på en komponent inom kluster för att upprätthålla tillstånd eller fungera som ett centralt nav för releaseinformation. Istället kunde vi helt enkelt ta emot information från Kubernetes API-server, generera ett diagram på klientsidan och lagra en registrering av installationen i Kubernetes.

Tillers huvudmål hade kunnat uppnås utan Tiller, så ett av våra första beslut gällande Helm 3 var att helt överge Tiller.

Med Tiller borta har Helms säkerhetsmodell förenklats radikalt. Helm 3 stöder nu alla moderna säkerhets-, identitets- och auktoriseringsmetoder för nuvarande Kubernetes. Styrbehörigheter bestäms med hjälp av kubeconfig-fil. Klusteradministratörer kan begränsa användarrättigheterna till vilken detaljnivå som helst. Utgåvor sparas fortfarande i klustret, och resten av Helms funktionalitet förblir intakt.

Diagramförråd

På en hög nivå är ett diagramförråd en plats där diagram kan lagras och delas. Helm-klienten paketerar och skickar diagrammen till förvaret. Enkelt uttryckt är ett diagramförråd en primitiv HTTP-server med en index.yaml-fil och några paketerade diagram.

Även om det finns några fördelar med att Charts Repository API uppfyller de flesta grundläggande lagringskrav, finns det också några nackdelar:

Diagramförråd är inte kompatibla med de flesta säkerhetsimplementeringar som krävs i en produktionsmiljö. Att ha ett standard-API för autentisering och auktorisering är extremt viktigt i produktionsscenarier.
Helms karthärkomstverktyg, som används för att signera, verifiera integriteten och härkomsten av ett diagram, är en valfri del av diagrampubliceringsprocessen.
I fleranvändarscenarier kan samma diagram laddas upp av en annan användare, vilket fördubblar mängden utrymme som krävs för att lagra samma innehåll. Smartare repositories har utvecklats för att lösa detta problem, men de är inte en del av den formella specifikationen.
Att använda en enda indexfil för att söka, lagra metadata och hämta diagram har gjort det svårt att utveckla säkra fleranvändarimplementeringar.

Projekt Docker Distribution (även känd som Docker Registry v2) är efterföljaren till Docker Registry och fungerar i huvudsak som en uppsättning verktyg för förpackning, frakt, lagring och leverans av Docker-bilder. Många stora molntjänster erbjuder distributionsbaserade produkter. Tack vare denna ökade uppmärksamhet har distributionsprojektet dragit nytta av år av förbättringar, bästa säkerhetspraxis och fälttester som har gjort det till en av de mest framgångsrika obesjungna hjältarna i världen med öppen källkod.

Men visste du att distributionsprojektet utformades för att distribuera alla former av innehåll, inte bara behållarbilder?

Tack vare insatserna Öppna Container Initiative (eller OCI), kan Helm-diagram placeras på vilken distributionsinstans som helst. För närvarande är denna process experimentell. Inloggningsstöd och andra funktioner som behövs för en komplett Helm 3 är ett pågående arbete, men vi är glada över att lära oss av upptäckterna som OCI- och distributionsteamen har gjort under åren. Och genom deras mentorskap och vägledning lär vi oss hur det är att driva en högt tillgänglig tjänst i stor skala.

En mer detaljerad beskrivning av några kommande ändringar av Helm-diagramförråden finns tillgänglig по ссылке.

Releasehantering

I Helm 3 spåras applikationstillståndet inom klustret av ett par objekt:

release objekt - representerar en applikationsinstans;
release version secret - representerar det önskade tillståndet för applikationen vid en specifik tidpunkt (till exempel lanseringen av en ny version).

samtal helm install skapar ett releaseobjekt och releaseversionshemlighet. Ring upp helm upgrade kräver ett releaseobjekt (som det kan ändra) och skapar en ny releaseversionshemlighet som innehåller de nya värdena och ett förberett manifest.

Releaseobjekt innehåller information om releasen, där release är en specifik installation av ett namngivet diagram och värden. Det här objektet beskriver metadata på översta nivån om releasen. Utgivningsobjektet består under hela programmets livscykel och är ägare till alla hemligheter för versionsversionen, såväl som alla objekt som skapas direkt av Helm-diagrammet.

Release version secret associerar en release med en serie revisioner (installation, uppdateringar, rollbacks, radering).

I Helm 2 var revisionerna extremt konsekventa. Ring upp helm install skapade v1, den efterföljande uppdateringen (uppgraderingen) - v2, och så vidare. Release och release version hemlighet har komprimerats till ett enda objekt som kallas revision. Revisioner lagrades i samma namnutrymme som Tiller, vilket innebar att varje utgåva var "global" vad gäller namnutrymme; som ett resultat kunde bara en instans av namnet användas.

I Helm 3 är varje utgåva associerad med en eller flera hemligheter för utgivningsversioner. Releaseobjektet beskriver alltid den aktuella versionen som distribueras till Kubernetes. Varje hemlig version av versionen beskriver bara en version av den versionen. En uppgradering kommer till exempel att skapa en ny versionshemlighet och sedan ändra releaseobjektet så att det pekar på den nya versionen. I fallet med en återställning kan du använda hemligheter för tidigare versioner för att återställa versionen till ett tidigare tillstånd.

Efter att Tiller har övergetts lagrar Helm 3 releasedata i samma namnutrymme som releasen. Denna ändring låter dig installera ett diagram med samma versionsnamn i ett annat namnområde, och data sparas mellan klusteruppdateringar/omstarter i etcd. Till exempel kan du installera WordPress i "foo"-namnutrymmet och sedan i "bar"-namnutrymmet, och båda utgåvorna kan heta "wordpress".

Ändringar av diagramberoenden

Sjökort packade (med helm package) för användning med Helm 2 kan installeras med Helm 3, dock har arbetsflödet för sjökortsutveckling genomgått en fullständig översyn, så vissa ändringar måste göras för att fortsätta utvecklingen av sjökort med Helm 3. I synnerhet har hanteringssystemet för sjökortsberoende ändrats.

Diagrammets beroendehanteringssystem har flyttats från requirements.yaml и requirements.lock på Chart.yaml и Chart.lock. Detta betyder att de diagram som använde 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 diagrammet i Helm 2 och se vad som förändras när vi flyttar till Helm 3.

I rodret 2 requirements.yaml såg ut så här:

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

Diagram laddas fortfarande ner och placeras i katalogen charts/, så underdiagram (underdiagram), som ligger i katalogen charts/, kommer att fortsätta att fungera utan ändringar.

Vi presenterar biblioteksdiagram

Helm 3 stöder en klass av sjökort som kallas biblioteksdiagram (bibliotekskarta). Det här diagrammet används av andra diagram, men skapar inga utgivningsartefakter på egen hand. Biblioteksdiagrammallar kan bara deklarera element define. Annat innehåll ignoreras helt enkelt. Detta gör det möjligt för användare att återanvända och dela kodavsnitt som kan användas över flera diagram, och därigenom undvika dubbelarbete och bibehålla principen TORR.

Biblioteksdiagram deklareras i avsnittet dependencies i fil Chart.yaml. Att installera och hantera dem skiljer sig inte från andra diagram.

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

Vi är glada över de användningsfall som den här komponenten kommer att öppna upp för diagramutvecklare, såväl som de bästa metoderna som kan uppstå från biblioteksdiagram.

Vad händer nu?

Helm 3.0.0-alpha.1 är grunden på vilken vi börjar bygga en ny version av Helm. I artikeln beskrev jag några intressanta egenskaper hos Helm 3. Många av dem är fortfarande i de tidiga utvecklingsstadierna och detta är normalt; Poängen med en alfa-release är att testa idén, samla feedback från tidiga användare och bekräfta våra antaganden.

Så snart alfaversionen släpps (kom ihåg att detta är redan hänt - cirka. översätt.), kommer vi att börja acceptera patchar för Helm 3 från communityn. Du måste skapa en stark grund som gör att ny funktionalitet kan utvecklas och antas, och för att användarna ska känna sig delaktiga i processen genom att öppna biljetter och göra korrigeringar.

Jag har försökt lyfta fram några av de stora förbättringarna som kommer till Helm 3, men den här listan är inte på något sätt uttömmande. Den fullständiga färdplanen för Helm 3 innehåller funktioner som förbättrade uppdateringsstrategier, djupare integration med OCI-register och användningen av JSON-scheman för att validera diagramvärden. Vi planerar också att rensa upp kodbasen och uppdatera delar av den som har försummats de senaste tre åren.

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

Gå med i diskussionen på vår Slaka kanaler:

#helm-users för frågor och enkel kommunikation med samhället;
#helm-dev för att diskutera pull-förfrågningar, kod och buggar.

Du kan också chatta i våra veckovisa offentliga utvecklarsamtal på torsdagar kl. 19:30 MSK. Mötena är tillägnade att diskutera frågor som nyckelutvecklare och communityn arbetar med, samt diskussionsämnen för veckan. Vem som helst kan vara med och delta i mötet. Länk tillgänglig i Slack-kanalen #helm-dev.

PS från översättaren

Läs även på vår blogg:

Källa: will.com

Vi presenterar Helm 3