{"id":35955,"date":"2019-10-31T22:08:26","date_gmt":"2019-10-31T19:08:26","guid":{"rendered":"https:\/\/prohoster.info\/blog\/razvertyvanie-prilozhenij-na-neskolkih-klasterah-kubernetes-s-helm\/"},"modified":"2019-10-31T22:08:26","modified_gmt":"2019-10-31T19:08:26","slug":"razvertyvanie-prilozhenij-na-neskolkih-klasterah-kubernetes-s-helm","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/razvertyvanie-prilozhenij-na-neskolkih-klasterah-kubernetes-s-helm","title":{"rendered":"Distribuzione di applicazioni su pi\u00f9 cluster Kubernetes con Helm","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<\/p>\n<p><\/p>\n<h2 id=\"kak-dailymotion-ispolzuet-kubernetes-razvertyvanie-prilozheniy\">Come Dailymotion utilizza Kubernetes: distribuzione delle applicazioni<\/h2>\n<p><\/p>\n<p>Noi di Dailymotion abbiamo iniziato a usare Kubernetes in produzione 3 anni fa. Tuttavia, distribuire applicazioni su pi\u00f9 cluster \u00e8 tutt'altro che semplice, quindi negli ultimi anni abbiamo cercato di migliorare i nostri strumenti e flussi di lavoro.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h3 id=\"s-chego-nachalos\">Da che cosa \u00e8 iniziato<\/h3>\n<p><\/p>\n<p>Qui spieghiamo come distribuiamo le nostre applicazioni su pi\u00f9 cluster Kubernetes in tutto il mondo.<\/p>\n<p><\/p>\n<p>Per distribuire pi\u00f9 oggetti Kubernetes contemporaneamente, usiamo <noindex><a rel=\"nofollow\" href=\"https:\/\/helm.sh\/\">Helm<\/a><\/noindex>, e tutti i nostri chart sono archiviati in un unico repository git. Per distribuire l'intero stack dell'applicazione composto da pi\u00f9 servizi, utilizziamo quello che chiamiamo un chart aggregato. Fondamentalmente, si tratta di un chart che dichiara le dipendenze e consente di inizializzare l'API e i suoi servizi con un solo comando.<\/p>\n<p><\/p>\n<p>Inoltre, abbiamo scritto un piccolo script Python sopra Helm per fare controlli, creare chart, aggiungere segreti e distribuire applicazioni. Tutte queste operazioni vengono eseguite su una piattaforma CI centrale utilizzando un'immagine docker.<\/p>\n<p><\/p>\n<p>Andiamo al sodo.<\/p>\n<p><\/p>\n<blockquote><p>Nota. Quando leggi questo, il primo release candidate di Helm 3 \u00e8 gi\u00e0 stato annunciato. La versione principale contiene un'intera serie di miglioramenti volti a risolvere alcuni problemi che abbiamo affrontato in passato.<\/p><\/blockquote>\n<p><\/p>\n<h3 id=\"rabochiy-process-razrabotki-chartov\">Flusso di lavoro per lo sviluppo dei chart<\/h3>\n<p><\/p>\n<p>Per le applicazioni utilizziamo il branching, e abbiamo deciso di applicare lo stesso approccio ai chart.<\/p>\n<p><\/p>\n<ul>\n<li>Il ramo <strong>dev<\/strong> viene utilizzato per creare chart che saranno testati sui cluster di sviluppo.<\/li>\n<li>Quando la pull request viene inviata a <strong>master<\/strong>, vengono controllate in staging.<\/li>\n<li>Infine, creiamo una pull request per trasferire le modifiche al ramo <strong>prod<\/strong> e applicarle in produzione.<\/li>\n<\/ul>\n<p><\/p>\n<p>Ogni ambiente ha il suo repository privato che conserva i nostri chart, e utilizziamo <noindex><a rel=\"nofollow\" href=\"https:\/\/chartmuseum.com\/\">Chartmuseum<\/a><\/noindex> con API molto utili. In questo modo garantiamo un'adeguata isolamento tra gli ambienti e la verifica dei chart in condizioni reali prima di utilizzarli in produzione.<\/p>\n<p><\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/habrastorage.org\/webt\/rz\/vt\/uk\/rzvtuk6q7b_rkeaxnyujzhmfjog.png\"><\/a><\/noindex><\/p>\n<p><\/p>\n<p><em>Repository di chart nei diversi ambienti<\/em><\/p>\n<p><\/p>\n<p>Vale la pena notare che quando gli sviluppatori inviano un ramo dev, la versione del loro chart viene automaticamente inviata a dev Chartmuseum. In questo modo, tutti gli sviluppatori utilizzano un unico repository dev, e \u00e8 fondamentale specificare accuratamente la propria versione del chart per non utilizzare accidentalmente modifiche di altri.<\/p>\n<p><\/p>\n<p>Inoltre, il nostro piccolo script Python verifica gli oggetti Kubernetes secondo le specifiche di Kubernetes OpenAPI utilizzando <noindex><a rel=\"nofollow\" href=\"https:\/\/kubeval.instrumenta.dev\/\">Kubeval<\/a><\/noindex>, prima di pubblicarli su Chartmusem.<\/p>\n<p><\/p>\n<h3 id=\"obschee-opisanie-rabochego-processa-razrabotki-charta\">Descrizione generale del flusso di lavoro per lo sviluppo del chart<\/h3>\n<p><\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/habrastorage.org\/webt\/yd\/cw\/qw\/ydcwqw-vqfitu5bj8ky4nh7xxea.png\"><\/a><\/noindex><\/p>\n<p><\/p>\n<ol>\n<li>Impostazione delle attivit\u00e0 della pipeline secondo le specifiche <noindex><a rel=\"nofollow\" href=\"https:\/\/gazr.io\/\">gazr.io<\/a><\/noindex> per il controllo qualit\u00e0 (lint, unit-test).<\/li>\n<li>Invio dell'immagine docker con strumenti Python, che distribuiscono le nostre applicazioni.<\/li>\n<li>Impostazione dell'ambiente in base al nome del ramo.<\/li>\n<li>Verifica dei file yaml Kubernetes utilizzando Kubeval.<\/li>\n<li>Aumento automatico della versione del chart e dei suoi chart parent (chart che dipendono dal chart modificato).<\/li>\n<li>Invio del chart a Chartmuseum, che corrisponde al suo ambiente<\/li>\n<\/ol>\n<p><\/p>\n<h2 id=\"upravlenie-razlichiyami-v-klasterah\">Gestione delle differenze nei cluster<\/h2>\n<p><\/p>\n<h3 id=\"federaciya-klasterov\">Federazione dei cluster<\/h3>\n<p><\/p>\n<p>C'era un tempo in cui usavamo <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/cluster-administration\/federation\/\">la federazione dei cluster Kubernetes<\/a><\/noindex>, dove era possibile dichiarare oggetti Kubernetes da un unico endpoint API. Ma sono emersi problemi. Ad esempio, alcuni oggetti Kubernetes non potevano essere creati nell'endpoint di federazione, quindi era difficile gestire oggetti aggregati e altri oggetti per singoli cluster.<\/p>\n<p><\/p>\n<p>Per risolvere il problema, abbiamo iniziato a gestire i cluster in modo indipendente, il che ha semplificato notevolmente il processo (abbiamo utilizzato la prima versione della federazione; nella seconda potrebbe essere cambiato qualcosa).<\/p>\n<p><\/p>\n<h3 id=\"georaspredelennaya-platforma\">Piattaforma geograficamente distribuita<\/h3>\n<p><\/p>\n<p>Attualmente, la nostra piattaforma \u00e8 distribuita in 6 regioni \u2014 3 localmente e 3 nel cloud.<\/p>\n<p><\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/habrastorage.org\/webt\/jq\/c1\/mr\/jqc1mru36g5byams4wddzducauw.png\"><\/a><\/noindex><br \/>\n<em>Distribuzione distribuita<\/em><\/p>\n<p><\/p>\n<h3 id=\"globalnye-znacheniya-helm\">Valori globali di Helm<\/h3>\n<p><\/p>\n<p>4 valori globali di Helm consentono di definire le differenze tra i cluster. Per tutti i nostri chart ci sono valori minimi predefiniti.<\/p>\n<p><\/p>\n<pre><code class=\"plaintext\">global:\n  cloud: True\n  env: staging\n  region: us-central1\n  clusterName: staging-us-central1<\/code><\/pre>\n<p><\/p>\n<p><em>Valori globali<\/em><\/p>\n<p><\/p>\n<p>Questi valori aiutano a definire il contesto per le nostre applicazioni e vengono utilizzati per diversi compiti: monitoraggio, tracciamento, registrazione, effettuare chiamate esterne, scalabilit\u00e0, ecc.<\/p>\n<p><\/p>\n<ul>\n<li>\u00abcloud\u00bb: abbiamo una piattaforma Kubernetes ibrida. Ad esempio, il nostro API \u00e8 distribuito nelle zone GCP e nei nostri datacenter.<\/li>\n<li>\u00abenv\u00bb: alcuni valori possono cambiare per gli ambienti non lavorativi. Ad esempio, definizioni delle risorse e configurazioni di autoscalamento.<\/li>\n<li>\u00abregion\u00bb: queste informazioni aiutano a definire la posizione del cluster e possono essere utilizzate per determinare i punti finali pi\u00f9 vicini per i servizi esterni.<\/li>\n<li>\u00abclusterName\u00bb: se e quando vogliamo definire un valore per un singolo cluster.<\/li>\n<\/ul>\n<p><\/p>\n<p>Ecco un esempio concreto:<\/p>\n<p><\/p>\n<pre><code class=\"plaintext\">{{\n\/* Restituisce il numero di repliche dell'Horizontal Pod Autoscaler per GraphQL *\/}}\n{{- define \"graphql.hpaReplicas\" -}}\n{{- if eq .Values.global.env \"prod\" }}\n{{- if eq .Values.global.region \"europe-west1\" }}\nminReplicas: 40\n{{- else }}\nminReplicas: 150\n{{- end }}\nmaxReplicas: 1400\n{{- else }}\nminReplicas: 4\nmaxReplicas: 20\n{{- end }}\n{{- end -}}<\/code><\/pre>\n<p><\/p>\n<p><em>Esempio di template Helm<\/em><\/p>\n<p><\/p>\n<p>Questa logica \u00e8 definita in un template ausiliario, per evitare di appesantire il YAML di Kubernetes.<\/p>\n<p><\/p>\n<h3 id=\"obyavlenie-prilozheniya\">Dichiarazione dell'applicazione<\/h3>\n<p><\/p>\n<p>I nostri strumenti di distribuzione si basano su diversi file YAML. Di seguito \u00e8 riportato un esempio di come dichiariamo il servizio e la sua topologia di scaling (numero di repliche) nel cluster.<\/p>\n<p><\/p>\n<pre><code class=\"plaintext\">releases:\n  - foo.world\n\nfoo.world:                # Nome della release\n  services:               # Elenco delle app\/progetti di dailymotion\n    foobar:\n      chart_name: foo-foobar\n      repo: git@github.com:dailymotion\/foobar\n      contexts:\n        prod-europe-west1:\n          deployments:\n            - name: foo-bar-baz\n              replicas: 18\n            - name: another-deployment\n              replicas: 3<\/code><\/pre>\n<p><\/p>\n<p><em>Definizione del servizio<\/em><\/p>\n<p><\/p>\n<p>Questa \u00e8 la schematizzazione di tutti i passaggi che definiscono il nostro flusso di lavoro di distribuzione. L'ultimo passaggio distribuisce l'applicazione simultaneamente su pi\u00f9 cluster di lavoro.<\/p>\n<p><\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/habrastorage.org\/webt\/iu\/qh\/xk\/iuqhxki4nfqoi0mus258j0feylu.png\"><\/a><\/noindex><br \/>\n<em>Passaggi di distribuzione in Jenkins<\/em><\/p>\n<p><\/p>\n<h3 id=\"a-sekrety\">E i segreti?<\/h3>\n<p><\/p>\n<p>Per quanto riguarda la sicurezza, monitoriamo tutti i segreti provenienti da diverse fonti e li conserviamo in uno storage unico <noindex><a rel=\"nofollow\" href=\"https:\/\/www.vaultproject.io\/\">Vault<\/a><\/noindex> a Parigi.<\/p>\n<p><\/p>\n<p>I nostri strumenti di distribuzione estraggono i valori dei segreti da Vault e, quando \u00e8 il momento della distribuzione, li inseriscono in Helm.<\/p>\n<p><\/p>\n<p>Per questo abbiamo definito una mappatura tra i segreti nel Vault e i segreti necessari alle nostre applicazioni:<\/p>\n<p><\/p>\n<pre><code class=\"plaintext\">segreti:                                                                                                                                                                                                        \n     - secret_id: \"stack1-app1-password\"                                                                                                                                                                                  \n       contesti:                                                                                                                                                                                                   \n         - nome: \"default\"                                                                                                                                                                                         \n           vaultPath: \"\\\/kv\\\/dev\\\/stack1\\\/app1\\\/test\"                                                                                                                                                               \n           vaultKey: \"password\"                                                                                                                                                                                    \n         - nome: \"cluster1\"                                                                                                                                                                           \n           vaultPath: \"\\\/kv\\\/dev\\\/stack1\\\/app1\\\/test\"                                                                                                                                                               \n           vaultKey: \"password\"<\/code><\/pre>\n<p><\/p>\n<ul>\n<li>Abbiamo stabilito delle regole generali da seguire quando si registrano segreti in Vault.<\/li>\n<li>Se il segreto appartiene <strong>a un contesto o cluster specifico<\/strong>, \u00e8 necessario aggiungere una registrazione specifica. (Qui il contesto cluster1 ha un proprio valore per il segreto stack-app1-password).<\/li>\n<li>Altrimenti viene utilizzato il valore <strong>predefinito<\/strong>.<\/li>\n<li>Per ogni elemento in questo elenco nel <strong>segreto Kubernetes<\/strong> viene inserita una coppia chiave-valore. Pertanto, il modello del segreto nei nostri chart \u00e8 molto semplice.<\/li>\n<\/ul>\n<p><\/p>\n<pre><code class=\"plaintext\">apiVersion: v1\ndata:\n{{- range $key,$value := .Values.secrets }}\n  {{ $key }}: {{ $value | b64enc | quote }}\n{{ end }}\nkind: Secret\nmetadata:\n  name: \"{{ .Chart.Name }}\"\n  labels:\n    chartVersion: \"{{ .Chart.Version }}\"\n    tillerVersion: \"{{ .Capabilities.TillerVersion.SemVer }}\"\ntype: Opaque<\/code><\/pre>\n<p><\/p>\n<h2 id=\"problemy-i-ogranicheniya\">Problemi e limitazioni<\/h2>\n<p><\/p>\n<h3 id=\"rabota-s-neskolkimi-repozitoriyami\">Lavorare con pi\u00f9 repository<\/h3>\n<p><\/p>\n<p>Attualmente stiamo separando lo sviluppo di chart e applicazioni. Ci\u00f2 significa che gli sviluppatori devono lavorare in due repository git: uno per l'applicazione e l'altro per definire il suo deployment in Kubernetes. 2 repository git significano 2 flussi di lavoro e per un principiante \u00e8 facile confondersi.<\/p>\n<p><\/p>\n<h3 id=\"upravlyat-obobschennymi-chartami-hlopotno\">Gestire chart generici \u00e8 problematico<\/h3>\n<p><\/p>\n<p>Come abbiamo gi\u00e0 detto, i chart generici sono molto utili per definire dipendenze e per il rapido deployment di pi\u00f9 applicazioni. Ma usiamo <code>--reuse-values<\/code>, per evitare di passare ogni volta tutti i valori quando effettuiamo il deployment di un'applicazione inclusa in questo chart generico.<\/p>\n<p><\/p>\n<p>Nel processo di delivery continuo abbiamo solo due valori che cambiano regolarmente: il numero di repliche e il tag dell'immagine (versione). Altri valori, pi\u00f9 stabili, vengono modificati manualmente, ed \u00e8 piuttosto complicato. Inoltre, un errore nel dispiegamento di un chart generico pu\u00f2 portare a gravi malfunzionamenti, come abbiamo constatato sulla nostra esperienza.<\/p>\n<p><\/p>\n<h3 id=\"obnovlenie-neskolkih-faylov-konfiguracii\">Aggiornamento di pi\u00f9 file di configurazione<\/h3>\n<p><\/p>\n<p>Quando uno sviluppatore aggiunge una nuova applicazione, deve modificare diversi file: la dichiarazione dell'applicazione, l'elenco dei segreti, l'aggiunta dell'applicazione alle dipendenze, se \u00e8 inclusa nel chart generico.<\/p>\n<p><\/p>\n<h3 id=\"razresheniya-jenkins-slishkom-rasshireny-v-vault\">I permessi di Jenkins sono troppo ampi in Vault<\/h3>\n<p><\/p>\n<p>Ora abbiamo uno <noindex><a rel=\"nofollow\" href=\"https:\/\/www.vaultproject.io\/docs\/auth\/approle.html\">AppRole<\/a><\/noindex>, che legge tutti i segreti da Vault.<\/p>\n<p><\/p>\n<h3 id=\"process-otkata-ne-avtomatizirovan\">Il processo di rollback non \u00e8 automatizzato<\/h3>\n<p><\/p>\n<p>Per il rollback \u00e8 necessario eseguire il comando su pi\u00f9 cluster, e ci\u00f2 \u00e8 soggetto a errori. Eseguiamo questa operazione manualmente per garantire di specificare l'identificatore di versione corretto.<\/p>\n<p><\/p>\n<h2 id=\"my-dvizhemsya-v-storonu-gitops\">Stiamo andando verso GitOps<\/h2>\n<p><\/p>\n<h3 id=\"nasha-cel\">Il nostro obiettivo<\/h3>\n<p><\/p>\n<p>Vogliamo restituire il chart nel repository dell'applicazione che dispiega.<\/p>\n<p><\/p>\n<p>Il flusso di lavoro sar\u00e0 lo stesso di quello per lo sviluppo. Ad esempio, quando un ramo viene inviato al master, il dispiegamento verr\u00e0 avviato automaticamente. La principale differenza tra questo approccio e l'attuale flusso di lavoro sar\u00e0 che <strong>tutto sar\u00e0 gestito in git<\/strong> (l'applicazione stessa e il modo in cui viene dispiegata in Kubernetes).<\/p>\n<p><\/p>\n<p>Ci sono diversi vantaggi:<\/p>\n<p><\/p>\n<ul>\n<li>Molto <strong>pi\u00f9 chiaro<\/strong> per lo sviluppatore. \u00c8 pi\u00f9 facile imparare ad applicare modifiche nel chart locale.<\/li>\n<li>La definizione del dispiegamento del servizio pu\u00f2 essere specificata <strong>l\u00ec dove c'\u00e8 il codice<\/strong> del servizio.<\/li>\n<li><strong>Gestione della rimozione dei chart generici<\/strong>. Il servizio avr\u00e0 il proprio rilascio di Helm. Questo permetter\u00e0 di gestire il ciclo di vita dell'applicazione (rollback, upgrade) a un livello molto fine, senza influenzare altri servizi.<\/li>\n<li><strong>Vantaggi di git<\/strong> per la gestione dei chart: annullamento delle modifiche, registro delle modifiche, ecc. Se \u00e8 necessario annullare una modifica del chart, ci\u00f2 pu\u00f2 essere fatto tramite git. Il dispiegamento viene avviato automaticamente.<\/li>\n<li>Si potrebbe pensare di migliorare il flusso di lavoro dello sviluppo utilizzando strumenti come <strong>Skaffold<\/strong>, con il quale gli sviluppatori possono testare le modifiche in un contesto simile alla produzione.<\/li>\n<\/ul>\n<p><\/p>\n<h3 id=\"dvuhetapnaya-migraciya\">Migrazione in due fasi<\/h3>\n<p><\/p>\n<p>I nostri sviluppatori utilizzano questo workflow da 2 anni, quindi abbiamo bisogno di una migrazione il pi\u00f9 indolore possibile. Per questo motivo abbiamo deciso di aggiungere una fase intermedia verso l'obiettivo.<br \/>\nLa prima fase \u00e8 semplice:<\/p>\n<p><\/p>\n<ul>\n<li>Manteniamo una struttura simile per la configurazione del deployment delle applicazioni, ma in un unico oggetto chiamato DailymotionRelease.<\/li>\n<\/ul>\n<p><\/p>\n<pre><code class=\"plaintext\">apiVersion: \"v1\"\nkind: \"DailymotionRelease\"\nmetadata:\n  name: \"app1.ns1\"\n  environment: \"dev\"\n  branch: \"mybranch\"\nspec:\n  slack_channel: \"#admin\"\n  chart_name: \"app1\"\n  scaling:\n    - context: \"dev-us-central1-0\"\n      replicas:\n        - name: \"hermes\"\n          count: 2\n    - context: \"dev-europe-west1-0\"\n      replicas:\n        - name: \"app1-deploy\"\n          count: 2\n  secrets:\n    - secret_id: \"app1\"\n      contexts:\n        - name: \"default\"\n          vaultPath: \"\\\/kv\\\/dev\\\/ns1\\\/app1\\\/test\"\n          vaultKey: \"password\"\n        - name: \"dev-europe-west1-0\"\n          vaultPath: \"\\\/kv\\\/dev\\\/ns1\\\/app1\\\/test\"\n          vaultKey: \"password\"<\/code><\/pre>\n<p><\/p>\n<ul>\n<li>1 rilascio per applicazione (senza chart generali).<\/li>\n<li>Charts nel repository git dell'applicazione.<\/li>\n<\/ul>\n<p><\/p>\n<p>Abbiamo parlato con tutti gli sviluppatori, quindi il processo di migrazione \u00e8 gi\u00e0 iniziato. La prima fase \u00e8 ancora sotto controllo utilizzando la piattaforma CI. Presto scriver\u00f2 un altro post sulla seconda fase: come siamo passati al workflow GitOps con <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/weaveworks\/flux\">Flux<\/a><\/noindex>. Racconter\u00f2 come abbiamo impostato tutto e quali difficolt\u00e0 abbiamo affrontato (diversi repository, segreti, ecc.). Rimanete sintonizzati.<\/p>\n<p><\/p>\n<p>Qui abbiamo cercato di descrivere i nostri progressi nel workflow di deployment delle applicazioni negli ultimi anni, che ci hanno portato a riflettere sull'approccio GitOps. Non abbiamo ancora raggiunto l'obiettivo e comunicheremo i risultati, ma siamo gi\u00e0 convinti di aver fatto la scelta giusta nel semplificare tutto e avvicinarci alle abitudini degli sviluppatori.<\/p>\n<p>Fonte: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/southbridge\/blog\/458934\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041a\u0430\u043a Dailymotion \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u0442 Kubernetes: \u0440\u0430\u0437\u0432\u0435\u0440\u0442\u044b\u0432\u0430\u043d\u0438\u0435 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0439 \u041c\u044b \u0432 Dailymotion \u043d\u0430\u0447\u0430\u043b\u0438 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u044c Kubernetes \u0432 \u043f\u0440\u043e\u0434\u0430\u043a\u0448\u0435\u043d\u0435 3 \u0433\u043e\u0434\u0430 \u043d\u0430\u0437\u0430\u0434. \u041d\u043e \u0440\u0430\u0437\u0432\u0435\u0440\u0442\u044b\u0432\u0430\u0442\u044c \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f \u043d\u0430 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u0438\u0445 \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0430\u0445 \u0442\u043e \u0435\u0449\u0435 \u0443\u0434\u043e\u0432\u043e\u043b\u044c\u0441\u0442\u0432\u0438\u0435, \u043f\u043e\u044d\u0442\u043e\u043c\u0443 \u0432 \u043f\u043e\u0441\u043b\u0435\u0434\u043d\u0438\u0435 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u043b\u0435\u0442 \u043c\u044b \u0441\u0442\u0430\u0440\u0430\u043b\u0438\u0441\u044c \u0443\u043b\u0443\u0447\u0448\u0438\u0442\u044c \u043d\u0430\u0448\u0438 \u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442\u044b \u0438 \u0440\u0430\u0431\u043e\u0447\u0438\u0435 \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u044b. \u0421 \u0447\u0435\u0433\u043e \u043d\u0430\u0447\u0430\u043b\u043e\u0441\u044c \u0417\u0434\u0435\u0441\u044c \u043c\u044b \u0440\u0430\u0441\u0441\u043a\u0430\u0436\u0435\u043c, \u043a\u0430\u043a \u043c\u044b \u0440\u0430\u0437\u0432\u0435\u0440\u0442\u044b\u0432\u0430\u0435\u043c \u043d\u0430\u0448\u0438 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f \u043d\u0430 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u0438\u0445 \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0430\u0445 Kubernetes \u043f\u043e [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-35955","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.1.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041a\u0430\u043a Dailymotion \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u0442 Kubernetes: \u0440\u0430\u0437\u0432\u0435\u0440\u0442\u044b\u0432\u0430\u043d\u0438\u0435 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0439 \u041c\u044b \u0432 Dailymotion \u043d\u0430\u0447\u0430\u043b\u0438 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u044c Kubernetes \u0432.\" \/>\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\/razvertyvanie-prilozhenij-na-neskolkih-klasterah-kubernetes-s-helm\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\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\u0420\u0430\u0437\u0432\u0435\u0440\u0442\u044b\u0432\u0430\u043d\u0438\u0435 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0439 \u043d\u0430 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u0438\u0445 \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0430\u0445 Kubernetes \u0441 Helm | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041a\u0430\u043a Dailymotion \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u0442 Kubernetes: \u0440\u0430\u0437\u0432\u0435\u0440\u0442\u044b\u0432\u0430\u043d\u0438\u0435 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0439 \u041c\u044b \u0432 Dailymotion \u043d\u0430\u0447\u0430\u043b\u0438 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u044c Kubernetes \u0432.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/razvertyvanie-prilozhenij-na-neskolkih-klasterah-kubernetes-s-helm\" \/>\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:08:26+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T19:08:26+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\udd47Deployment delle applicazioni su pi\u00f9 cluster Kubernetes con Helm | ProHoster","description":"Come Dailymotion utilizza Kubernetes: deployment delle applicazioni. Noi di Dailymotion abbiamo iniziato a utilizzare Kubernetes nel.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/razvertyvanie-prilozhenij-na-neskolkih-klasterah-kubernetes-s-helm","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\u0420\u0430\u0437\u0432\u0435\u0440\u0442\u044b\u0432\u0430\u043d\u0438\u0435 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0439 \u043d\u0430 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u0438\u0445 \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0430\u0445 Kubernetes \u0441 Helm | ProHoster","og:description":"\u041a\u0430\u043a Dailymotion \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u0442 Kubernetes: \u0440\u0430\u0437\u0432\u0435\u0440\u0442\u044b\u0432\u0430\u043d\u0438\u0435 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0439 \u041c\u044b \u0432 Dailymotion \u043d\u0430\u0447\u0430\u043b\u0438 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u044c Kubernetes \u0432.","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/razvertyvanie-prilozhenij-na-neskolkih-klasterah-kubernetes-s-helm","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:08:26+00:00","article:modified_time":"2019-10-31T19:08:26+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"35955","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-22 01:25:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 01:53:31","updated":"2026-01-22 01:25:19","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\/35955","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=35955"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/35955\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=35955"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=35955"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=35955"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}