{"id":34735,"date":"2019-10-31T22:00:06","date_gmt":"2019-10-31T19:00:06","guid":{"rendered":"https:\/\/prohoster.info\/blog\/znakomstvo-s-helm-3\/"},"modified":"2019-10-31T22:00:06","modified_gmt":"2019-10-31T19:00:06","slug":"znakomstvo-s-helm-3","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/znakomstvo-s-helm-3","title":{"rendered":"Introduktion til Helm 3","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Introduktion til Helm 3\" src=\"\/wp-content\/uploads\/2019\/05\/6de0e2887ddcc802f1dd71c902325401.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<i><b>Bem. overs.<\/b>: 16. maj i \u00e5r markerede en vigtig milep\u00e6l i udviklingen af pakkemanageren til Kubernetes \u2014 Helm. P\u00e5 denne dag blev den f\u00f8rste alfa-version af det kommende store projekt \u2014 3.0 pr\u00e6senteret. Dens udgivelse vil medf\u00f8re betydelige og l\u00e6nge ventede \u00e6ndringer i Helm, som mange i Kubernetes-f\u00e6llesskabet s\u00e6tter store forh\u00e5bninger til. Det inkluderer ogs\u00e5 os, da vi aktivt bruger Helm til deployment af applikationer: vi har integreret det i vores v\u00e6rkt\u00f8j til implementering af CI\/CD. <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\">werf<\/a><\/noindex> Og fra tid til anden bidrager vi til udviklingen af upstream. Denne overs\u00e6ttelse samler 7 bem\u00e6rkninger fra Helm's officielle blog, der er knyttet til den f\u00f8rste alfa-udgivelse af Helm 3 og fort\u00e6ller om projektets historie og de vigtigste funktioner i Helm 3. Forfatteren er Matt \u00abbacongobbler\u00bb Fisher, medarbejder hos Microsoft og en af de centrale vedligeholdere af Helm.<\/i><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>15. oktober 2015 blev projektet, nu kendt som Helm, f\u00f8dt. Kun et \u00e5r efter grundl\u00e6ggelsen sluttede Helm-f\u00e6llesskabet sig til Kubernetes og arbejdede aktivt p\u00e5 Helm 2. I juni 2018 blev Helm <noindex><a rel=\"nofollow\" href=\"https:\/\/www.cncf.io\/blog\/2018\/06\/01\/cncf-to-host-helm\/\">en del af CNCF<\/a><\/noindex> som et inkuberingsprojekt. Lad os hoppe til nutiden \u2014 og her n\u00e6rmer den f\u00f8rste alfa-udgivelse af den nye Helm 3 sig <i>(denne udgivelse <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/helm\/helm\/releases\/tag\/v3.0.0-alpha.1\">har allerede fundet sted<\/a><\/noindex> i midten af maj \u2014 note fra overs\u00e6tteren)<\/i>.<\/p>\n<p>I dette materiale vil jeg fort\u00e6lle om, hvordan det hele startede, hvordan vi n\u00e5ede til den nuv\u00e6rende fase, pr\u00e6sentere nogle unikke funktioner, der er tilg\u00e6ngelige i den f\u00f8rste alfa-udgivelse af Helm 3, og forklare, hvordan vi planl\u00e6gger at udvikle os videre.<\/p>\n<p>Resum\u00e9:<\/p>\n<ul>\n<li>historien om Helm;<\/li>\n<li>en s\u00f8d farvel til Tiller;<\/li>\n<li>repositoryer af charts;<\/li>\n<li>administration af udgivelser;<\/li>\n<li>\u00e6ndringer i charts-afh\u00e6ngigheder;<\/li>\n<li>library charts;<\/li>\n<li>hvad nu?<\/li>\n<\/ul>\n<p><\/p>\n<h2>Historien om Helm<\/h2>\n<p><\/p>\n<h3>F\u00f8dslen<\/h3>\n<p>\nHelm 1 startede som et Open Source-projekt skabt af Deis. Vi var en lille startup, <noindex><a rel=\"nofollow\" href=\"https:\/\/blogs.microsoft.com\/blog\/2017\/04\/10\/microsoft-acquire-deis-help-companies-innovate-containers\/\">der blev overtaget<\/a><\/noindex> af Microsoft i for\u00e5ret 2017. Vores andet Open Source-projekt, som ogs\u00e5 hed Deis, havde et v\u00e6rkt\u00f8j <code>deisctl<\/code>, der blev brugt (blandt andet) til installation og drift af Deis-platformen i <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/coreos\/fleet\">Fleet-klusteret.<\/a><\/noindex>P\u00e5 det tidspunkt var Fleet en af de f\u00f8rste platforme til orkestrering af containere.<\/p>\n<p>I midten af 2015 besluttede vi at \u00e6ndre kurs og flyttede Deis (som p\u00e5 det tidspunkt var omd\u00f8bt til Deis Workflow) fra Fleet til Kubernetes. Et af de f\u00f8rste v\u00e6rkt\u00f8jer, der blev revideret, <code>deisctl<\/code>. Vi brugte det til installation og administration af Deis Workflow i Fleet-klusteret.<\/p>\n<p>Helm 1 blev skabt efter forbillederne fra kendte pakkemanager s\u00e5som Homebrew, apt og yum. Dets prim\u00e6re form\u00e5l var at forenkle opgaver som pakning og installation af applikationer i Kubernetes. Helm blev officielt pr\u00e6senteret i 2015 p\u00e5 KubeCon-konferencen i San Francisco.<\/p>\n<p>Vores f\u00f8rste fors\u00f8g med Helm lykkedes, men der var alvorlige begr\u00e6nsninger. Det tog et s\u00e6t Kubernetes-manifester, tilsat generatorer som input YAML-blokke. <i>(front-matter)<\/i>*, og indl\u00e6ste resultaterne i Kubernetes.<\/p>\n<p><i>* <b>Bem. overs.<\/b>: Fra den f\u00f8rste version af Helm blev YAML-syntax valgt til at beskrive Kubernetes-ressourcer, og n\u00e5r der blev skrevet konfigurationer, blev Jinja-skabeloner og Python-scripts underst\u00f8ttet. Mere om dette og strukturen i den f\u00f8rste version af Helm generelt skrev vi i kapitlet \"Kort historie om Helm\" <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/417079\/\">dette materiale<\/a><\/noindex>.<\/i><\/p>\n<p>For eksempel, for at erstatte et felt i YAML-filen, skulle man tilf\u00f8je f\u00f8lgende konstruktion i manifestet:<\/p>\n<pre><code class=\"plaintext\">#helm:generate sed -i -e s|ubuntu-debootstrap|fluffy-bunny| my\/pod.yaml<\/code><\/pre>\n<p>\nDet er fantastisk, at der i dag findes skabelonv\u00e6rkt\u00f8jer, ikke sandt?<\/p>\n<p>Af mange grunde kr\u00e6vede denne tidlige Kubernetes-installationsprogram en h\u00e5rdkodet liste over manifestfiler og udf\u00f8rte kun en lille fast sekvens af begivenheder. Det var s\u00e5 besv\u00e6rligt at bruge, at R&amp;D-teamet i Deis Workflow havde det sv\u00e6rt, da de fors\u00f8gte at flytte deres produkt til denne platform \u2014 dog var fr\u00f8ene til id\u00e9en allerede blevet s\u00e5et. Vores f\u00f8rste fors\u00f8g blev en fremragende mulighed for l\u00e6ring: vi inds\u00e5, at vi virkelig br\u00e6ndte for at skabe pragmatiske v\u00e6rkt\u00f8jer, der l\u00f8ser dagligdags problemer for vores brugere.<\/p>\n<p>Med erfaring fra tidligere fejl indledte vi udviklingen af Helm 2.<\/p>\n<h3>Skabelsen af Helm 2<\/h3>\n<p>\nI slutningen af 2015 kontaktede Googles team os. De arbejdede p\u00e5 et lignende v\u00e6rkt\u00f8j til Kubernetes. Deployment Manager til Kubernetes var en port af et eksisterende v\u00e6rkt\u00f8j, der blev brugt til Google Cloud Platform. \"\u00d8nsker vi ikke, - spurgte de, - at bruge et par dage p\u00e5 at diskutere ligheder og forskelle?\"<\/p>\n<p>I januar 2016 m\u00f8dtes Helm- og Deployment Manager-holdene i Seattle for at udveksle id\u00e9er. Forhandlingerne resulterede i en ambiti\u00f8s plan: at fusionere begge projekter for at skabe Helm 2. Sammen med Deis og Google sluttede gutterne sig til udviklerteamet. <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/skippbox\">SkippBox<\/a><\/noindex> <i>(som nu er en del af Bitnami \u2014 red.)<\/i>, og vi begyndte at arbejde p\u00e5 Helm 2.<\/p>\n<p>Vi \u00f8nskede at bevare brugervenligheden af Helm, men tilf\u00f8je f\u00f8lgende:<\/p>\n<ul>\n<li> skabeloner til tilpasning af charts;<\/li>\n<li> intern klyngeadministration for teams;<\/li>\n<li> f\u00f8rsteklasses chart-repositorium;<\/li>\n<li> et stabilt pakkeformat med mulighed for signering;<\/li>\n<li> en fast forpligtelse til semantisk versionering og at bevare bagudkompatibilitet mellem versioner.<\/li>\n<\/ul>\n<p>\nFor at opn\u00e5 disse m\u00e5l blev der tilf\u00f8jet et andet element til Helm-\u00f8kosystemet. Denne interne komponent blev kaldt Tiller og h\u00e5ndterede installation og administration af Helm-charts.<\/p>\n<p>Siden lanceringen af Helm 2 i 2016 har Kubernetes f\u00e5et flere v\u00e6sentlige nyheder. Der er kommet rollebaseret adgangskontrol (<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/422801\/\">RBAC<\/a><\/noindex>), som til sidst erstattede attributbaseret adgangskontrol (ABAC). Nye ressourcetyper blev introduceret (Deployments var stadig i beta p\u00e5 det tidspunkt). Der blev opfundet Custom Resource Definitions (oprindeligt kaldet Third Party Resources eller TPRs). Og vigtigst af alt - et s\u00e6t bedste praksisser blev etableret.<\/p>\n<p>P\u00e5 baggrund af alle disse \u00e6ndringer fortsatte Helm med at tjene Kubernetes-brugerne trofast. Efter tre \u00e5r og mange nye tilf\u00f8jelser blev det klart, at det var p\u00e5 tide at foretage betydelige \u00e6ndringer i kodebasen, s\u00e5 Helm kunne forts\u00e6tte med at im\u00f8dekomme de voksende behov i den udviklende \u00f8kosystem.<\/p>\n<h2>En s\u00f8d farvel til Tiller<\/h2>\n<p>\nUnder udviklingen af Helm 2 introducerede vi Tiller som en del af vores integration med Google's Deployment Manager. Tiller spillede en vigtig rolle for de teams, der arbejdede inden for en f\u00e6lles klynge: det gjorde det muligt for forskellige specialister, der udnyttede infrastrukturen, at interagere med det samme s\u00e6t af udgivelser.<\/p>\n<p>Da rollebaseret adgangskontrol (RBAC) blev indf\u00f8rt som standard i Kubernetes 1.6, blev arbejdet med Tiller i produktion mere udfordrende. P\u00e5 grund af det enorme antal mulige sikkerhedspolitikker var vores tilgang at tilbyde en tilladende konfiguration som standard. Dette gjorde det muligt for nybegyndere at eksperimentere med Helm og Kubernetes uden f\u00f8rst at skulle dykke ind i sikkerhedsindstillingerne. Desv\u00e6rre kunne denne tilladende konfiguration give brugeren for brede tilladelser, som de ikke havde brug for. DevOps- og SRE-ingeni\u00f8rer m\u00e5tte l\u00e6re ekstra operationelle skridt for at installere Tiller i en flerbruger- (multi-tenant) klynge.<\/p>\n<p>Ved at l\u00e6re, hvordan medlemmer af samfundet bruger Helm i specifikke situationer, inds\u00e5 vi, at Tiller's release management system ikke beh\u00f8vede at v\u00e6re afh\u00e6ngigt af en intern klyngekomponent for at opretholde tilstande eller fungere som et centralt knudepunkt med information om udgivelser. I stedet kunne vi blot hente information fra Kubernetes API-serveren, generere et chart p\u00e5 klientsiden og gemme installationsoptegnelsen i Kubernetes.<\/p>\n<p>Den prim\u00e6re opgave, som Tiller udf\u00f8rte, kunne ogs\u00e5 udf\u00f8res uden Tiller, s\u00e5 en af vores f\u00f8rste beslutninger om Helm 3 var fuldst\u00e6ndig at fjerne Tiller.<\/p>\n<p>Med Tiller's afgang blev Helm's sikkerhedsmodel radikalt forenklet. Helm 3 underst\u00f8tter nu alle moderne sikkerhedsm\u00e5der, identifikation og autorisation af den nuv\u00e6rende Kubernetes. Helm's tilladelser defineres ved hj\u00e6lp af <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/configuration\/organize-cluster-access-kubeconfig\/\">kubeconfig-filen<\/a><\/noindex>. Klyngeadministratorer kan begr\u00e6nse brugerrettigheder med enhver grad af detalje. Udgivelser gemmes stadig inden for klyngen, og resten af Helm's funktionalitet bevares.<\/p>\n<h2>Chart-repositorier<\/h2>\n<p>\nP\u00e5 et h\u00f8jt 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.<\/p>\n<p>Selvom der er nogle fordele ved, at chart-repositoriets API opfylder de grundl\u00e6ggende krav til lager, har det ogs\u00e5 nogle ulemper:<\/p>\n<ul>\n<li> Chart-repositorier er d\u00e5rligt kompatible med de fleste sikkerhedsl\u00f8sninger, der er n\u00f8dvendige i produktionsmilj\u00f8er. En standard API til autentificering og autorisation er yderst vigtig i produktionsscenarier.<\/li>\n<li> Helm-v\u00e6rkt\u00f8jer til at spore oprindelsen af charts, der bruges til signering, integritetskontrol og oprindelsesanalyse, er en valgfri del af publiceringsprocessen af et chart.<\/li>\n<li> I multi-bruger scenarier kan det samme chart blive uploadet af en anden bruger, hvilket fordobler den n\u00f8dvendige lagerplads til det samme indhold. For at l\u00f8se dette problem er der blevet udviklet smartere repositories, men de er ikke en del af den officielle specifikation.<\/li>\n<li> Brugen af en enkelt indeksfil til at finde, opbevare metadata og hente charts har kompliceret udviklingen af sikre multi-bruger implementeringer.<\/li>\n<\/ul>\n<p>\nProjekt <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/docker\/distribution\">Docker Distribution<\/a><\/noindex> (ogs\u00e5 kendt som Docker Registry v2) er efterf\u00f8lgeren til Docker Registry og repr\u00e6senterer i virkeligheden et v\u00e6rkt\u00f8jss\u00e6t til pakning, overf\u00f8rsel, opbevaring og levering af Docker-images. Mange store cloud-tjenester tilbyder produkter baseret p\u00e5 Distribution. Denne ekstra opm\u00e6rksomhed har givet projektet Distribution fordel af mange \u00e5rs forbedringer, bedste sikkerhedspraksis og test i 'kamp'-milj\u00f8er, hvilket har gjort det til en af de mest succesrige, oversete helte i Open Source-verdenen.<\/p>\n<p>Men vidste du, at Distribution-projektet blev udviklet til distribution af enhver form for indhold, ikke kun containerimages?<\/p>\n<p>Takket v\u00e6re indsatsen fra <noindex><a rel=\"nofollow\" href=\"https:\/\/www.opencontainers.org\/\">Open Container Initiative<\/a><\/noindex> (eller OCI) kan Helm-charts placeres p\u00e5 enhver Distribution-instans. Mens denne proces stadig er eksperimentel. Arbejdet med at underst\u00f8tte login og andre funktioner, der er n\u00f8dvendige for fuld Helm 3, er endnu ikke afsluttet, men vi er meget glade for muligheden for at l\u00e6re af de opdagelser, som OCI- og Distribution-teams har gjort gennem \u00e5rene. Takket v\u00e6re deres vejledning og mentoring l\u00e6rer vi, hvad det kr\u00e6ver at drive en h\u00f8jt tilg\u00e6ngelig service i stor skala.<\/p>\n<p>En mere detaljeret beskrivelse af nogle kommende \u00e6ndringer i Helm-chart-repositories er tilg\u00e6ngelig <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.bacongobbler.com\/post\/2019-01-25-distributing-with-distribution\/\">via linket<\/a><\/noindex>.<\/p>\n<h2>Udgivelsesh\u00e5ndtering<\/h2>\n<p>\nI Helm 3 spores applikationens tilstand inden for klyngen af et par objekter:<\/p>\n<ul>\n<li> release object \u2014 repr\u00e6senterer en instans af applikationen;<\/li>\n<li> release version secret \u2014 repr\u00e6senterer den \u00f8nskede tilstand af applikationen p\u00e5 et bestemt tidspunkt (for eksempel udgivelse af en ny version).<\/li>\n<\/ul>\n<p>\nKald <code>helm install<\/code> opretter release object og release version secret. Kaldet <code>helm upgrade<\/code> kr\u00e6ver tilstedev\u00e6relsen af release object (som det kan \u00e6ndre) og opretter en ny release version secret, der indeholder nye v\u00e6rdier og det forberedte manifest.<\/p>\n<p>Release object indeholder information om en udgivelse, hvor udgivelsen er en specifik installation af et navngivet chart og dets v\u00e6rdier. Dette objekt beskriver metadata p\u00e5 h\u00f8jeste niveau om udgivelsen. Release object forbliver gennem hele applikationens livscyklus og ejer alle release version secrets samt alle objekter, der direkte oprettes af Helm-chartet.<\/p>\n<p>Release version secret forbinder udgivelsen med en serie revisioner (installation, opdateringer, tilbagesendelse, sletning).<\/p>\n<p>I Helm 2 var revisioner udelukkende sekventielle. Kaldet <code>helm install<\/code> oprettede v1, efterf\u00f8lgende opdatering (upgrade) \u2014 v2, og s\u00e5 videre. Release og release version secret blev samlet i et enkelt objekt kendt som revision. Revisioner blev opbevaret i det samme namespaces som Tiller, hvilket bet\u00f8d, at hver udgivelse var \"global\" med hensyn til namespaces; som f\u00f8lge heraf kunne kun \u00e9n instans af navnet bruges.<\/p>\n<p>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 \u00e9n version af denne udgivelse. En opdatering (upgrade) vil for eksempel oprette en ny release version secret og derefter \u00e6ndre release object, s\u00e5 det peger p\u00e5 denne nye version. I tilf\u00e6lde af et tilbagefald (rollback) kan tidligere release version secrets bruges til at rulle udgivelsen tilbage til en tidligere tilstand.<\/p>\n<p>Efter afviklingen af Tiller opbevarer Helm 3 data om udgivelsen i det samme namespace som udgivelsen. Denne \u00e6ndring g\u00f8r det muligt at installere et chart med det 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 hedde \"wordpress\".<\/p>\n<h2>\u00c6ndringer i chart-afh\u00e6ngigheder<\/h2>\n<p>\nCharts, der er pakket (ved hj\u00e6lp af <code>helm package<\/code>) til brug med Helm 2 kan installeres med Helm 3. Men udviklingsarbejdsprocessen for charts er blevet fuldst\u00e6ndig revideret, s\u00e5 der skal foretages nogle \u00e6ndringer for fortsat at kunne udvikle charts med Helm 3. Is\u00e6r er systemet til h\u00e5ndtering af chartafh\u00e6ngigheder \u00e6ndret.<\/p>\n<p>Systemet til h\u00e5ndtering af afh\u00e6ngigheder for charts er g\u00e5et fra <code>requirements.yaml<\/code> og <code>requirements.lock<\/code> og f\u00e5 en fungerende kommando. <code>Chart.yaml<\/code> og <code>Chart.lock<\/code>. Dette betyder, at charts, der brugte kommandoen <code>helm dependency<\/code>, kr\u00e6ver nogle tilpasninger for at fungere i Helm 3.<\/p>\n<p>Lad os tage et eksempel. Vi tilf\u00f8jer en afh\u00e6ngighed til et chart i Helm 2 og ser, hvad der \u00e6ndres ved overgangen til Helm 3.<\/p>\n<p>I Helm 2 <code>requirements.yaml<\/code> s\u00e5dan ud:<\/p>\n<pre><code class=\"plaintext\">dependencies:\n- name: mariadb\n  version: 5.x.x\n  repository: https:\/\/kubernetes-charts.storage.googleapis.com\/\n  condition: mariadb.enabled\n  tags:\n    - database<\/code><\/pre>\n<p>\nI Helm 3 vil den samme afh\u00e6ngighed afspejles i dit <code>Chart.yaml<\/code>:<\/p>\n<pre><code class=\"plaintext\">dependencies:\n- name: mariadb\n  version: 5.x.x\n  repository: https:\/\/kubernetes-charts.storage.googleapis.com\/\n  condition: mariadb.enabled\n  tags:\n    - database<\/code><\/pre>\n<p>\nCharts indl\u00e6ses stadig og placeres i mappen <code>charts\/<\/code>, s\u00e5 subcharts <i>(subcharts)<\/i>, der ligger i kataloget <code>charts\/<\/code>, vil forts\u00e6tte med at fungere uden \u00e6ndringer.<\/p>\n<h2>Pr\u00e6senterer Library Charts<\/h2>\n<p>\nHelm 3 underst\u00f8tter en klasse charts, der kaldes library charts <i>(library chart).<\/i>. Dette chart bruges af andre charts, men skaber ikke selv nogen udgivelsesartefakter. Library chart skabeloner kan kun erkl\u00e6re elementer. <code>define<\/code>. Andet indhold ignoreres simpelthen. Dette g\u00f8r det muligt for brugerne at genbruge og dele kodefragmenter, som kan anvendes p\u00e5 tv\u00e6rs af mange charts og dermed undg\u00e5 duplikering og f\u00f8lge princippet <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Don%27t_repeat_yourself\">DRY<\/a><\/noindex>.<\/p>\n<p>Library charts erkl\u00e6res i sektionen <code>dependencies<\/code> i filen <code>Chart.yaml<\/code>. Installation og h\u00e5ndtering af dem adskiller sig ikke fra andre charts.<\/p>\n<pre><code class=\"plaintext\">dependencies:\n  - name: mylib\n    version: 1.x.x\n    repository: quay.io<\/code><\/pre>\n<p>\nVi ser frem til de anvendelsesmuligheder, som denne komponent \u00e5bner for chartudviklere, samt de bedste praksisser, der kan opst\u00e5 takket v\u00e6re library charts.<\/p>\n<h2>Hvad nu?<\/h2>\n<p>\nHelm 3.0.0-alpha.1 er grundlaget, som vi begynder at bygge den nye version af Helm p\u00e5. 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\u00e9en, samle feedback fra de f\u00f8rste brugere og bekr\u00e6fte vores antagelser.<\/p>\n<p>N\u00e5r alpha-versionen er frigivet <i>(lad os minde om, at dette <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/helm\/helm\/releases\/tag\/v3.0.0-alpha.1\">allerede er sket<\/a><\/noindex> \u2014 red. anm.)<\/i>, vi vil begynde at modtage patches til Helm 3 fra f\u00e6llesskabet. Det er n\u00f8dvendigt at skabe et solidt fundament, der muligg\u00f8r udvikling og modtagelse af nye funktionaliteter, og brugerne vil kunne f\u00f8le sig involveret i processen ved at \u00e5bne tickets og indsende rettelser.<\/p>\n<p>I artiklen har jeg fors\u00f8gt at belyse nogle v\u00e6sentlige forbedringer, der vil blive tilg\u00e6ngelige i Helm 3, men denne liste kan p\u00e5 ingen m\u00e5de betragtes som udt\u00f8mmende. 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\u00e6rdier. Vi planl\u00e6gger ogs\u00e5 at rydde op i kodebasen og opdatere de dele, der har v\u00e6ret ignoreret i de sidste tre \u00e5r.<\/p>\n<p>Hvis du f\u00f8ler, at vi har overset noget, vil vi gerne h\u00f8re dine tanker!<\/p>\n<p>Deltag i diskussionen i vores <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.slack.com\/\">Slack-kanaler<\/a><\/noindex>:<\/p>\n<ul>\n<li> <code>#helm-users<\/code> til sp\u00f8rgsm\u00e5l og almindelig kommunikation med f\u00e6llesskabet;<\/li>\n<li> <code>#helm-dev<\/code> til diskussion af pull requests, kode og bugs.<\/li>\n<\/ul>\n<p>\nDu kan ogs\u00e5 deltage i vores ugentlige Public Developer Calls hver torsdag kl. 19:30 MSK. M\u00f8derne er dedikeret til diskussion af opgaver, som de centrale udviklere og f\u00e6llesskabet arbejder p\u00e5, samt ugens diskussionsemner. Alle er velkomne til at deltage i m\u00f8det. Linket er tilg\u00e6ngeligt i Slack-kanalen <code>#helm-dev<\/code>.<\/p>\n<h2>P.S. fra overs\u00e6tteren<\/h2>\n<p>\nL\u00e6s ogs\u00e5 p\u00e5 vores blog:<\/p>\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/417079\/\">Pakkestyringssystem for Kubernetes \u2014 Helm: fortid, nutid, fremtid<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/438814\/\">En sober vurdering af Helm 2: \u201eS\u00e5dan som det er\u2026\u201c<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/420437\/\">Praktisk introduktion til pakken manager for Kubernetes \u2014 Helm<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/441964\/\">Kubernetes tips &amp; tricks: overs\u00e6ttelse af fungerende ressourcer i klyngen til styring af Helm 2<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/336170\/\">Praksis med dapp. Del 2. Udrulning af Docker-billeder i Kubernetes ved hj\u00e6lp af Helm<\/a><\/noindex>\u00bb.<\/li>\n<\/ul>\n<p>Kilde: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/453734\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041f\u0440\u0438\u043c. \u043f\u0435\u0440\u0435\u0432.: 16 \u043c\u0430\u044f \u044d\u0442\u043e\u0433\u043e \u0433\u043e\u0434\u0430 \u2014 \u0437\u043d\u0430\u0447\u0438\u043c\u0430\u044f \u0432\u0435\u0445\u0430 \u0432 \u0440\u0430\u0437\u0432\u0438\u0442\u0438\u0438 \u043c\u0435\u043d\u0435\u0434\u0436\u0435\u0440\u0430 \u043f\u0430\u043a\u0435\u0442\u043e\u0432 \u0434\u043b\u044f Kubernetes \u2014 Helm. \u0412 \u044d\u0442\u043e\u0442 \u0434\u0435\u043d\u044c \u0431\u044b\u043b \u043f\u0440\u0435\u0434\u0441\u0442\u0430\u0432\u043b\u0435\u043d \u043f\u0435\u0440\u0432\u044b\u0439 \u0430\u043b\u044c\u0444\u0430-\u0440\u0435\u043b\u0438\u0437 \u0431\u0443\u0434\u0443\u0449\u0435\u0439 \u043a\u0440\u0443\u043f\u043d\u043e\u0439 \u0432\u0435\u0440\u0441\u0438\u0438 \u043f\u0440\u043e\u0435\u043a\u0442\u0430 \u2014 3.0. \u0415\u0451 \u0432\u044b\u0445\u043e\u0434 \u043f\u0440\u0438\u043d\u0435\u0441\u0451\u0442 \u0432 Helm \u0441\u0443\u0449\u0435\u0441\u0442\u0432\u0435\u043d\u043d\u044b\u0435 \u0438 \u0434\u043e\u043b\u0433\u043e\u0436\u0434\u0430\u043d\u043d\u044b\u0435 \u0438\u0437\u043c\u0435\u043d\u0435\u043d\u0438\u044f, \u043d\u0430 \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043c\u043d\u043e\u0433\u0438\u0435 \u0432 Kubernetes-\u0441\u043e\u043e\u0431\u0449\u0435\u0441\u0442\u0432\u0435 \u0432\u043e\u0437\u043b\u0430\u0433\u0430\u044e\u0442 \u0431\u043e\u043b\u044c\u0448\u0438\u0435 \u043d\u0430\u0434\u0435\u0436\u0434\u044b. \u041a \u0442\u0430\u043a\u043e\u0432\u044b\u043c \u043e\u0442\u043d\u043e\u0441\u0438\u043c\u0441\u044f \u0438 \u043c\u044b \u0441\u0430\u043c\u0438, \u043f\u043e\u0441\u043a\u043e\u043b\u044c\u043a\u0443 \u0430\u043a\u0442\u0438\u0432\u043d\u043e [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":26173,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-34735","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.3 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041f\u0440\u0438\u043c.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/znakomstvo-s-helm-3\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"da_DK\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u0417\u043d\u0430\u043a\u043e\u043c\u0441\u0442\u0432\u043e \u0441 Helm 3 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041f\u0440\u0438\u043c.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/znakomstvo-s-helm-3\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T19:00:06+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T19:00:06+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Introduktion til Helm 3 | ProHoster","description":"Bem.","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/znakomstvo-s-helm-3","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0417\u043d\u0430\u043a\u043e\u043c\u0441\u0442\u0432\u043e \u0441 Helm 3 | ProHoster","og:description":"\u041f\u0440\u0438\u043c.","og:url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/znakomstvo-s-helm-3","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:00:06+00:00","article:modified_time":"2019-10-31T19:00:06+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"34735","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-21 20:26:53","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 23:08:04","updated":"2026-01-21 20:26:53","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/34735","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=34735"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/34735\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media\/26173"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=34735"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=34735"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=34735"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}