{"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 delle 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 utilizzare Kubernetes in produzione 3 anni fa. Tuttavia, distribuire applicazioni su pi\u00f9 cluster non \u00e8 un compito semplice, perci\u00f2 negli ultimi anni abbiamo cercato di migliorare i nostri strumenti e i nostri processi.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h3 id=\"s-chego-nachalos\">Da dove \u00e8 iniziato<\/h3>\n<p><\/p>\n<p>Qui spiegheremo 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, utilizziamo <noindex><a rel=\"nofollow\" href=\"https:\/\/helm.sh\/\">Helm<\/a><\/noindex>, e tutti i nostri chart sono conservati in un unico repository git. Per distribuire l'intero stack dell'applicazione composto da pi\u00f9 servizi, utilizziamo quello che chiamiamo un chart aggregatore. 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 effettuare 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>Passiamo al sodo.<\/p>\n<p><\/p>\n<blockquote><p>Nota. Quando leggi questo, la prima release candidate di Helm 3 \u00e8 gi\u00e0 stata annunciata. La versione principale contiene un insieme di miglioramenti progettati per affrontare 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>Ramo <strong>dev<\/strong> \u00e8 utilizzato per creare i chart che verranno testati nei cluster di sviluppo.<\/li>\n<li>Quando la pull request viene inviata a <strong>master<\/strong>, vengono controllati in staging.<\/li>\n<li>Infine, creiamo una pull request per applicare le modifiche al ramo <strong>prod<\/strong> e implementarle in produzione.<\/li>\n<\/ul>\n<p><\/p>\n<p>Ogni ambiente ha il proprio repository privato che memorizza 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 rigoroso isolamento tra gli ambienti e testiamo i 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 in diversi ambienti<\/em><\/p>\n<p><\/p>\n<p>\u00c8 importante notare che quando gli sviluppatori inviano un ramo dev, la versione del loro chart viene automaticamente inviata in dev Chartmuseum. In questo modo, tutti gli sviluppatori utilizzano un unico repository dev, e sar\u00e0 necessario specificare attentamente la propria versione del chart per non utilizzare accidentalmente le modifiche di qualcun altro.<\/p>\n<p><\/p>\n<p>Inoltre, il nostro piccolo script Python verifica gli oggetti Kubernetes rispetto alle specifiche Kubernetes OpenAPI tramite <noindex><a rel=\"nofollow\" href=\"https:\/\/kubeval.instrumenta.dev\/\">Kubeval<\/a><\/noindex>, prima di pubblicarli in Chartmuseum.<\/p>\n<p><\/p>\n<h3 id=\"obschee-opisanie-rabochego-processa-razrabotki-charta\">Panoramica del flusso di lavoro di 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>Configurazione 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 di Kubernetes utilizzando Kubeval.<\/li>\n<li>Incremento automatico della versione del chart e dei suoi chart parent (charts che dipendono dal chart modificabile).<\/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'\u00e8 stato un tempo in cui utilizzavamo <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. Tuttavia, si sono presentati dei problemi. Ad esempio, alcuni oggetti Kubernetes non potevano essere creati nell'endpoint della federazione, rendendo difficile gestire gli oggetti combinati e altri oggetti per cluster separati.<\/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 geodistribuita<\/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 Helm<\/h3>\n<p><\/p>\n<p>4 valori globali Helm permettono di definire differenze tra 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 sono utilizzati per vari compiti: monitoraggio, tracciamento, logging, effettuazione di chiamate esterne, scalabilit\u00e0, ecc.<\/p>\n<p><\/p>\n<ul>\n<li>\u00abcloud\u00bb: abbiamo una piattaforma ibrida Kubernetes. Ad esempio, la nostra API \u00e8 distribuita nelle zone GCP e nei nostri data center.<\/li>\n<li>\u00abenv\u00bb: alcuni valori possono cambiare per gli ambienti non di produzione. Ad esempio, le definizioni delle risorse e la configurazione del ridimensionamento automatico.<\/li>\n<li>\u00abregion\u00bb: queste informazioni aiutano a determinare la posizione del cluster e possono essere utilizzate per identificare i punti finali pi\u00f9 vicini per i servizi esterni.<\/li>\n<li>\u00abclusterName\u00bb: se e quando vogliamo definire un valore per un cluster specifico.<\/li>\n<\/ul>\n<p><\/p>\n<p>Ecco un esempio specifico:<\/p>\n<p><\/p>\n<pre><code class=\"plaintext\">{{\/* Restituisce le repliche dell'Horizontal Pod Autoscaler per GraphQL*\/}}\n{{- definisci \"graphql.hpaReplicas\" -}}\n{{- se eq .Values.global.env \"prod\" }}\n{{- se eq .Values.global.region \"europe-west1\" }}\nminReplicas: 40\n{{- altrimenti }}\nminReplicas: 150\n{{- fine }}\nmaxReplicas: 1400\n{{- altrimenti }}\nminReplicas: 4\nmaxReplicas: 20\n{{- fine }}\n{{- fine -}}<\/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 affollare il Kubernetes YAML.<\/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 scalabilit\u00e0 (numero di repliche) nel cluster.<\/p>\n<p><\/p>\n<pre><code class=\"plaintext\">rilascia:\n  - foo.world\n\nfoo.world:                # Nome del rilascio\n  servizi:               # Elenco delle app\/progetti di dailymotion\n    foobar:\n      chart_name: foo-foobar\n      repo: git@github.com:dailymotion\/foobar\n      contesti:\n        prod-europe-west1:\n          distribuzioni:\n            - nome: foo-bar-baz\n              repliche: 18\n            - nome: altra-distribuzione\n              repliche: 3<\/code><\/pre>\n<p><\/p>\n<p><em>Definizione del servizio<\/em><\/p>\n<p><\/p>\n<p>Questa \u00e8 la schemi di tutti i passaggi che definiscono il nostro processo 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, tracciamo tutti i segreti da diverse fonti e li conserviamo in un archivio 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 arriva il momento della distribuzione, li inseriscono in Helm.<\/p>\n<p><\/p>\n<p>Per questo motivo abbiamo definito una mappatura tra i segreti in Vault e i segreti necessari alle nostre applicazioni:<\/p>\n<p><\/p>\n<pre><code class=\"plaintext\">secrets:                                                                                                                                                                                                        \n     - secret_id: \"stack1-app1-password\"                                                                                                                                                                                  \n       contexts:                                                                                                                                                                                                   \n         - name: \"default\"                                                                                                                                                                                         \n           vaultPath: \"\/kv\/dev\/stack1\/app1\/test\"                                                                                                                                                               \n           vaultKey: \"password\"                                                                                                                                                                                    \n         - name: \"cluster1\"                                                                                                                                                                           \n           vaultPath: \"\/kv\/dev\/stack1\/app1\/test\"                                                                                                                                                               \n           vaultKey: \"password\"<\/code><\/pre>\n<p><\/p>\n<ul>\n<li>Abbiamo definito delle regole generali che devono essere seguite quando si registrano i segreti nel Vault.<\/li>\n<li>Se il segreto \u00e8 associato <strong>a un contesto o a un cluster specifico<\/strong>, \u00e8 necessario aggiungere una registrazione specifica. (Qui il contesto cluster1 ha un valore proprio per il segreto stack-app1-password).<\/li>\n<li>In caso contrario, viene utilizzato il valore <strong>predefinito<\/strong>.<\/li>\n<li>Per ogni voce in questo elenco in <strong>segreto Kubernetes<\/strong> viene inserito un 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 dei chart e delle applicazioni. Questo significa che gli sviluppatori devono lavorare in due repository git: uno per l'applicazione e il secondo per definire il suo deployment in Kubernetes. 2 repository git equivalgono a 2 flussi di lavoro, ed \u00e8 facile per un principiante confondersi.<\/p>\n<p><\/p>\n<h3 id=\"upravlyat-obobschennymi-chartami-hlopotno\">Gestire chart generici \u00e8 complicato<\/h3>\n<p><\/p>\n<p>Come abbiamo gi\u00e0 detto, i chart generici sono molto utili per definire le dipendenze e per il rapido deployment di pi\u00f9 applicazioni. Ma noi utilizziamo <code>--reuse-values<\/code>, per evitare di passare tutti i valori ogni volta che deployiamo un'applicazione che fa parte di 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, e questo \u00e8 piuttosto complicato. Inoltre, un errore nel rilascio di un chart generico pu\u00f2 portare a gravi malfunzionamenti, come abbiamo sperimentato in prima persona.<\/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, aggiungere l'applicazione alle dipendenze se fa parte del chart generico.<\/p>\n<p><\/p>\n<h3 id=\"razresheniya-jenkins-slishkom-rasshireny-v-vault\">I permessi di Jenkins sono troppo estesi in Vault<\/h3>\n<p><\/p>\n<p>Attualmente 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 un rollback \u00e8 necessario eseguire comandi su pi\u00f9 cluster, il che porta a potenziali errori. Effettuiamo questa operazione manualmente per assicurarci di indicare il corretto identificativo della versione.<\/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 riportare il chart nel repository dell'applicazione che distribuisce.<\/p>\n<p><\/p>\n<p>Il processo di lavoro sar\u00e0 lo stesso di quello per lo sviluppo. Ad esempio, quando un ramo viene inviato nel master, il deployment verr\u00e0 avviato automaticamente. La principale differenza tra questo approccio e l'attuale processo di lavoro \u00e8 che <strong>tutto sar\u00e0 gestito in git<\/strong> (l'applicazione stessa e il modo in cui viene distribuita 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 le modifiche nel chart locale.<\/li>\n<li>La definizione del deployment del servizio pu\u00f2 essere specificata <strong>l\u00ec dove si trova il codice<\/strong> del servizio.<\/li>\n<li><strong>Gestione della cancellazione dei chart generali<\/strong>. Il servizio avr\u00e0 la sua release Helm. Questo permetter\u00e0 di gestire il ciclo di vita dell'applicazione (rollback, upgrade) a un livello molto dettagliato, senza coinvolgere altri servizi.<\/li>\n<li><strong>Vantaggi di git<\/strong> per la gestione dei chart: annullamento delle modifiche, registro delle audit, ecc. Se \u00e8 necessario annullare una modifica al chart, \u00e8 possibile farlo tramite git. Il deployment viene avviato automaticamente.<\/li>\n<li>Si pu\u00f2 pensare a migliorare il processo di sviluppo utilizzando strumenti come <strong>Skaffold<\/strong>, con cui gli sviluppatori possono testare le modifiche in un contesto simile a quello di produzione.<\/li>\n<\/ul>\n<p><\/p>\n<h3 id=\"dvuhetapnaya-migraciya\">Migrazione a due fasi<\/h3>\n<p><\/p>\n<p>I nostri sviluppatori utilizzano questo flusso di lavoro 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 generici).<\/li>\n<li>Chart 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 controllata utilizzando la piattaforma CI. Presto scriver\u00f2 un altro post sulla seconda fase: come siamo passati al flusso di lavoro GitOps con <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/weaveworks\/flux\">Flux<\/a><\/noindex>. Vi racconter\u00f2 come abbiamo configurato tutto e quali difficolt\u00e0 abbiamo affrontato (diversi repository, segreti, ecc.). Rimanete sintonizzati per gli aggiornamenti.<\/p>\n<p><\/p>\n<p>Qui abbiamo cercato di descrivere il nostro progresso nel processo di distribuzione delle applicazioni negli ultimi anni, che ci ha portati 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 semplificando tutto e avvicinandolo 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.0.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.0.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\udd47 Distribuzione delle applicazioni su pi\u00f9 cluster Kubernetes con Helm | ProHoster","description":"Come Dailymotion utilizza Kubernetes: distribuzione delle applicazioni Abbiamo iniziato a utilizzare Kubernetes in Dailymotion.","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}]}}