{"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\/no\/blog\/administrirovanie\/znakomstvo-s-helm-3","title":{"rendered":"Introduksjon til Helm 3","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Introduksjon til Helm 3\" src=\"\/wp-content\/uploads\/2019\/05\/6de0e2887ddcc802f1dd71c902325401.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<i><b>Obs. overs.<\/b>: 16. mai i \u00e5r markerer en betydningsfull milep\u00e6l i utviklingen av pakkeadministratoren for Kubernetes \u2013 Helm. Denne dagen ble den f\u00f8rste alpha-utgaven av den kommende st\u00f8rre versjonen av prosjektet \u2013 3.0 \u2013 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\u00e5rt verkt\u00f8y for implementering av CI\/CD. <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\">werf<\/a><\/noindex> 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\u00f8rste 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.<\/i><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>15. oktober 2015 ble prosjektet, n\u00e5 kjent som Helm, f\u00f8dt. Bare ett \u00e5r etter grunnleggelsen ble Helm-samfunnet med i Kubernetes, samtidig som de aktivt jobbet med Helm 2. I juni 2018 ble Helm <noindex><a rel=\"nofollow\" href=\"https:\/\/www.cncf.io\/blog\/2018\/06\/01\/cncf-to-host-helm\/\">en del av CNCF<\/a><\/noindex> som et utviklende (incubating) prosjekt. La oss g\u00e5 til n\u00e5tiden \u2013 og n\u00e5 n\u00e6rmer den f\u00f8rste alpha-utgaven av nye Helm 3 seg. <i>(denne utgivelsen <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/helm\/helm\/releases\/tag\/v3.0.0-alpha.1\">fant allerede sted<\/a><\/noindex> i midten av mai \u2013 overs. anm.)<\/i>.<\/p>\n<p>I dette materialet vil jeg fortelle om hvordan alt begynte, hvordan vi kom hit, presentere noen unike funksjoner som er tilgjengelige i den f\u00f8rste alpha-utgaven av Helm 3, og forklare hvordan vi planlegger \u00e5 utvikle oss videre.<\/p>\n<p>Sammendrag:<\/p>\n<ul>\n<li>historien om opprettelsen av Helm;<\/li>\n<li>\u00f8mt farvel til Tiller;<\/li>\n<li>chart-repositorier;<\/li>\n<li>forvaltning av utgivelser;<\/li>\n<li>endringer i chart-avhengigheter;<\/li>\n<li>library charts;<\/li>\n<li>hva n\u00e5?<\/li>\n<\/ul>\n<p><\/p>\n<h2>Historien om opprettelsen av Helm<\/h2>\n<p><\/p>\n<h3>F\u00f8dselen<\/h3>\n<p>\nHelm 1 begynte som et \u00e5pen kildekode-prosjekt, skapt av firmaet Deis. Vi var et lite oppstartsselskap, <noindex><a rel=\"nofollow\" href=\"https:\/\/blogs.microsoft.com\/blog\/2017\/04\/10\/microsoft-acquire-deis-help-companies-innovate-containers\/\">som ble oppkj\u00f8pt<\/a><\/noindex> av Microsoft v\u00e5ren 2017. V\u00e5rt andre \u00e5pne kildekode-prosjekt, ogs\u00e5 kalt Deis, hadde et verkt\u00f8y <code>deisctl<\/code>, som ble brukt (blant annet) for \u00e5 installere og drifte Deis-plattformen i <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/coreos\/fleet\">Fleet-klyngen.<\/a><\/noindex>P\u00e5 den tiden var Fleet en av de f\u00f8rste plattformene for orkestrering av containere.<\/p>\n<p>I midten av 2015 besluttet vi \u00e5 endre kurs og migrere Deis (som da hadde f\u00e5tt navnet Deis Workflow) fra Fleet til Kubernetes. En av de f\u00f8rste tingene som ble omarbeidet, var verkt\u00f8yet for installasjon. <code>deisctl<\/code>Vi brukte det til \u00e5 installere og forvalte Deis Workflow i Fleet-klyngen.<\/p>\n<p>Helm 1 ble utviklet med inspirasjon fra kjente pakkebehandlere som Homebrew, apt og yum. Hovedoppgaven var \u00e5 forenkle oppgaver som pakking og installering av applikasjoner i Kubernetes. Helm ble offisielt lansert i 2015 under KubeCon-konferansen i San Francisco.<\/p>\n<p>V\u00e5r f\u00f8rste fors\u00f8k med Helm ga resultater, men det kom med betydelige begrensninger. Den tok en samling Kubernetes-manifester, beriket med generatorer som innledende YAML-blokker, <i>(front-matter)<\/i>*, og lastet resultatene inn i Kubernetes.<\/p>\n<p><i>* <b>Obs. overs.<\/b>: Framsiden av Helm 1 valgte YAML-syntaks for \u00e5 beskrive Kubernetes-ressurser, og ved konfigurasjonsskriving ble Jinja-maler og Python-skript st\u00f8ttet. Mer om dette og strukturen til Helm 1 generelt diskutert i kapitlet \u00abKort historie om Helm\u00bb <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/417079\/\">dette materialet<\/a><\/noindex>.<\/i><\/p>\n<p>For eksempel, for \u00e5 erstatte et felt i en YAML-fil, m\u00e5tte man legge til f\u00f8lgende konstruksjon 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 vi i dag har malere, ikke sant?<\/p>\n<p>Av mange grunner krevde denne tidlige Kubernetes-installasjonen en hardkodet liste med manifestfiler og utf\u00f8rte bare en liten fast sekvens av hendelser. Det var s\u00e5 vanskelig \u00e5 bruke at R&amp;D-teamet til Deis Workflow hadde det t\u00f8ft n\u00e5r de fors\u00f8kte \u00e5 portere produktet sitt til denne plattformen \u2014 men fr\u00f8ene til ideen var allerede s\u00e5dd. V\u00e5r f\u00f8rste fors\u00f8k ga en flott l\u00e6ringsmulighet: vi inns\u00e5 at vi virkelig er lidenskapelige for \u00e5 lage pragmatiske verkt\u00f8y som l\u00f8ser hverdagsproblemer for brukerne v\u00e5re.<\/p>\n<p>Basert p\u00e5 erfaringene fra tidligere feil, begynte vi \u00e5 utvikle Helm 2.<\/p>\n<h3>Utvikling av Helm 2<\/h3>\n<p>\nP\u00e5 slutten av 2015 kontaktet Googles team oss. De jobbet med et lignende verkt\u00f8y for Kubernetes. Deployment Manager for Kubernetes var en portering av et eksisterende verkt\u00f8y som ble brukt for Google Cloud Platform. \u00abVil vi bruke noen dager p\u00e5 \u00e5 diskutere likhetene og forskjellene?\u00bb spurte de.<\/p>\n<p>I januar 2016 m\u00f8ttes teamene fra Helm og Deployment Manager i Seattle for \u00e5 dele ideer. Forhandlingene resulterte i en ambisi\u00f8s plan: \u00e5 kombinere begge prosjektene for \u00e5 skape Helm 2. Sammen med Deis og Google ble guttene fra utviklingsteamet med. <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/skippbox\">SkippBox<\/a><\/noindex> <i>(n\u00e5 en del av Bitnami \u2014 overs. anm.)<\/i>, og vi begynte arbeidet med Helm 2.<\/p>\n<p>Vi \u00f8nsket \u00e5 bevare brukervennligheten i Helm, men legge til f\u00f8lgende:<\/p>\n<ul>\n<li> chart-maler for tilpasning;<\/li>\n<li> intra-klyngeadministrasjon for team;<\/li>\n<li> f\u00f8rsteklasses chart-repositorium;<\/li>\n<li> et stabilt pakkeforum med signeringsmuligheter;<\/li>\n<li> et solid engasjement for semantisk versjonering og opprettholdelse av bakoverkompatibilitet mellom versjoner.<\/li>\n<\/ul>\n<p>\nFor \u00e5 oppn\u00e5 disse m\u00e5lene ble et andre element lagt til Helm-\u00f8kosystemet. Denne intra-klyngekomponenten ble kalt Tiller og hadde ansvar for installering og administrasjon av Helm-charts.<\/p>\n<p>Siden lanseringen av Helm 2 i 2016 har Kubernetes f\u00e5tt flere betydelige nyvinninger. Det ble innf\u00f8rt rollebasert tilgangskontroll (<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/422801\/\">RBAC<\/a><\/noindex>), som til slutt erstattet attributtbasert tilgangskontroll (ABAC). Nye ressurs typer ble introdusert (Deployments var fremdeles i beta-delen p\u00e5 den tiden). Det ble erfart om Custom Resource Definitions (opprinnelig kalt Third Party Resources eller TPRs). Og viktigst av alt \u2014 et sett med beste praksis ble utviklet.<\/p>\n<p>I lys av alle disse endringene fortsatte Helm \u00e5 v\u00e6re en p\u00e5litelig tjeneste for Kubernetes-brukere. Etter tre \u00e5r og mange nye tillegg ble det klart at det var p\u00e5 tide med betydelige endringer i kodebasen for at Helm fortsatt skulle kunne oppfylle de voksende behovene til det utviklende \u00f8kosystemet.<\/p>\n<h2>\u00f8mt farvel til Tiller<\/h2>\n<p>\nUnder utviklingen av Helm 2 introduserte vi Tiller som en del av v\u00e5r integrasjon med Google sin Deployment Manager. Tiller spilte en viktig rolle for teamene som jobbet innenfor samme klynge: den tillot forskjellige spesialister som drifter infrastrukturen \u00e5 samhandle med det samme settet av utgivelser.<\/p>\n<p>Siden rollebasert tilgangskontroll (RBAC) var som standard aktivert i Kubernetes 1.6, ble det mer komplisert \u00e5 jobbe med Tiller i produksjon. P\u00e5 grunn av det enorme antallet mulige sikkerhetspolicyer var v\u00e5r tiln\u00e6rming \u00e5 tilby en tillatende konfigurasjon som standard. Dette tillot nybegynnere \u00e5 eksperimentere med Helm og Kubernetes uten \u00e5 m\u00e5tte dykke ned i sikkerhetsinnstillinger f\u00f8rst. Dessverre kunne denne tillatende konfigurasjonen gi brukeren for brede tillatelser som de ikke trengte. DevOps- og SRE-ingeni\u00f8rer m\u00e5tte l\u00e6re seg ekstra driftssteg for \u00e5 installere Tiller i en flerbruker-klynge.<\/p>\n<p>Etter \u00e5 ha forst\u00e5tt hvordan representanter fra fellesskapet bruker Helm i spesifikke situasjoner, inns\u00e5 vi at systemet for utgivelsesadministrasjon for Tiller ikke trengte \u00e5 v\u00e6re avhengig av en intern klyngekomponent for \u00e5 opprettholde tilstander eller fungere som et sentralt knutepunkt for informasjon om utgivelser. I stedet kunne vi ganske enkelt hente informasjon fra Kubernetes API-serveren, generere diagram p\u00e5 klientsiden og lagre installasjonsoppf\u00f8ringen i Kubernetes.<\/p>\n<p>Hovedoppgaven til Tiller kunne ogs\u00e5 utf\u00f8res uten Tiller, s\u00e5 et av v\u00e5re f\u00f8rste beslutninger ang\u00e5ende Helm 3 var \u00e5 fullstendig avskaffe Tiller.<\/p>\n<p>Med Tiller sin avgang ble sikkerhetsmodellen til Helm radikalt forenklet. Helm 3 st\u00f8tter n\u00e5 alle moderne metoder for sikkerhet, identifisering og autorisering i den n\u00e5v\u00e6rende Kubernetes. Tillatelser for Helm defineres ved hjelp av <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/configuration\/organize-cluster-access-kubeconfig\/\">kubeconfig-filen.<\/a><\/noindex>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.<\/p>\n<h2>Chart-repositorier<\/h2>\n<p>\nP\u00e5 et h\u00f8yt niv\u00e5 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.<\/p>\n<p>Selv om det er noen fordeler med at API-et til chart-repositoriet m\u00f8ter de mest grunnleggende kravene til lagring, har det ogs\u00e5 noen ulemper:<\/p>\n<ul>\n<li> Chart-repositorier er d\u00e5rlig kompatible med de fleste sikkerhetsimplementasjoner som er n\u00f8dvendige i produksjonsmilj\u00f8er. Tilstedev\u00e6relsen av et standard API for autentisering og autorisasjon er avgj\u00f8rende i produksjonsscenarier.<\/li>\n<li> Helm-verkt\u00f8yene for sporing av opprinnelse av charts, brukt for signering, integritetskontroll og opprinnelse av charts, er en valgfri del av Chart-publiseringsprosessen.<\/li>\n<li> 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 \u00e5 l\u00f8se dette problemet har smartere repositorier blitt utviklet, men de er ikke en del av den formelle spesifikasjonen.<\/li>\n<li> Bruken av en enkelt indeksfil for \u00e5 s\u00f8ke, lagre metadata og hente charts har komplisert utviklingen av sikre flerbruksimplementasjoner.<\/li>\n<\/ul>\n<p>\nProsjekt <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/docker\/distribution\">Docker Distribution<\/a><\/noindex> (ogs\u00e5 kjent som Docker Registry v2) er etterf\u00f8lgeren til Docker Registry og fungerer faktisk som et verkt\u00f8ysett for \u00e5 pakke, sende, lagre og distribuere Docker-bilder. Mange store skytjenester tilbyr produkter basert p\u00e5 Distribution. Takket v\u00e6re denne \u00f8kte oppmerksomheten har Distribution-prosjektet dratt nytte av mange \u00e5rs forbedringer, beste praksis innen sikkerhet og testing i \"kamp\"-milj\u00f8er, noe som har gjort det til en av de mest suksessrike usungne heltene i Open Source-verdenen.<\/p>\n<p>Men visste du at Distribution-prosjektet ble utviklet for \u00e5 distribuere enhver form for innhold, ikke bare containere?<\/p>\n<p>Takket v\u00e6re innsatsen til <noindex><a rel=\"nofollow\" href=\"https:\/\/www.opencontainers.org\/\">Open Container Initiative<\/a><\/noindex> (eller OCI) kan Helm-charts plasseres p\u00e5 enhver instans av Distribution. S\u00e5 langt er denne prosessen eksperimentell. Arbeidet med \u00e5 st\u00f8tte p\u00e5logging og andre funksjoner som er n\u00f8dvendig for en fullverdig Helm 3, er fortsatt ikke avsluttet, men vi er veldig glade for muligheten til \u00e5 l\u00e6re av oppdagelsene gjort av OCI- og Distribution-teamene i \u00e5renes l\u00f8p. Og takket v\u00e6re deres veiledning l\u00e6rer vi hva det vil si \u00e5 drifte en h\u00f8yt tilgjengelig tjeneste i stor skala.<\/p>\n<p>En mer detaljert beskrivelse av noen kommende endringer i Helm-chart-repositoriene er tilgjengelig <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.bacongobbler.com\/post\/2019-01-25-distributing-with-distribution\/\">via lenken<\/a><\/noindex>.<\/p>\n<h2>Utgivelsesadministrasjon<\/h2>\n<p>\nI Helm 3 spores applikasjonsstatus innen klyngen av et par objekter:<\/p>\n<ul>\n<li> release object \u2014 representerer en instans av applikasjonen;<\/li>\n<li> release version secret \u2014 representerer \u00f8nsket tilstand av applikasjonen p\u00e5 et bestemt tidspunkt (for eksempel utgivelsen av en ny versjon).<\/li>\n<\/ul>\n<p>\nKall <code>helm install<\/code> oppretter release object og release version secret. Kall <code>helm upgrade<\/code> krever eksistensen av release object (som den kan endre) og oppretter en ny release version secret som inneholder nye verdier og en forberedt manifest.<\/p>\n<p>Release-objektet inneholder informasjon om utgivelsen, hvor utgivelsen er en spesifikk installasjon av en navngitt chart og verdier. Dette objektet beskriver metadata om utgivelsen p\u00e5 et overordnet niv\u00e5. Release-objektet beholdes gjennom hele livssyklusen til applikasjonen og fungerer som eier av alle release version secrets, samt alle objekter som opprettes direkte av Helm-chartet.<\/p>\n<p>Release version secret binder utgivelsen til en serie revisjoner (installasjon, oppdateringer, tilbaketrekning, sletting).<\/p>\n<p>I Helm 2 var revisjoner utelukkende sekvensielle. Kall <code>helm install<\/code> Opprettet v1, p\u00e5f\u00f8lgende oppgradering (upgrade) \u2014 v2, og s\u00e5 videre. Release og release version secret ble sl\u00e5tt sammen til ett objekt, kjent som revision. Revisionene ble lagret i samme navnerom som Tiller, noe som betydde at hver utgivelse var 'global' i forhold til navnerom; som et resultat kunne man bruke bare \u00e9n instans av navnet.<\/p>\n<p>I Helm 3 er hver utgivelse knyttet til en eller flere release version secrets. Release-objektet beskriver alltid den n\u00e5v\u00e6rende utgivelsen som er distribuert i Kubernetes. Hver release version secret beskriver bare \u00e9n versjon av denne utgivelsen. Oppgradering (upgrade), for eksempel, vil opprette en ny release version secret og deretter endre release-objektet slik at det peker p\u00e5 denne nye versjonen. Ved tilbakestilling (rollback) kan tidligere release version secrets brukes for \u00e5 rulle tilbake utgivelsen til en tidligere tilstand.<\/p>\n<p>Etter avvik fra Tiller lagrer Helm 3 data om utgivelsen i det samme navnerommet som utgivelsen. Denne endringen muliggj\u00f8r installasjon av et chart med samme navn p\u00e5 utgivelsen i et annet navnerom, og dataene forblir bevart mellom oppdateringer\/restarter av klyngen i etcd. For eksempel kan man installere WordPress i navnerommet 'foo' og deretter i navnerommet 'bar', og begge utgivelsene kan kalles 'wordpress'.<\/p>\n<h2>Endringer i chart-avhengigheter<\/h2>\n<p>\nCharts pakket (ved hjelp av <code>helm package<\/code>) 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.<\/p>\n<p>The chart dependency management system has transitioned from <code>requirements.yaml<\/code> og <code>requirements.lock<\/code> En funksjon har blitt <code>Chart.yaml<\/code> og <code>Chart.lock<\/code>. This means that the charts that used the command <code>helm dependency<\/code>, require some configuration to work in Helm 3.<\/p>\n<p>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.<\/p>\n<p>In Helm 2 <code>requirements.yaml<\/code> it looked like this:<\/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>\nIn Helm 3, the same dependency will be reflected in your <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 are still loaded and placed in the directory <code>charts\/<\/code>, so the subcharts <i>(subcharts)<\/i>, located in the directory <code>charts\/<\/code>, will continue to work unchanged.<\/p>\n<h2>Introducing Library Charts<\/h2>\n<p>\nHelm 3 supports a class of charts called library charts <i>(library chart)<\/i>. Dette chartet brukes av andre charts, men skaper ikke selv noen utgivelsesartefakter. Malene til library charts kan kun deklarere elementer. <code>define<\/code>. 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 <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Don%27t_repeat_yourself\">DRY<\/a><\/noindex>.<\/p>\n<p>Library charts are declared in the section <code>avhengigheter<\/code> in the file <code>Chart.yaml<\/code>. Installing and managing them is not different from other charts.<\/p>\n<pre><code class=\"plaintext\">dependencies:\n  - name: mylib\n    version: 1.x.x\n    repository: quay.io<\/code><\/pre>\n<p>\nWe 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.<\/p>\n<h2>Hva skjer videre?<\/h2>\n<p>\nHelm 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.<\/p>\n<p>Once the alpha version is released <i>(let's remember that this <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/helm\/helm\/releases\/tag\/v3.0.0-alpha.1\">has already happened<\/a><\/noindex> \u2013 obs. overs.)<\/i>, vi begynner \u00e5 akseptere patches for Helm 3 fra fellesskapet. Det er n\u00f8dvendig \u00e5 skape et solid grunnlag som tillater utvikling og aksept av nye funksjoner, samtidig som brukerne kan f\u00f8le seg involvert i prosessen ved \u00e5 \u00e5pne billetter og bidra med rettelser.<\/p>\n<p>I artikkelen har jeg fors\u00f8kt \u00e5 belyse noen betydelige forbedringer som vil komme i Helm 3, men denne listen kan absolutt ikke kalles utt\u00f8mmende. 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\u00e5 \u00e5 rydde opp i kodebasen og oppdatere de delene som har v\u00e6rt neglisjert de siste tre \u00e5rene.<\/p>\n<p>Hvis du mener vi har oversett noe, vil vi gjerne h\u00f8re tankene dine!<\/p>\n<p>Bli med i diskusjonen i v\u00e5re <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.slack.com\/\">Slack-kanaler<\/a><\/noindex>:<\/p>\n<ul>\n<li> <code>#helm-users<\/code> for sp\u00f8rsm\u00e5l og generell kommunikasjon med fellesskapet;<\/li>\n<li> <code>#helm-dev<\/code> for diskusjon av pull requests, kode og feil.<\/li>\n<\/ul>\n<p>\nDu kan ogs\u00e5 chatte i v\u00e5re ukentlige Public Developer Calls p\u00e5 torsdager kl 19:30 MSK. M\u00f8tene er viet til diskusjon av oppgaver som n\u00f8kkelutviklere og fellesskapet jobber med, samt ukens diskusjonstemaer. Alle er velkomne til \u00e5 delta p\u00e5 m\u00f8tet. Lenken er tilgjengelig i Slack-kanalen <code>#helm-dev<\/code>.<\/p>\n<h2>P.S. from the translator<\/h2>\n<p>\nAlso read in our blog:<\/p>\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/417079\/\">Pakkeh\u00e5ndterer for Kubernetes \u2014 Helm: fortid, n\u00e5tid, fremtid<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/438814\/\">Et n\u00f8kternt blikk p\u00e5 Helm 2: 'Slik som det er...'<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/420437\/\">Praktisk introduksjon til pakkeh\u00e5ndtereren 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: oversette kj\u00f8rende ressurser i klyngen til 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. Distribusjon av Docker-bilder i Kubernetes ved hjelp av 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.5 - 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\/no\/blog\/administrirovanie\/znakomstvo-s-helm-3\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.5\" \/>\n\t\t<meta property=\"og:locale\" content=\"nn_NO\" \/>\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\/no\/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\udd47Innledning til Helm 3 | ProHoster","description":"Note.","canonical_url":"https:\/\/prohoster.info\/no\/blog\/administrirovanie\/znakomstvo-s-helm-3","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"nn_NO","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\/no\/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\/no\/wp-json\/wp\/v2\/posts\/34735","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/comments?post=34735"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/posts\/34735\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/media\/26173"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/media?parent=34735"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/categories?post=34735"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/tags?post=34735"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}