{"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 di traduzione.<\/b>: 16 maggio di quest'anno \u2014 una data importante nello sviluppo del gestore di pacchetti per Kubernetes \u2014 Helm. In questo giorno \u00e8 stato presentato il primo rilascio alpha della futura grande versione del progetto \u2014 3.0. Il suo lancio porter\u00e0 in Helm cambiamenti significativi e attesi da tempo, sui quali molte persone nella comunit\u00e0 Kubernetes ripongono grandi speranze. Ci consideriamo tra questi, poich\u00e9 utilizziamo attivamente Helm per il deployment delle applicazioni: lo abbiamo integrato nel nostro strumento per realizzare CI\/CD <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\">werf<\/a><\/noindex> e di tanto in tanto contribuiamo allo sviluppo upstream. Questa traduzione riunisce 7 articoli dal blog ufficiale di Helm, collegati al primo rilascio alpha di Helm 3 e che raccontano la storia del progetto e le principali caratteristiche di Helm 3. Il loro autore \u00e8 Matt \u00abbacongobbler\u00bb Fisher, dipendente Microsoft e uno dei principali maintainer di Helm.<\/i><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>Il 15 ottobre 2015 \u00e8 nato il progetto, oggi conosciuto come Helm. Solo un anno dopo la sua fondazione, la comunit\u00e0 di Helm si \u00e8 unita a Kubernetes, lavorando attivamente su Helm 2. Nel 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 del CNCF<\/a><\/noindex> come progetto incubante. Tornando al presente, 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 materiale parler\u00f2 di come tutto \u00e8 iniziato, come siamo arrivati all'attuale fase, presenter\u00f2 alcune caratteristiche uniche disponibili nel primo rilascio alpha di Helm 3 e spiegher\u00f2 come intendiamo svilupparci in futuro.<\/p>\n<p>Sommario:<\/p>\n<ul>\n<li>storia della creazione 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>cosa c'\u00e8 dopo?<\/li>\n<\/ul>\n<p><\/p>\n<h2>Storia della creazione di Helm<\/h2>\n<p><\/p>\n<h3>Nascita<\/h3>\n<p>\nHelm 1 \u00e8 iniziato come progetto Open Source, creato dall'azienda 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>Nel mezzo del 2015 abbiamo deciso di cambiare rotta e abbiamo migrato Deis (all'epoca rinominato in Deis Workflow) da Fleet a Kubernetes. Uno dei primi strumenti a essere rielaborato <code>deisctl<\/code>. Lo usavamo per installare e gestire Deis Workflow in un cluster Fleet.<\/p>\n<p>Helm 1 \u00e8 stato creato sull'esempio di noti gestori di pacchetti come Homebrew, apt e yum. Il suo obiettivo principale era semplificare compiti come l'imballaggio e l'installazione di applicazioni in Kubernetes. Helm \u00e8 stato presentato ufficialmente nel 2015 durante la conferenza KubeCon a San Francisco.<\/p>\n<p>Il nostro primo tentativo con Helm ha funzionato, ma non \u00e8 stato privo di seri limiti. Prelevava un insieme di manifesti Kubernetes, arricchiti da generatori come input YAML-blocchi <i>(front-matter)<\/i>*, e caricava i risultati in Kubernetes.<\/p>\n<p><i>* <b>Nota di traduzione.<\/b>: Dalla prima versione di Helm, \u00e8 stata scelta la sintassi YAML per descrivere le risorse Kubernetes e nell'elaborazione delle configurazioni venivano supportati modelli Jinja e script Python. Abbiamo scritto di pi\u00f9 su questo e sulla natura della prima versione di Helm nella sezione \"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 nel file YAML, era necessario aggiungere nel manifesto la seguente struttura:<\/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 motori di templating, non \u00e8 vero?<\/p>\n<p>Per molte ragioni, questo primo installer di Kubernetes richiedeva un elenco di file manifesto rigidamente definito e eseguiva solo una piccola sequenza fissa di eventi. Utilizzarlo era cos\u00ec difficile che al team R&amp;D di Deis Workflow \u00e8 andata male quando hanno cercato di migrare il loro prodotto a questa piattaforma; tuttavia, i semi dell'idea erano gi\u00e0 stati piantati. Il nostro primo tentativo \u00e8 stato un'ottima opportunit\u00e0 di apprendimento: abbiamo capito che eravamo davvero appassionati nella creazione di strumenti pragmatici che risolvono problemi quotidiani per i 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, il team di Google ci ha contattato. Stava lavorando a uno strumento simile per Kubernetes. Il Deployment Manager per Kubernetes era un porting di uno strumento esistente utilizzato per Google Cloud Platform. \"Non vogliamo passare qualche giorno a discutere delle somiglianze e delle 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 i due progetti per creare Helm 2. Insieme a Deis e Google, si sono uniti al team di sviluppatori ragazzi da <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 semplicit\u00e0 d'uso di Helm, ma aggiungere quanto segue:<\/p>\n<ul>\n<li> modelli di chart per la personalizzazione;<\/li>\n<li> gestione interna del cluster per i team;<\/li>\n<li> un repository di chart di prima classe;<\/li>\n<li> un formato di pacchetti stabile con firma possibile;<\/li>\n<li> un forte impegno per il versionamento semantico e per garantire la retrocompatibilit\u00e0 tra le versioni.<\/li>\n<\/ul>\n<p>\nPer raggiungere questi obiettivi, \u00e8 stato aggiunto un secondo elemento all'ecosistema Helm. Questo componente interno al cluster \u00e8 stato chiamato Tiller e si occupava dell'installazione e della gestione dei chart Helm.<\/p>\n<p>Sin dall'uscita di Helm 2 nel 2016, Kubernetes ha visto diverse innovazioni significative. \u00c8 stata implementata la gestione degli accessi basata sui ruoli (<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/422801\/\">RBAC<\/a><\/noindex>), che ha infine sostituito il controllo degli accessi basato sugli attributi (ABAC). Sono stati introdotti nuovi tipi di risorse (le Deployments erano ancora in beta all'epoca). Sono state ideate le Custom Resource Definitions (inizialmente chiamate Third Party Resources o TPR). E, soprattutto, \u00e8 emerso un set di best practice.<\/p>\n<p>Nel contesto di tutti questi cambiamenti, Helm ha continuato a servire con fedelt\u00e0 agli utenti di Kubernetes. Dopo tre anni e molte nuove aggiunte, \u00e8 diventato chiaro che era il momento di apportare modifiche significative alla base di codice affinch\u00e9 Helm potesse continuare a soddisfare le esigenze crescenti di un ecosistema in evoluzione.<\/p>\n<h2>Un 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 importante per i team che lavorano all'interno dello stesso cluster: permetteva a diversi specialisti che gestivano l'infrastruttura di interagire con lo stesso insieme di rilascio.<\/p>\n<p>Poich\u00e9 il controllo degli accessi basato sui ruoli (RBAC) era abilitato di default in Kubernetes 1.6, lavorare con Tiller in produzione diventava pi\u00f9 difficile. A causa dell'enorme numero di politiche di sicurezza possibili, la nostra posizione era quella di offrire una configurazione permissiva per impostazione predefinita. Questo consentiva ai neofiti di sperimentare con Helm e Kubernetes senza dover prima approfondire le impostazioni di sicurezza. Purtroppo, questa configurazione permissiva poteva conferire all'utente un'ampia gamma di permessi non necessari. Gli ingegneri DevOps e SRE dovevano apprendere ulteriori passaggi operativi per installare Tiller in un cluster multi-tenant.<\/p>\n<p>Scoprendo come i membri della community utilizzano Helm in situazioni specifiche, abbiamo capito che il sistema di gestione dei rilasci di Tiller non doveva fare affidamento su un componente intra-cluster per mantenere stati o funzionare come hub centrale con informazioni sul rilascio. Piuttosto, potevamo semplicemente ottenere informazioni dall'API server di Kubernetes, generare un chart lato client e mantenere un registro dell'installazione in Kubernetes.<\/p>\n<p>Il compito principale di Tiller poteva essere svolto anche senza di lui, quindi una delle prime decisioni che abbiamo preso riguardo Helm 3 \u00e8 stata l'eliminazione totale di Tiller.<\/p>\n<p>Con l'uscita di Tiller, il modello di sicurezza di Helm \u00e8 radicalmente semplificato. Helm 3 ora supporta tutti i moderni metodi 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\/\">file kubeconfig<\/a><\/noindex>. Gli amministratori del cluster possono limitare i diritti degli utenti con qualsiasi grado di dettaglio. Le release rimangono comunque memorizzate all'interno del cluster, e il resto della funzionalit\u00e0 di Helm viene mantenuta.<\/p>\n<h2>I repository dei chart<\/h2>\n<p>\nA un livello alto, un repository di chart \u00e8 un luogo dove \u00e8 possibile memorizzare e condividere i chart. Il client Helm imballa e invia i chart al repository. In parole semplici, un repository di chart \u00e8 un server HTTP primitivo con un file index.yaml e alcuni chart imballati.<\/p>\n<p>Sebbene ci siano alcuni vantaggi nel fatto che l'API del repository dei chart soddisfi i requisiti di base per lo storage, ha anche alcuni 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. Avere un'API standard per l'autenticazione e l'autorizzazione \u00e8 estremamente importante negli scenari di produzione.<\/li>\n<li> Gli strumenti di Helm per il tracciamento dell'origine dei chart, utilizzati per la firma, il controllo dell'integrit\u00e0 e l'origine dei chart, costituiscono una parte facoltativa del processo di pubblicazione del Chart.<\/li>\n<li> Negli 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 stati sviluppati repository pi\u00f9 intelligenti, ma non fanno parte della specifica formale.<\/li>\n<li> L'uso di un unico file indice per cercare, memorizzare metadati e ottenere chart ha complicato lo sviluppo di implementazioni sicure multiutente.<\/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 effettivamente da insieme di strumenti per impacchettare, inviare, memorizzare e distribuire immagini Docker. Molti grandi servizi cloud offrono prodotti basati su Distribution. Grazie a questa attenzione, il progetto Distribution ha beneficiato di anni di miglioramenti, migliori pratiche in materia di sicurezza e test in condizioni 'reali', trasformandolo in uno dei pi\u00f9 riusciti eroi non celebrati del mondo Open Source.<\/p>\n<p>Ma sapevate che il progetto Distribution \u00e8 stato sviluppato per distribuire qualsiasi forma di contenuto, e non solo immagini di 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. Finora, questo processo \u00e8 di natura sperimentale. Il lavoro per supportare il login e altre funzionalit\u00e0 necessarie per un completo Helm 3 non \u00e8 ancora concluso, ma siamo molto entusiasti di poter apprendere dalle scoperte fatte dai team OCI e Distribution negli anni. E grazie alla loro guida e mentorship, stiamo imparando cosa significa gestire un servizio ad alta disponibilit\u00e0 su larga scala.<\/p>\n<p>Una descrizione pi\u00f9 dettagliata di alcuni dei prossimi cambiamenti 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> l'oggetto release \u2014 rappresenta un'istanza dell'applicazione;<\/li>\n<li> release version secret \u2014 rappresenta lo stato desiderato dell'applicazione in un momento specifico (ad esempio, il rilascio di una nuova versione).<\/li>\n<\/ul>\n<p>\nChiamata <code>helm install<\/code> crea un oggetto di release e un segreto della versione di release. Chiamata <code>helm upgrade<\/code> richiede un oggetto di release (che pu\u00f2 modificare) e crea un nuovo segreto della versione di release, contenente nuovi valori e un manifesto preparato.<\/p>\n<p>L'oggetto Release contiene informazioni sul rilascio, dove il rilascio \u00e8 una specifica installazione di un chart nominato e dei suoi valori. Questo oggetto descrive i metadati di alto livello sul rilascio. L'oggetto Release viene conservato per l'intero ciclo di vita dell'applicazione e funge da proprietario di tutti i segreti della release version, cos\u00ec come di tutti gli oggetti direttamente creati dal chart Helm.<\/p>\n<p>Il segreto della versione di release collega la release a una serie di revisioni (installazione, aggiornamenti, rollback, rimozione).<\/p>\n<p>In Helm 2, le revisioni erano esclusivamente sequenziali. Chiamata <code>helm install<\/code> creava v1, il successivo aggiornamento (upgrade) era v2, e cos\u00ec via. L'oggetto Release e il segreto della release version sono stati fusi in un unico oggetto, noto come revisione. Le revisioni erano conservate nello stesso spazio dei nomi di Tiller, il che significava che ogni rilascio era \"globale\" in termini di spazio dei nomi; 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 segreti della release version. L'oggetto Release descrive sempre il rilascio attuale distribuito in Kubernetes. Ogni segreto della release version descrive solo una versione di quel rilascio. Un aggiornamento (upgrade), ad esempio, creer\u00e0 un nuovo segreto della release version e poi modificher\u00e0 l'oggetto Release per puntare a questa nuova versione. In caso di rollback, possono essere utilizzati i segreti della release version precedenti per ripristinare il rilascio allo stato precedente.<\/p>\n<p>Dopo l'abbandono di Tiller, Helm 3 conserva i dati del rilascio in uno spazio dei nomi unico associato al 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\/riavvii del cluster in etcd. Ad esempio, \u00e8 possibile installare WordPress nello spazio dei nomi \"foo\", e poi nello spazio dei nomi \"bar\", e entrambi i rilasci possono chiamarsi \"wordpress\".<\/p>\n<h2>Modifiche nelle dipendenze dei chart<\/h2>\n<p>\nChart impacchettati (con <code>helm package<\/code>) per l'uso con Helm 2, pu\u00f2 essere installato con Helm 3, tuttavia il flusso di lavoro per lo sviluppo dei chart \u00e8 stato completamente ristrutturato, quindi \u00e8 necessario apportare alcune modifiche per continuare a sviluppare i chart con Helm 3. In particolare, \u00e8 cambiato il sistema di gestione delle dipendenze dei chart.<\/p>\n<p>Il sistema di gestione delle dipendenze del chart \u00e8 passato a <code>requirements.yaml<\/code> e <code>requirements.lock<\/code> in <code>Chart.yaml<\/code> e <code>Chart.lock<\/code>. Questo significa che i chart che utilizzavano il comando <code>helm dependency<\/code>, richiedono qualche configurazione per funzionare in Helm 3.<\/p>\n<p>Esaminiamo un esempio. Aggiungiamo una dipendenza a un 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 continuano a essere scaricati e posizionati nella directory <code>charts\/<\/code>, quindi i subchart <i>(subcharts)<\/i>, che si trovano 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 template dei library chart possono dichiarare solo elementi <code>define<\/code>. Altri contenuti vengono semplicemente ignorati. Questo consente agli utenti di riutilizzare e condividere frammenti di codice che possono essere utilizzati in molti chart, evitando cos\u00ec duplicazioni e rispettando 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 di essi non differiscono da 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>\nNon vediamo l'ora di esplorare le possibilit\u00e0 che questo componente aprir\u00e0 per gli sviluppatori di chart, cos\u00ec come le migliori pratiche che potrebbero emergere grazie ai library chart.<\/p>\n<h2>Cosa succede dopo?<\/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 prime fasi di sviluppo ed \u00e8 normale; il senso di una versione alpha \u00e8 testare l'idea, raccogliere feedback dai primi utenti e confermare le nostre ipotesi.<\/p>\n<p>Non appena 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 accaduto<\/a><\/noindex> \u2014 nota del traduttore.)<\/i>, inizieremo a ricevere patch per Helm 3 dalla comunit\u00e0. \u00c8 necessario creare una base solida che permetta di sviluppare e integrare nuove funzionalit\u00e0, in modo che gli utenti possano sentirsi coinvolti nel processo, aprendo ticket e apportando correzioni.<\/p>\n<p>Nell'articolo ho cercato di evidenziare alcuni importanti miglioramenti che verranno introdotti in Helm 3, ma questo elenco non pu\u00f2 in alcun modo essere considerato esaustivo. Il piano completo per Helm 3 include innovazioni come strategie di aggiornamento migliorate, integrazione pi\u00f9 profonda con i registri OCI e utilizzo di schemi JSON per la validazione dei valori dei chart. Inoltre, prevediamo di ripulire il codice sorgente e aggiornare le sue parti che sono rimaste trascurate negli ultimi tre anni.<\/p>\n<p>Se senti che ci siamo persi qualcosa, saremo felici di conoscere 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 interazioni 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 gioved\u00ec alle 19:30 MSK. Gli incontri sono dedicati alla discussione delle attivit\u00e0 su cui stanno lavorando i principali sviluppatori e la comunit\u00e0, oltre ad argomenti di discussione per 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>\nLeggi 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 obiettivo a Helm 2: \u201cEcco com'\u00e8...\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 \u2013 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: traduzione delle risorse operative 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. Deploy di immagini Docker in Kubernetes utilizzando 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 5.0.2 - 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\/it\/blog\/administrirovanie\/znakomstvo-s-helm-3\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2\" \/>\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.\" \/>\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.","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.","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","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"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}]}}