{"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 deploy in Kubernetes: rolling, recreate, blue\/green, canary, dark (A\/B testing)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><i><b>Nota di traduzione:<\/b> Questo materiale di riepilogo di Weaveworks introduce le strategie di distribuzione delle applicazioni pi\u00f9 popolari e spiega come attuare le pi\u00f9 avanzate di esse tramite il Kubernetes operator Flagger. \u00c8 scritto in un linguaggio semplice e contiene diagrammi chiari che permettono anche ai neofiti di comprendere l'argomento.<\/i><\/p>\n<p><img decoding=\"async\" alt=\"Strategie di deploy 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 panoramica<\/a><\/noindex> delle strategie di distribuzione, realizzata in Container Solutions<\/i><\/p>\n<p>Una delle maggiori sfide nello sviluppo di applicazioni cloud native oggi \u00e8 accelerare il deployment. Con un approccio a microservizi, gli sviluppatori lavorano gi\u00e0 con applicazioni completamente modulari e le progettano in modo che diversi team possano scrivere codice e apportare modifiche all'applicazione in parallelo.<\/p>\n<p>Distribuzioni pi\u00f9 brevi e frequenti offrono i seguenti vantaggi:<\/p>\n<ul>\n<li> Riduzione del time-to-market.<\/li>\n<li> Nuove funzionalit\u00e0 arrivano pi\u00f9 rapidamente agli utenti.<\/li>\n<li> I feedback degli utenti raggiungono pi\u00f9 velocemente il team di sviluppo. Ci\u00f2 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: lavorare su un numero maggiore di funzionalit\u00e0 rende il lavoro pi\u00f9 interessante.<\/li>\n<\/ul>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\nTuttavia, con l'aumento della frequenza delle versioni, aumenta anche il rischio di influenzare negativamente l'affidabilit\u00e0 dell'applicazione o l'esperienza dell'utente. \u00c8 per questo motivo che i team di operations e DevOps devono costruire processi e gestire le strategie di deployment in modo da minimizzare i rischi per il prodotto e per gli utenti. (Scopri di pi\u00f9 sull'automazione della CI\/CD pipeline <noindex><a rel=\"nofollow\" href=\"https:\/\/www.weave.works\/assets\/images\/blta8084030436bce24\/CICD_eBook_Web.pdf\">qui<\/a><\/noindex>.)<\/p>\n<p>In questo articolo discuteremo varie strategie di deployment in Kubernetes, includendo distribuzioni rolling e metodi pi\u00f9 avanzati, come i canary deployment e le loro varianti.<\/p>\n<h2>Strategie di deploy<\/h2>\n<p>\nEsistono diversi tipi di strategie di distribuzione che possono essere utilizzate a seconda dell'obiettivo. Ad esempio, potresti aver bisogno di apportare modifiche a un ambiente per ulteriori test, o a un sottoinsieme di utenti\/clienti, oppure potrebbe essere necessario effettuare un test limitato sugli utenti prima di rendere una funzionalit\u00e0 <i>pubblica<\/i>.<\/p>\n<h3>Rolling (distribuzione progressiva)<\/h3>\n<p>\nQuesta \u00e8 una strategia di distribuzione standard in Kubernetes. Sostituisce gradualmente, uno dopo l'altro, i pod con la vecchia versione dell'applicazione con quelli con la nuova versione - senza downtime per il cluster.<\/p>\n<p><img decoding=\"async\" alt=\"Strategie di deploy 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 funzionare (verificandoli con <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 alla rimozione dei pod vecchi. Se si verifica un problema, un aggiornamento graduale pu\u00f2 essere interrotto senza fermare l'intero cluster. Nel file YAML che descrive il tipo di distribuzione, 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 per l'aggiornamento progressivo 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 (ri-creazione)<\/h3>\n<p>\nIn questo tipo pi\u00f9 semplice di distribuzione, i pod vecchi vengono eliminati tutti insieme e sostituiti da nuovi:<\/p>\n<p><img decoding=\"async\" alt=\"Strategie di deploy 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 circa 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 blue-green)<\/h3>\n<p>\nLa strategia blue-green (a volte chiamata anche red\/black) prevede il contemporaneo deployment della versione vecchia (green) e di quella nuova (blue) dell'applicazione. Dopo il deployment di entrambe le versioni, gli utenti normali hanno accesso alla versione green, mentre la blue \u00e8 disponibile per il team QA per test automatizzati tramite un servizio dedicato o un port forwarding diretto:<\/p>\n<p><img decoding=\"async\" alt=\"Strategie di deploy 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 blue (nuova) \u00e8 stata testata e il suo rilascio \u00e8 stato approvato, il servizio viene commutato su di essa, mentre la versione green (vecchia) viene ritirata:<\/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 canary)<\/h3>\n<p>\nLe distribuzioni canary sono simili alle blue-green, ma sono meglio gestite e utilizzano <noindex><a rel=\"nofollow\" href=\"https:\/\/redmonk.com\/jgovernor\/2018\/08\/06\/towards-progressive-delivery\/\">un approccio<\/a><\/noindex> progressivo. Questo tipo comprende diverse strategie, tra cui i 'lanci stealth' e il testing A\/B.<\/p>\n<p>Questa strategia viene applicata quando \u00e8 necessario testare una nuova funzionalit\u00e0, solitamente nel backend dell'applicazione. Il concetto alla base \u00e8 creare due server praticamente identici: uno gestisce quasi tutti gli utenti, mentre l'altro, con nuove funzionalit\u00e0, gestisce solo un piccolo sottoinsieme di utenti, dopo di che i risultati vengono confrontati. Se tutto procede senza errori, la nuova versione viene gradualmente distribuita all'intera infrastruttura.<\/p>\n<p>Sebbene questa strategia possa essere realizzata esclusivamente tramite Kubernetes, sostituendo i pod vecchi con i nuovi, \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 \"canary\" con il tag 0.2.0. Modificando i pesi nel manifesto del gateway virtuale di Istio, \u00e8 possibile gestire la distribuzione del traffico tra queste due distribuzioni:<\/p>\n<p><img decoding=\"async\" alt=\"Strategie di deploy 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 canarini con 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 del traduttore.<\/b>: Abbiamo anche tradotto il materiale sui deployment canarini in Istio <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/440378\/\">qui<\/a><\/noindex>.)<\/i><\/p>\n<h4>Canary Deployments with Weaveworks Flagger<\/h4>\n<p>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/docs.flagger.app\/\">Weaveworks Flagger<\/a><\/noindex> consente di gestire facilmente ed efficacemente i deployment canarini.<\/p>\n<p>Flagger automatizza il lavoro con essi. Utilizza Istio o AWS App Mesh per instradare e commutare il traffico, oltre a metriche Prometheus per analizzare i risultati. Inoltre, l'analisi dei deployment canarini pu\u00f2 essere arricchita con webhook per eseguire test di accettazione, test di carico e qualsiasi altro tipo di controllo.<\/p>\n<p>Basandosi sulla distribuzione di Kubernetes e, se necessario, sullo scaling orizzontale dei pod (HPA), Flagger crea set di oggetti (distribuzioni Kubernetes, servizi ClusterIP e servizi virtuali Istio o App Mesh) per analizzare e implementare distribuzioni canary:<\/p>\n<p><img decoding=\"async\" alt=\"Strategie di deploy 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 canary, misurando parallelamente le metriche chiave di prestazione, come la percentuale di richieste HTTP riuscite, la durata media delle richieste e la salute dei pod. Basandosi sull'analisi dei KPI (indicatori chiave di prestazione), la parte canary cresce o diminuisce e i risultati dell'analisi vengono pubblicati su Slack. Puoi trovare una descrizione e una dimostrazione di questo processo 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 deploy 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>Deployment Dark (nascosti) o A\/B<\/h3>\n<p>\nIl deployment nascosto \u00e8 un'altra variazione della strategia canarina (con cui, tra l'altro, Flagger pu\u00f2 lavorare). La differenza tra un deployment nascosto e uno canarino \u00e8 che i deployment nascosti riguardano il frontend, non il backend, come i canarini.<\/p>\n<p>Un altro nome per questi deployment \u00e8 A\/B testing. Invece di rendere disponibile una nuova funzionalit\u00e0 a tutti gli utenti, viene proposta solo a una parte limitata di essi. Di solito questi utenti non sanno di essere i tester pionieri (da qui il termine 'deployment nascosto').<\/p>\n<p>Con i toggles delle funzionalit\u00e0 <i>(feature toggles)<\/i> e altri strumenti \u00e8 possibile monitorare come gli utenti interagiscono con la nuova funzionalit\u00e0, se li coinvolge o se trovano la nuova interfaccia utente confusa, e altre tipologie di metriche.<\/p>\n<p><img decoding=\"async\" alt=\"Strategie di deploy 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 A\/B Deployments<\/h4>\n<p>\nOltre all'instradamento basato sui pesi, Flagger pu\u00f2 anche indirizzare il traffico verso il server canarino in base alle impostazioni HTTP. Nello A\/B testing possono essere utilizzati gli header HTTP o i cookie per reindirizzare un segmento specifico di utenti. Questo \u00e8 particolarmente efficace per le applicazioni frontend che richiedono l'affinit\u00e0 della sessione con il server <i>(session affinity)<\/i>. Maggiori informazioni possono essere trovate nella documentazione di Flagger.<\/p>\n<p><i>L'autore esprime gratitudine <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/stefanprodan\">Stefan Prodan<\/a><\/noindex>, ingegnere di Weaveworks (e creatore di Flagger), per tutte queste fantastiche diagrammi di deployment.<\/i><\/p>\n<h2>P.S. dal traduttore<\/h2>\n<p>\nLeggete anche nel nostro blog:<\/p>\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/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\/\">Costruzione e deploy 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.0.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.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\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 Deployment 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}]}}