{"id":52688,"date":"2019-11-14T00:00:00","date_gmt":"2019-11-13T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/strategii-deploya-v-kubernetes-rolling-recreate-blue-green-canary-dark-a-b-testirovanie"},"modified":"2020-02-18T14:00:29","modified_gmt":"2020-02-18T11:00:29","slug":"strategii-deploya-v-kubernetes-rolling-recreate-blue-green-canary-dark-a-b-testirovanie","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/strategii-deploya-v-kubernetes-rolling-recreate-blue-green-canary-dark-a-b-testirovanie","title":{"rendered":"Strategie di distribuzione in Kubernetes: rolling, recreate, blue\/green, canary, dark (A\/B testing)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><i><b>Nota del traduttore:<\/b> Questo materiale informativo di Weaveworks presenta le strategie di rilascio delle applicazioni pi\u00f9 popolari e discute dell'implementazione delle pi\u00f9 avanzate di esse attraverso l'operatore Kubernetes Flagger. \u00c8 scritto in un linguaggio semplice e contiene diagrammi illustrativi che permettono anche ai neofiti di comprendere l'argomento.<\/i><\/p>\n<p><img decoding=\"async\" alt=\"Strategie di distribuzione in Kubernetes: rolling, recreate, blue\/green, canary, dark (A\/B testing)\" src=\"\/wp-content\/uploads\/2019\/11\/8d32d63c9986e9f5b35ccca74a546d42.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Il diagramma \u00e8 tratto da <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.container-solutions.com\/kubernetes-deployment-strategies\">un'altra recensione<\/a><\/noindex> delle strategie di rilascio, realizzata da Container Solutions<\/i><\/p>\n<p>Una delle sfide maggiori nello sviluppo delle applicazioni cloud-native di oggi \u00e8 l'accelerazione del deployment. Con un approccio a microservizi, gli sviluppatori lavorano gi\u00e0 con applicazioni completamente modulari, progettandole in modo che diversi team possano scrivere codice e apportare modifiche all'applicazione simultaneamente.<\/p>\n<p>Deployment pi\u00f9 brevi e frequenti offrono i seguenti vantaggi:<\/p>\n<ul>\n<li> Si riduce il time-to-market.<\/li>\n<li> Nuove funzionalit\u00e0 arrivano pi\u00f9 rapidamente agli utenti.<\/li>\n<li> Il feedback degli utenti arriva pi\u00f9 velocemente al team di sviluppo. Questo significa che il team pu\u00f2 aggiungere funzionalit\u00e0 e risolvere problemi in modo pi\u00f9 tempestivo.<\/li>\n<li> Aumenta il morale degli sviluppatori: con un numero maggiore di funzionalit\u00e0 in sviluppo, \u00e8 pi\u00f9 stimolante lavorare.<\/li>\n<\/ul>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\nMa con l'aumento della frequenza dei rilasci, aumenta anche il rischio di impattare negativamente sull'affidabilit\u00e0 dell'applicazione o sull'esperienza dell'utente. Per questo motivo, \u00e8 fondamentale per i team operativi e DevOps costruire processi e gestire le strategie di rilascio in modo da minimizzare i rischi per il prodotto e per gli utenti. (Scopri di pi\u00f9 sull'automazione del pipeline CI\/CD) <noindex><a rel=\"nofollow\" href=\"https:\/\/www.weave.works\/assets\/images\/blta8084030436bce24\/CICD_eBook_Web.pdf\">qui<\/a><\/noindex>.)<\/p>\n<p>In questa pubblicazione discuteremo delle diverse strategie di deployment in Kubernetes, incluse le rolling deployment e metodi pi\u00f9 avanzati come i canary release e le loro varianti.<\/p>\n<h2>Strategie di deployment<\/h2>\n<p>\nEsistono diversi tipi di strategie di rilascio che possono essere utilizzate a seconda dell'obiettivo. Ad esempio, potresti aver bisogno di apportare modifiche a un certo ambiente per ulteriori test, o a un sottoinsieme di utenti\/clienti, o potrebbe sorgere la necessit\u00e0 di eseguire test limitati sugli utenti prima di rendere una certa funzionalit\u00e0 <i>pubblica<\/i>.<\/p>\n<h3>Rolling (deployment graduale)<\/h3>\n<p>\nQuesta \u00e8 la strategia di distribuzione standard in Kubernetes. Sostituisce gradualmente, uno alla volta, i pod con la vecchia versione dell'applicazione con pod con la nuova versione, senza interrompere il cluster.<\/p>\n<p><img decoding=\"async\" alt=\"Strategie di distribuzione in Kubernetes: rolling, recreate, blue\/green, canary, dark (A\/B testing)\" src=\"\/wp-content\/uploads\/2019\/11\/cbd490f1ef8311ff4c242726e947248c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nKubernetes attende che i nuovi pod siano pronti per l'uso (verificandoli tramite <noindex><a rel=\"nofollow\" href=\"https:\/\/www.weave.works\/blog\/resilient-apps-with-liveness-and-readiness-probes-in-kubernetes\">test di readiness<\/a><\/noindex>), prima di procedere con la rimozione dei vecchi. Se si verifica un problema, un aggiornamento rolling pu\u00f2 essere interrotto senza fermare l'intero cluster. Nel file YAML che descrive il tipo di deployment, la nuova immagine sostituisce la vecchia immagine:<\/p>\n<pre><code class=\"plaintext\">apiVersion: apps\/v1beta1\nkind: Deployment\nmetadata:\n  name: awesomeapp\nspec:\n  replicas: 3\n  template:\n    metadata:\n      labels:\n        app: awesomeapp\n    spec:\n      containers:\n        - name: awesomeapp\n          image: imagerepo-user\/awesomeapp:new\n          ports:\n            - containerPort: 8080<\/code><\/pre>\n<p>\nI parametri dell'aggiornamento in rolling possono essere specificati nel file di manifesto:<\/p>\n<pre><code class=\"plaintext\">spec:\n  replicas: 3\n  strategy:\n    type: RollingUpdate\n    rollingUpdate:\n       maxSurge: 25%\n       maxUnavailable: 25%  \n  template:\n  ...\n<\/code><\/pre>\n<p><\/p>\n<h3>Recreate (ricreazione)<\/h3>\n<p>\nIn questo tipo pi\u00f9 semplice di distribuzione, i vecchi pod vengono terminati tutti insieme e sostituiti da nuovi:<\/p>\n<p><img decoding=\"async\" alt=\"Strategie di distribuzione in Kubernetes: rolling, recreate, blue\/green, canary, dark (A\/B testing)\" src=\"\/wp-content\/uploads\/2019\/11\/46168e36b7f44c76bcea40ab3a1a2cad.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIl manifesto corrispondente appare cos\u00ec:<\/p>\n<pre><code class=\"plaintext\">spec:\n  replicas: 3\n  strategy:\n    type: Recreate\n  template:\n  ...<\/code><\/pre>\n<p><\/p>\n<h3>Blue\/Green (distribuzioni blu\/verdi)<\/h3>\n<p>\nLa strategia di distribuzione blu-verde (a volte chiamata anche rossa\/nera) prevede la distribuzione simultanea della versione vecchia (verde) e di quella nuova (blu) dell'applicazione. Dopo il deployment di entrambe le versioni, gli utenti normali accedono alla versione verde, mentre la versione blu \u00e8 disponibile per il team QA per automatizzare i test tramite un servizio separato o un port forwarding diretto:<\/p>\n<p><img decoding=\"async\" alt=\"Strategie di distribuzione in Kubernetes: rolling, recreate, blue\/green, canary, dark (A\/B testing)\" src=\"\/wp-content\/uploads\/2019\/11\/6664b625c99e089acf01c92edce0b45a.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<pre><code class=\"plaintext\">apiVersion: apps\/v1beta1\nkind: Deployment\nmetadata:\n  name: awesomeapp-02\nspec:\n  template:\n    metadata:\n      labels:\n        app: awesomeapp\n        version: \"02\"<\/code><\/pre>\n<p>\nDopo che la versione blu (nuova) \u00e8 stata testata e il suo rilascio \u00e8 stato approvato, il servizio viene switchato su di essa, mentre la versione verde (vecchia) viene disattivata:<\/p>\n<pre><code class=\"plaintext\">apiVersion: v1\nkind: Service\nmetadata:\n  name: awesomeapp\nspec:\n  selector:\n    app: awesomeapp\n    version: \"02\"\n...<\/code><\/pre>\n<p><\/p>\n<h3>Canary (distribuzioni canarie)<\/h3>\n<p>\nLe distribuzioni canarie sono simili a quelle blu-verdi, ma meglio gestibili e utilizzano <noindex><a rel=\"nofollow\" href=\"https:\/\/redmonk.com\/jgovernor\/2018\/08\/06\/towards-progressive-delivery\/\">un approccio progressivo<\/a><\/noindex> . Questo tipo comprende diverse strategie, tra cui il lancio \"soft\" e il test A\/B.<\/p>\n<p>Questa strategia viene applicata quando \u00e8 necessario testare una nuova funzionalit\u00e0, generalmente nel backend dell'applicazione. L'idea alla base dell'approccio \u00e8 quella di creare due server praticamente identici: uno gestisce quasi tutti gli utenti, mentre l'altro, con le nuove funzioni, gestisce solo un piccolo sottoinsieme di utenti, dopodich\u00e9 vengono confrontati i risultati del loro funzionamento. Se tutto procede senza errori, la nuova versione viene gradualmente distribuita su tutta l'infrastruttura.<\/p>\n<p>Sebbene questa strategia possa essere implementata esclusivamente con i mezzi di Kubernetes, \u00e8 molto pi\u00f9 comodo e semplice utilizzare una service mesh come Istio.<\/p>\n<p>Ad esempio, potresti avere due manifesti diversi in Git: uno normale con il tag 0.1.0 e uno \"canarino\" con il tag 0.2.0. Modificando i pesi nel manifesto del gateway virtuale di Istio, puoi gestire la distribuzione del traffico tra questi due deployment:<\/p>\n<p><img decoding=\"async\" alt=\"Strategie di distribuzione in Kubernetes: rolling, recreate, blue\/green, canary, dark (A\/B testing)\" src=\"\/wp-content\/uploads\/2019\/11\/d75dc34fea187c4e67879d0f64f9251c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nUna guida passo passo per implementare i deployment canary utilizzando Istio pu\u00f2 essere trovata nel materiale <noindex><a rel=\"nofollow\" href=\"https:\/\/www.weave.works\/blog\/gitops-workflows-for-istio-canary-deployments\">GitOps Workflows with Istio<\/a><\/noindex>. <i>(<b>Nota di traduzione.<\/b>: Abbiamo anche tradotto il materiale sui rilasci canary in Istio <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/440378\/\">qui<\/a><\/noindex>.)<\/i><\/p>\n<h4>Deployment canary con Weaveworks Flagger<\/h4>\n<p>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/docs.flagger.app\/\">Weaveworks Flagger<\/a><\/noindex> consente di gestire in modo semplice ed efficace i rilasci canary.<\/p>\n<p>Flagger automatizza il lavoro con loro. Utilizza Istio o AWS App Mesh per la gestione e l'instradamento del traffico, nonch\u00e9 le metriche Prometheus per l'analisi dei risultati. Inoltre, l'analisi dei deployment canary pu\u00f2 essere integrata con webhook per effettuare test di accettazione, test di carico e qualsiasi altro tipo di verifica.<\/p>\n<p>Sulla base del deployment di Kubernetes e, se necessario, della scalabilit\u00e0 orizzontale dei pod (HPA), Flagger crea insiemi di oggetti (deployment di Kubernetes, servizi ClusterIP e servizi virtuali di Istio o App Mesh) per analizzare e implementare distribuzioni canarino:<\/p>\n<p><img decoding=\"async\" alt=\"Strategie di distribuzione in Kubernetes: rolling, recreate, blue\/green, canary, dark (A\/B testing)\" src=\"\/wp-content\/uploads\/2019\/11\/99aa426bbcf59edcb70d5637e32d8ff7.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nImplementando un ciclo di controllo <i>(control loop)<\/i>, Flagger reindirizza gradualmente il traffico al server canarino, mentre misura le metriche chiave delle prestazioni, come il tasso di richieste HTTP riuscite, la durata media delle richieste e la salute dei pod. In base all'analisi delle KPI (key performance indicators), la parte canarino pu\u00f2 aumentare o ridursi e i risultati dell'analisi vengono pubblicati su Slack. Una descrizione e una dimostrazione di questo processo possono essere trovate nel materiale <noindex><a rel=\"nofollow\" href=\"https:\/\/www.weave.works\/blog\/progressive-delivery-for-aws-app-mesh\">Progressive Delivery for App Mesh<\/a><\/noindex>.<\/p>\n<p><img decoding=\"async\" alt=\"Strategie di distribuzione in Kubernetes: rolling, recreate, blue\/green, canary, dark (A\/B testing)\" src=\"\/wp-content\/uploads\/2019\/11\/f9fa1ba66edecc2b3e971952a318ea40.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Distribuzioni oscure (nascoste) o A\/B<\/h3>\n<p>\nLa distribuzione nascosta \u00e8 un'altra variazione della strategia canary (con cui, peraltro, Flagger pu\u00f2 lavorare). La differenza tra distribuzioni nascoste e canary \u00e8 che le distribuzioni nascoste si occupano del frontend, a differenza delle canary che si occupano del backend.<\/p>\n<p>Un altro nome per queste distribuzioni \u00e8 A\/B testing. Invece di aprire l'accesso a una nuova funzionalit\u00e0 a tutti gli utenti, questa viene proposta solo a una parte limitata di essi. Di solito, questi utenti non sanno di essere dei tester pionieristici (da qui il termine \"distribuzione nascosta\").<\/p>\n<p>Utilizzando i feature toggles <i>(interruttori di funzionalit\u00e0)<\/i> e altri strumenti \u00e8 possibile monitorare come gli utenti interagiscono con la nuova funzionalit\u00e0, se li cattura oppure se trovano l'interfaccia utente confusa, insieme ad altri tipi di metriche.<\/p>\n<p><img decoding=\"async\" alt=\"Strategie di distribuzione in Kubernetes: rolling, recreate, blue\/green, canary, dark (A\/B testing)\" src=\"\/wp-content\/uploads\/2019\/11\/037b5ccca2e1d99ac142d2ce734f954d.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h4>Flagger e distribuzioni A\/B<\/h4>\n<p>\nOltre alla routing ponderata, Flagger pu\u00f2 anche direzionare il traffico a un server canary in base ai parametri HTTP. Durante l'A\/B testing, \u00e8 possibile utilizzare gli header HTTP o i cookie per reindirizzare un certo segmento di utenti. Questo \u00e8 particolarmente efficace per le applicazioni frontend che richiedono l'affinit\u00e0 della sessione con il server <i>(affinit\u00e0 della sessione)<\/i>. Maggiori informazioni possono essere trovate nella documentazione di Flagger.<\/p>\n<p><i>L'autore ringrazia <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/stefanprodan\">Stefan Prodan<\/a><\/noindex>, ingegnere di Weaveworks (e creatore di Flagger), per tutti questi fantastici schemi di distribuzione.<\/i><\/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\/447180\/\">Panoramica e confronto dei controller Ingress per Kubernetes<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/460351\/\">werf \u2014 il nostro strumento per CI\/CD in Kubernetes (panoramica e video della presentazione)<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/469541\/\">Build e deployment di microservizi simili con werf e GitLab CI<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/458878\/\">Che cos'\u00e8 GitOps?<\/a><\/noindex>\u00bb.<\/li>\n<\/ul>\n<p>Fonte: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/471620\/\">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.: \u042d\u0442\u043e\u0442 \u043e\u0431\u0437\u043e\u0440\u043d\u044b\u0439 \u043c\u0430\u0442\u0435\u0440\u0438\u0430\u043b \u043e\u0442 Weaveworks \u0437\u043d\u0430\u043a\u043e\u043c\u0438\u0442 \u0441 \u043d\u0430\u0438\u0431\u043e\u043b\u0435\u0435 \u043f\u043e\u043f\u0443\u043b\u044f\u0440\u043d\u044b\u043c\u0438 \u0441\u0442\u0440\u0430\u0442\u0435\u0433\u0438\u044f\u043c\u0438 \u0432\u044b\u043a\u0430\u0442\u0430 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0439 \u0438 \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u044b\u0432\u0430\u0435\u0442 \u043e \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e\u0441\u0442\u0438 \u0440\u0435\u0430\u043b\u0438\u0437\u0430\u0446\u0438\u0438 \u043d\u0430\u0438\u0431\u043e\u043b\u0435\u0435 \u043f\u0440\u043e\u0434\u0432\u0438\u043d\u0443\u0442\u044b\u0445 \u0438\u0437 \u043d\u0438\u0445 \u0441 \u043f\u043e\u043c\u043e\u0449\u044c\u044e Kubernetes-\u043e\u043f\u0435\u0440\u0430\u0442\u043e\u0440\u0430 Flagger. \u041e\u043d \u043d\u0430\u043f\u0438\u0441\u0430\u043d \u043f\u0440\u043e\u0441\u0442\u044b\u043c \u044f\u0437\u044b\u043a\u043e\u043c \u0438 \u0441\u043e\u0434\u0435\u0440\u0436\u0438\u0442 \u043d\u0430\u0433\u043b\u044f\u0434\u043d\u044b\u0435 \u0441\u0445\u0435\u043c\u044b, \u043f\u043e\u0437\u0432\u043e\u043b\u044f\u044e\u0449\u0438\u0435 \u0440\u0430\u0437\u043e\u0431\u0440\u0430\u0442\u044c\u0441\u044f \u0432 \u0432\u043e\u043f\u0440\u043e\u0441\u0435 \u0434\u0430\u0436\u0435 \u043d\u0430\u0447\u0438\u043d\u0430\u044e\u0449\u0438\u043c \u0438\u043d\u0436\u0435\u043d\u0435\u0440\u0430\u043c. \u0421\u0445\u0435\u043c\u0430 \u0432\u0437\u044f\u0442\u0430 \u0438\u0437 \u0434\u0440\u0443\u0433\u043e\u0433\u043e \u043e\u0431\u0437\u043e\u0440\u0430 \u0441\u0442\u0440\u0430\u0442\u0435\u0433\u0438\u0439 \u0432\u044b\u043a\u0430\u0442\u0430, \u0441\u0434\u0435\u043b\u0430\u043d\u043d\u043e\u0433\u043e \u0432 Container Solutions \u041e\u0434\u043d\u043e\u0439 \u0438\u0437 [&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-52688","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=\"\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\/strategii-deploya-v-kubernetes-rolling-recreate-blue-green-canary-dark-a-b-testirovanie\" \/>\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\u0421\u0442\u0440\u0430\u0442\u0435\u0433\u0438\u0438 \u0434\u0435\u043f\u043b\u043e\u044f \u0432 Kubernetes: rolling, recreate, blue\/green, canary, dark (A\/B-\u0442\u0435\u0441\u0442\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435) | 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\/strategii-deploya-v-kubernetes-rolling-recreate-blue-green-canary-dark-a-b-testirovanie\" \/>\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-11-13T21:00:00+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-02-18T11:00:29+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\udd47Strategie di distribuzione in Kubernetes: rolling, recreate, blue\/green, canary, dark (A\/B testing) | ProHoster","description":"Nota.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/strategii-deploya-v-kubernetes-rolling-recreate-blue-green-canary-dark-a-b-testirovanie","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\u0421\u0442\u0440\u0430\u0442\u0435\u0433\u0438\u0438 \u0434\u0435\u043f\u043b\u043e\u044f \u0432 Kubernetes: rolling, recreate, blue\/green, canary, dark (A\/B-\u0442\u0435\u0441\u0442\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435) | ProHoster","og:description":"\u041f\u0440\u0438\u043c.","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/strategii-deploya-v-kubernetes-rolling-recreate-blue-green-canary-dark-a-b-testirovanie","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-11-13T21:00:00+00:00","article:modified_time":"2020-02-18T11:00:29+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"52688","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-24 04:27:20","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 17:03:32","updated":"2026-01-24 04:27:20","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\/52688","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=52688"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/52688\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=52688"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=52688"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=52688"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}