{"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\/it\/blog\/administrirovanie\/znakomstvo-s-helm-3","title":{"rendered":"Introduzione a Helm 3","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Introduzione a Helm 3\" src=\"\/wp-content\/uploads\/2019\/05\/6de0e2887ddcc802f1dd71c902325401.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<i><b>Nota del traduttore.<\/b>: il 16 maggio di quest'anno segna una tappa significativa nello sviluppo del gestore di pacchetti per Kubernetes: Helm. In questo giorno \u00e8 stata presentata la prima versione alpha della prossima grande versione del progetto \u2014 3.0. Il suo rilascio porter\u00e0 cambiamenti sostanziali e tanto attesi in Helm, su cui molti nel community di Kubernetes nutrono grandi speranze. Noi stessi facciamo parte di questi poich\u00e9 utilizziamo attivamente Helm per il deployment delle applicazioni: lo abbiamo integrato nel nostro strumento per l'implementazione del CI\/CD. <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\">werf<\/a><\/noindex> E di volta in volta contribuiamo nello sviluppo upstream. Questa traduzione raccoglie 7 note dal blog ufficiale di Helm, in occasione del primo rilascio alpha di Helm 3, che raccontano la storia del progetto e le principali caratteristiche di Helm 3. L'autore \u00e8 Matt \u00abbacongobbler\u00bb Fisher, dipendente di Microsoft e uno dei principali manutentori di Helm.<\/i><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>Il progetto ora conosciuto come Helm \u00e8 nato il 15 ottobre 2015. Solo un anno dopo la sua creazione, la community di Helm si \u00e8 unita a Kubernetes, lavorando attivamente su Helm 2. A giugno 2018, Helm <noindex><a rel=\"nofollow\" href=\"https:\/\/www.cncf.io\/blog\/2018\/06\/01\/cncf-to-host-helm\/\">\u00e8 entrato a far parte della CNCF<\/a><\/noindex> come progetto in incubazione. Voltiamo lo sguardo al presente \u2014 ecco che si avvicina il primo rilascio alpha del nuovo Helm 3 <i>(questo rilascio <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/helm\/helm\/releases\/tag\/v3.0.0-alpha.1\">\u00e8 gi\u00e0 avvenuto<\/a><\/noindex> a met\u00e0 maggio \u2014 nota del traduttore)<\/i>.<\/p>\n<p>In questo articolo parler\u00f2 di come \u00e8 iniziata la storia, come siamo arrivati all'attuale stadio, presenter\u00f2 alcune caratteristiche uniche disponibili nella prima alpha release di Helm 3 e spiegher\u00f2 come intendiamo svilupparci in futuro.<\/p>\n<p>Sintesi:<\/p>\n<ul>\n<li>la storia di Helm;<\/li>\n<li>un dolce addio a Tiller<\/li>\n<li>repository dei chart;<\/li>\n<li>gestione delle release;<\/li>\n<li>modifiche alle dipendenze dei chart;<\/li>\n<li>library charts;<\/li>\n<li>E poi?<\/li>\n<\/ul>\n<p><\/p>\n<h2>La storia di Helm<\/h2>\n<p><\/p>\n<h3>Nascita<\/h3>\n<p>\nHelm 1 \u00e8 nato come progetto Open Source creato da Deis. Eravamo una piccola startup, <noindex><a rel=\"nofollow\" href=\"https:\/\/blogs.microsoft.com\/blog\/2017\/04\/10\/microsoft-acquire-deis-help-companies-innovate-containers\/\">acquisita<\/a><\/noindex> da Microsoft nella primavera del 2017. Un altro nostro progetto Open Source, anch'esso chiamato Deis, aveva uno strumento <code>deisctl<\/code>, utilizzato (tra le altre cose) per installare e gestire la piattaforma Deis in <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/coreos\/fleet\">un cluster Fleet.<\/a><\/noindex>All'epoca, Fleet era una delle prime piattaforme per l'orchestrazione dei container.<\/p>\n<p>A met\u00e0 del 2015 abbiamo deciso di cambiare rotta e abbiamo migrato Deis (all'epoca rinominato Deis Workflow) da Fleet a Kubernetes. Tra i primi strumenti a essere riprogettato, c'era quello dell'installazione. <code>deisctl<\/code>Lo abbiamo utilizzato per l'installazione e la gestione di Deis Workflow in un cluster Fleet.<\/p>\n<p>Helm 1 \u00e8 stato creato sulla falsariga di noti gestori di pacchetti, come Homebrew, apt e yum. Il suo obiettivo principale era semplificare compiti come il pacchettizzazione e l'installazione di applicazioni in Kubernetes. Helm \u00e8 stato ufficialmente presentato nel 2015 alla conferenza KubeCon a San Francisco.<\/p>\n<p>Il nostro primo tentativo con Helm ha avuto successo, ma non \u00e8 stato privo di seri limiti. Utilizzava un insieme di manifesti Kubernetes, arricchiti da generatori come input in blocchi YAML. <i>(front-matter)<\/i>*, e caricava i risultati in Kubernetes.<\/p>\n<p><i>* <b>Nota del traduttore.<\/b>: Con la prima versione di Helm \u00e8 stato scelto il sintassi YAML per descrivere le risorse Kubernetes, e durante la scrittura delle configurazioni venivano supportati modelli Jinja e script Python. Abbiamo discusso di pi\u00f9 su questo e sull'architettura della prima versione di Helm nel capitolo \"Breve storia di Helm\". <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/417079\/\">di questo materiale<\/a><\/noindex>.<\/i><\/p>\n<p>Ad esempio, per sostituire un campo in un file YAML, era necessario aggiungere nel manifesto la seguente costruzione:<\/p>\n<pre><code class=\"plaintext\">#helm:generate sed -i -e s|ubuntu-debootstrap|fluffy-bunny| my\/pod.yaml<\/code><\/pre>\n<p>\n\u00c8 fantastico che oggi esistano i generatori di modelli, vero?<\/p>\n<p>Per molti motivi, questo primo installatore di Kubernetes richiedeva un elenco fisso di file manifest e seguiva solo una piccola sequenza di eventi. Era cos\u00ec difficile da usare che il team R&amp;D di Deis Workflow ha avuto non pochi problemi quando ha cercato di migrare il proprio prodotto su questa piattaforma; tuttavia, i semi dell'idea erano gi\u00e0 stati piantati. Il nostro primo tentativo \u00e8 stato un'opportunit\u00e0 preziosa per apprendere: abbiamo capito di essere davvero appassionati di creare strumenti pragmatici che risolvano i problemi quotidiani dei nostri utenti.<\/p>\n<p>Basandoci sull'esperienza degli errori passati, abbiamo iniziato a sviluppare Helm 2.<\/p>\n<h3>Creazione di Helm 2<\/h3>\n<p>\nAlla fine del 2015, ci ha contattati il team di Google. Stavano lavorando a uno strumento simile per Kubernetes. Deployment Manager per Kubernetes era un porting di uno strumento esistente utilizzato per Google Cloud Platform. \"Non vogliamo dedicarci alcuni giorni per discutere somiglianze e differenze?\"<\/p>\n<p>Nel gennaio 2016, i team di Helm e Deployment Manager si sono incontrati a Seattle per scambiarsi idee. I colloqui si sono conclusi con un piano ambizioso: unire entrambi i progetti per creare Helm 2. Insieme a Deis e Google, si sono uniti al team di sviluppo i ragazzi di <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/skippbox\">SkippBox<\/a><\/noindex> <i>(ora parte di Bitnami \u2014 nota del traduttore)<\/i>, e abbiamo iniziato a lavorare su Helm 2.<\/p>\n<p>Volevamo mantenere la facilit\u00e0 d'uso di Helm, ma aggiungere quanto segue:<\/p>\n<ul>\n<li> modelli di chart per la personalizzazione;<\/li>\n<li> gestione intra-cluster per i team;<\/li>\n<li> un repository di chart di prima classe;<\/li>\n<li> un formato di pacchetto stabile con supporto per la firma;<\/li>\n<li> un forte impegno per il versioning semantico e il mantenimento della compatibilit\u00e0 retroattiva tra le versioni.<\/li>\n<\/ul>\n<p>\nPer raggiungere questi obiettivi, \u00e8 stato aggiunto un secondo elemento all'ecosistema di Helm. Questo componente intra-cluster si chiamava Tiller e si occupava dell'installazione e della gestione dei chart di Helm.<\/p>\n<p>Dalla sua uscita, Helm 2 ha visto Kubernetes crescere con importanti innovazioni. \u00c8 stata introdotta la gestione degli accessi basata sui ruoli (<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/422801\/\">RBAC<\/a><\/noindex>), che alla fine ha sostituito il controllo accessi basato su attributi (ABAC). Sono stati introdotti nuovi tipi di risorse (i Deployments erano ancora in fase beta). Sono state inventate le Custom Resource Definitions (inizialmente chiamate Third Party Resources o TPR). E soprattutto, \u00e8 emerso un insieme di best practices.<\/p>\n<p>Nel contesto di tutti questi cambiamenti, Helm ha continuato a servire diligentemente gli utenti di Kubernetes. Dopo tre anni e numerosi nuovi aggiornamenti, \u00e8 diventato chiaro che era il momento di apportare modifiche sostanziali alla base di codice, affinch\u00e9 Helm potesse continuare a soddisfare le crescenti esigenze dell'ecosistema in evoluzione.<\/p>\n<h2>Dolce addio a Tiller<\/h2>\n<p>\nDurante lo sviluppo di Helm 2, abbiamo presentato Tiller come parte della nostra integrazione con il Deployment Manager di Google. Tiller ha svolto un ruolo cruciale per i team che operano all'interno dello stesso cluster: consentiva ai vari specialisti che gestivano l'infrastruttura di interagire con lo stesso set di rilascio.<\/p>\n<p>Poich\u00e9 il controllo degli accessi basato sui ruoli (RBAC) \u00e8 stato abilitato per impostazione predefinita in Kubernetes 1.6, lavorare con Tiller in produzione \u00e8 diventato pi\u00f9 complesso. A causa dell'enorme numero di possibili politiche di sicurezza, la nostra posizione era quella di offrire per impostazione predefinita una configurazione permissiva. Ci\u00f2 consentiva ai principianti di sperimentare con Helm e Kubernetes senza dover prima immergersi nelle impostazioni di sicurezza. Sfortunatamente, questa configurazione permissiva poteva conferire all'utente un intervallo di autorizzazioni troppo ampio, non necessarie per il suo uso. Gli ingegneri DevOps e SRE dovevano apprendere passaggi operativi aggiuntivi per installare Tiller in un cluster multi-tenant.<\/p>\n<p>Scoprendo come i membri della comunit\u00e0 utilizzano Helm in situazioni specifiche, abbiamo compreso che il sistema di gestione delle versioni di Tiller non ha bisogno di dipendere da un componente interno al cluster per mantenere gli stati o operare come hub centrale per le informazioni sulle versioni. Invece, potremmo semplicemente recuperare le informazioni dall'API server di Kubernetes, generare il chart lato client e mantenere un record dell'installazione in Kubernetes.<\/p>\n<p>La funzione principale di Tiller poteva essere realizzata anche senza Tiller, quindi una delle nostre prime decisioni riguardo a Helm 3 \u00e8 stata l'abbandono totale di Tiller.<\/p>\n<p>Con l'uscita di Tiller, il modello di sicurezza di Helm \u00e8 radicalmente semplificato. Helm 3 ora supporta tutte le moderne modalit\u00e0 di sicurezza, identificazione e autorizzazione dell'attuale Kubernetes. I permessi di Helm sono definiti tramite <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/configuration\/organize-cluster-access-kubeconfig\/\">il file kubeconfig.<\/a><\/noindex>Gli amministratori del cluster possono limitare i diritti degli utenti con qualsiasi livello di dettaglio. Le release continuano a essere mantenute all'interno del cluster, mentre il resto della funzionalit\u00e0 di Helm rimane.<\/p>\n<h2>I repository dei chart<\/h2>\n<p>\nA un livello elevato, il repository dei chart \u00e8 il luogo in cui archiviare e condividere i chart. Il client Helm impacchetta e invia i chart al repository. In parole semplici, il repository dei chart \u00e8 un server HTTP primitivo con un file index.yaml e alcuni chart impacchettati.<\/p>\n<p>Sebbene ci siano alcuni vantaggi nel fatto che l'API del repository dei chart risponda ai requisiti fondamentali di archiviazione, presenta anche diversi svantaggi:<\/p>\n<ul>\n<li> I repository dei chart sono poco compatibili con la maggior parte delle implementazioni di sicurezza necessarie in un ambiente di produzione. \u00c8 fondamentale avere un'API standard per l'autenticazione e l'autorizzazione in scenari di produzione.<\/li>\n<li> Gli strumenti di Helm per il tracciamento dell'origine del chart, utilizzati per la firma, la verifica dell'integrit\u00e0 e l'origine del chart, sono una parte facoltativa del processo di pubblicazione del Chart.<\/li>\n<li> Nei scenari multiutente, lo stesso chart pu\u00f2 essere caricato da un altro utente, raddoppiando lo spazio necessario per memorizzare lo stesso contenuto. Per affrontare questo problema, sono state sviluppate soluzioni di repository pi\u00f9 intelligenti, tuttavia queste non fanno parte della specifica formale.<\/li>\n<li> L'uso di un unico file indice per la ricerca, la memorizzazione dei metadati e il recupero dei chart ha complicato lo sviluppo di implementazioni multiutente sicure.<\/li>\n<\/ul>\n<p>\nProgetto <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/docker\/distribution\">Docker Distribution<\/a><\/noindex> (noto anche come Docker Registry v2) \u00e8 il successore di Docker Registry e funge essenzialmente da insieme di strumenti per imballare, inviare, memorizzare e fornire immagini Docker. Molti grandi servizi cloud offrono prodotti basati su Distribution. Grazie a questa maggiore attenzione, il progetto Distribution ha beneficiato di anni di miglioramenti, delle migliori pratiche in materia di sicurezza e di test in condizioni \"reali\", diventando uno degli eroi non celebrati pi\u00f9 di successo nel mondo dell'Open Source.<\/p>\n<p>Ma sapevate che il progetto Distribution \u00e8 stato concepito per distribuire qualsiasi forma di contenuto, e non solo immagini dei contenitori?<\/p>\n<p>Grazie agli sforzi <noindex><a rel=\"nofollow\" href=\"https:\/\/www.opencontainers.org\/\">Open Container Initiative<\/a><\/noindex> (o OCI), i chart di Helm possono essere ospitati su qualsiasi istanza di Distribution. Sebbene questo processo sia ancora sperimentale. Il lavoro per supportare i login e altre funzionalit\u00e0 necessarie per un completo Helm 3 non \u00e8 ancora terminato, ma siamo molto lieti di poter apprendere dalle scoperte fatte dai team di OCI e Distribution nel corso degli anni. E grazie alla loro mentorship e guida, stiamo imparando cosa significhi gestire un servizio ad alta disponibilit\u00e0 su larga scala.<\/p>\n<p>Una descrizione pi\u00f9 dettagliata di alcune delle modifiche imminenti nei repository dei chart di Helm \u00e8 disponibile <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.bacongobbler.com\/post\/2019-01-25-distributing-with-distribution\/\">al link<\/a><\/noindex>.<\/p>\n<h2>Gestione delle release<\/h2>\n<p>\nIn Helm 3, lo stato dell'applicazione \u00e8 tracciato all'interno del cluster da una coppia di oggetti:<\/p>\n<ul>\n<li> release object \u2014 rappresenta un'istanza dell'applicazione;<\/li>\n<li> release version secret \u2014 rappresenta lo stato desiderato dell'applicazione in un determinato momento (ad esempio, il rilascio di una nuova versione).<\/li>\n<\/ul>\n<p>\nLa chiamata <code>helm install<\/code> crea release object e release version secret. La chiamata <code>helm upgrade<\/code> richiede l'esistenza di un release object (che pu\u00f2 modificare) e crea un nuovo release version secret contenente nuovi valori e un manifesto preparato.<\/p>\n<p>L'oggetto di rilascio contiene informazioni sul rilascio, dove il rilascio \u00e8 un'installazione specifica di un chart denominato e dei valori. Questo oggetto descrive i metadati di alto livello sul rilascio. L'oggetto di rilascio viene conservato per tutta la durata del ciclo di vita dell'applicazione e funge da proprietario di tutti i segreti delle versioni di rilascio, nonch\u00e9 di tutti gli oggetti creati direttamente dal chart di Helm.<\/p>\n<p>Il segreto della versione di rilascio collega il rilascio a una serie di revisioni (installazioni, aggiornamenti, rollback, eliminazione).<\/p>\n<p>In Helm 2, le revisioni erano esclusivamente sequenziali. La chiamata <code>helm install<\/code> ha creato v1, l'aggiornamento successivo (upgrade) \u00e8 stato v2, e cos\u00ec via. Il rilascio e il segreto della versione di rilascio sono stati combinati in un unico oggetto, noto come revisione. Le revisioni sono state conservate nello stesso namespace di Tiller, il che significava che ogni rilascio era \"globale\" in termini di namespace; di conseguenza, era possibile utilizzare solo un'istanza di un nome.<\/p>\n<p>In Helm 3, ogni rilascio \u00e8 associato a uno o pi\u00f9 release version secret. L'oggetto di rilascio descrive sempre l'attuale rilascio distribuito in Kubernetes. Ogni release version secret descrive solo una versione di questo rilascio. Un aggiornamento, ad esempio, creer\u00e0 un nuovo release version secret e poi aggiorner\u00e0 l'oggetto di rilascio per puntare a questa nuova versione. In caso di rollback, si possono utilizzare i release version secret precedenti per tornare allo stato precedente del rilascio.<\/p>\n<p>Dopo l'abbandono di Tiller, Helm 3 memorizza i dati del rilascio in uno spazio dei nomi unificato con il rilascio stesso. Questa modifica consente di installare un chart con lo stesso nome del rilascio in un altro spazio dei nomi, e i dati vengono mantenuti tra aggiornamenti\/ripristini del cluster in etcd. Ad esempio, \u00e8 possibile installare WordPress nello spazio dei nomi \"foo\" e poi in \"bar\", e entrambi i rilasci possono essere chiamati \"wordpress\".<\/p>\n<h2>Modifiche alle dipendenze dei chart<\/h2>\n<p>\nChart impacchettati (con <code>helm package<\/code>) per l'uso con Helm 2, \u00e8 possibile installare con Helm 3, tuttavia il processo di sviluppo dei chart \u00e8 stato completamente rivisto, quindi \u00e8 necessario apportare alcune modifiche per continuare lo sviluppo dei chart con Helm 3. In particolare, il sistema di gestione delle dipendenze dei chart \u00e8 cambiato.<\/p>\n<p>Il sistema di gestione delle dipendenze del chart \u00e8 passato da <code>requirements.yaml<\/code> e <code>requirements.lock<\/code> con <code>Chart.yaml<\/code> e <code>Chart.lock<\/code>. Questo significa che i chart che utilizzavano il comando <code>helm dependency<\/code>, richiedono alcune configurazioni per funzionare in Helm 3.<\/p>\n<p>Esaminiamo un esempio. Aggiungiamo una dipendenza al chart in Helm 2 e vediamo cosa cambia passando a Helm 3.<\/p>\n<p>In Helm 2 <code>requirements.yaml<\/code> si presentava come segue:<\/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 la stessa dipendenza sar\u00e0 riflessa nel tuo <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>\nI chart vengono ancora caricati e posizionati nella directory <code>charts\/<\/code>, quindi i subchart <i>(subcharts)<\/i>, presenti nella cartella <code>charts\/<\/code>, continueranno a funzionare senza modifiche.<\/p>\n<h2>Presentazione dei Library Charts<\/h2>\n<p>\nHelm 3 supporta una classe di chart chiamata chart di libreria <i>(library chart)<\/i>. Questo chart \u00e8 utilizzato da altri chart, ma non crea autonomamente alcun artefatto di rilascio. I modelli dei library chart possono dichiarare solo elementi <code>definire<\/code>. Altro contenuto viene semplicemente ignorato. Questo permette agli utenti di riutilizzare e condividere frammenti di codice che possono essere impiegati in molti chart, evitando cos\u00ec duplicazioni e seguendo il principio <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Don%27t_repeat_yourself\">DRY<\/a><\/noindex>.<\/p>\n<p>I library chart sono dichiarati nella sezione <code>dependencies<\/code> nel file <code>Chart.yaml<\/code>. L'installazione e la gestione sono simili a quelle degli altri chart.<\/p>\n<pre><code class=\"plaintext\">dependencies:\n  - name: mylib\n    version: 1.x.x\n    repository: quay.io<\/code><\/pre>\n<p>\nSiamo entusiasti delle possibilit\u00e0 d'uso che questo componente offrir\u00e0 agli sviluppatori di chart, cos\u00ec come delle migliori pratiche che possono emergere grazie ai library chart.<\/p>\n<h2>E ora?<\/h2>\n<p>\nHelm 3.0.0-alpha.1 \u00e8 la base su cui iniziamo a costruire una nuova versione di Helm. In questo articolo ho descritto alcune interessanti funzionalit\u00e0 di Helm 3. Molte di esse sono ancora nelle fasi iniziali di sviluppo e va bene cos\u00ec; l'essenza di un rilascio alpha \u00e8 testare l'idea, raccogliere feedback dai primi utenti e confermare le nostre ipotesi.<\/p>\n<p>Una volta che la versione alpha sar\u00e0 rilasciata <i>(ricordiamo che questo <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/helm\/helm\/releases\/tag\/v3.0.0-alpha.1\">\u00e8 gi\u00e0 avvenuto<\/a><\/noindex> \u2014 nota di traduzione)<\/i>, inizieremo ad accettare patch per Helm 3 dalla comunit\u00e0. \u00c8 necessario creare una base solida che consenta di sviluppare e accettare nuove funzionalit\u00e0, e gli utenti potranno sentirsi coinvolti nel processo aprendo ticket e proponendo correzioni.<\/p>\n<p>Nell'articolo ho cercato di evidenziare alcuni dei miglioramenti significativi che arriveranno con Helm 3, ma questa lista non pu\u00f2 in alcun modo essere considerata esaustiva. Il piano completo per Helm 3 include innovazioni come strategie di aggiornamento migliorate, integrazione pi\u00f9 profonda con i registri OCI e uso di schemi JSON per la convalida dei valori dei chart. Prevediamo anche di ripulire la base di codice e aggiornare quelle parti che sono rimaste trascurate negli ultimi tre anni.<\/p>\n<p>Se pensi che ci sia qualcosa che abbiamo trascurato, saremo felici di sentire le tue opinioni!<\/p>\n<p>Unisciti alla discussione nei nostri <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.slack.com\/\">canali Slack<\/a><\/noindex>:<\/p>\n<ul>\n<li> <code>#helm-users<\/code> per domande e semplici conversazioni con la comunit\u00e0;<\/li>\n<li> <code>#helm-dev<\/code> per discutere di pull request, codice e bug.<\/li>\n<\/ul>\n<p>\nPuoi anche partecipare alle nostre Public Developer Calls settimanali ogni gioved\u00ec alle 19:30 MSK. Gli incontri sono dedicati alla discussione delle attivit\u00e0 su cui lavorano i principali sviluppatori e la comunit\u00e0, nonch\u00e9 ai temi da discutere durante la settimana. Chiunque pu\u00f2 unirsi e partecipare all'incontro. Il link \u00e8 disponibile nel canale Slack. <code>#helm-dev<\/code>.<\/p>\n<h2>P.S. dal traduttore<\/h2>\n<p>\nLeggete anche nel nostro blog:<\/p>\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/417079\/\">Il gestore di pacchetti per Kubernetes \u2014 Helm: passato, presente, futuro<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/438814\/\">Uno sguardo sobrio su Helm 2: \u201cEcco com'\u00e8\u2026\u201d<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/420437\/\">Introduzione pratica al gestore di pacchetti per Kubernetes \u2014 Helm<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/441964\/\">Consigli e trucchi per Kubernetes: tradurre le risorse funzionanti nel cluster sotto Helm 2<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/336170\/\">Pratica con dapp. Parte 2. Distribuzione di immagini Docker in Kubernetes usando Helm<\/a><\/noindex>\u00bb.<\/li>\n<\/ul>\n<p>Fonte: <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 4.9.10 - aioseo.com -->\n\t<meta name=\"description\" content=\"\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\" \/>\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\/it\/blog\/administrirovanie\/znakomstvo-s-helm-3\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 4.9.10\" \/>\n\t\t<meta property=\"og:locale\" content=\"it_IT\" \/>\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. \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\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/it\/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\udd47Introduzione a Helm 3 | ProHoster","description":"Nota del traduttore: il 16 maggio di quest'anno segna una tappa importante nello sviluppo del gestore di pacchetti per Kubernetes \u2014 Helm. In questa data \u00e8 stata presentata la prima versione alpha della futura grande release del progetto \u2014 3.0. La sua uscita porter\u00e0 cambiamenti significativi e attesi in Helm, su cui molti nel community Kubernetes ripongono grandi speranze. E noi stessi ci includiamo, poich\u00e9 siamo attivamente...","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/znakomstvo-s-helm-3","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","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. \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","og:url":"https:\/\/prohoster.info\/it\/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"},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/34735","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=34735"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/34735\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/26173"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=34735"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=34735"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=34735"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}