{"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\/de\/blog\/administrirovanie\/strategii-deploya-v-kubernetes-rolling-recreate-blue-green-canary-dark-a-b-testirovanie","title":{"rendered":"Bereitstellungsstrategien in Kubernetes: rolling, recreate, blue\/green, canary, dark (A\/B-Testing)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><i><b>Hinw. \u00dc.:<\/b> Dieses \u00dcberblicksmaterial von Weaveworks stellt die beliebtesten Strategien f\u00fcr die Bereitstellung von Anwendungen vor und erl\u00e4utert, wie die fortschrittlichsten von ihnen mit dem Kubernetes-Operator Flagger umgesetzt werden k\u00f6nnen. Es ist in einfacher Sprache verfasst und enth\u00e4lt anschauliche Diagramme, die selbst Anf\u00e4ngern helfen, die Thematik zu verstehen.<\/i><\/p>\n<p><img decoding=\"async\" alt=\"Bereitstellungsstrategien 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>Das Diagramm stammt aus <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.container-solutions.com\/kubernetes-deployment-strategies\">einer anderen \u00dcbersicht<\/a><\/noindex> zu Bereitstellungsstrategien, die von Container Solutions erstellt wurde.<\/i><\/p>\n<p>Eines der gr\u00f6\u00dften Probleme bei der Entwicklung von Cloud-Native-Anwendungen heute ist die Beschleunigung des Deployments. Bei einem Microservices-Ansatz arbeiten Entwickler bereits mit vollst\u00e4ndig modularen Anwendungen und gestalten diese so, dass verschiedene Teams gleichzeitig Code schreiben und \u00c4nderungen an der Anwendung vornehmen k\u00f6nnen.<\/p>\n<p>K\u00fcrzere und h\u00e4ufigere Bereitstellungen bieten folgende Vorteile:<\/p>\n<ul>\n<li> Die Markteinf\u00fchrungszeit wird verk\u00fcrzt.<\/li>\n<li> Neue Funktionen erreichen die Nutzer schneller.<\/li>\n<li> Nutzerfeedback gelangt schneller zum Entwicklerteam. Das bedeutet, dass das Team Funktionen erg\u00e4nzen und Probleme schneller beheben kann.<\/li>\n<li> Die Moral der Entwickler steigt: Mit einer gr\u00f6\u00dferen Anzahl von Funktionen macht die Arbeit mehr Spa\u00df.<\/li>\n<\/ul>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\nDoch mit einer erh\u00f6hten Release-H\u00e4ufigkeit steigen auch die Chancen, negative Auswirkungen auf die Zuverl\u00e4ssigkeit der Anwendung oder das Nutzererlebnis zu haben. Aus diesem Grund ist es f\u00fcr Betriebs- und DevOps-Teams wichtig, Prozesse zu gestalten und Bereitstellungsstrategien so zu managen, dass Risiken f\u00fcr das Produkt und die Nutzer minimiert werden. (Mehr \u00fcber die Automatisierung von CI\/CD-Pipelines erfahren Sie <noindex><a rel=\"nofollow\" href=\"https:\/\/www.weave.works\/assets\/images\/blta8084030436bce24\/CICD_eBook_Web.pdf\">hier<\/a><\/noindex>.)<\/p>\n<p>In dieser Ver\u00f6ffentlichung werden wir verschiedene Bereitstellungsstrategien in Kubernetes diskutieren, einschlie\u00dflich Rolling-Bereitstellungen und fortgeschrittenere Methoden wie Canary-Deployments und deren Varianten.<\/p>\n<h2>Bereitstellungsstrategien<\/h2>\n<p>\nEs gibt mehrere verschiedene Arten von Bereitstellungsstrategien, die je nach Ziel genutzt werden k\u00f6nnen. Zum Beispiel k\u00f6nnte es notwendig sein, \u00c4nderungen an einer bestimmten Umgebung f\u00fcr weitere Tests vorzunehmen, oder an einer Teilmenge von Nutzern\/Kunden, oder es k\u00f6nnte erforderlich sein, beschr\u00e4nkte Tests an Nutzern durchzuf\u00fchren, bevor eine Funktion <i>\u00f6ffentlich zug\u00e4nglich gemacht wird.<\/i>.<\/p>\n<h3>Rolling (schrittweises, 'aufschichtendes' Deployment)<\/h3>\n<p>\nDies ist die Standard-Deploy-Strategie in Kubernetes. Sie ersetzt schrittweise, einen nach dem anderen, Pods mit der alten Version der Anwendung durch Pods mit der neuen Version \u2013 ohne Ausfall des Clusters.<\/p>\n<p><img decoding=\"async\" alt=\"Bereitstellungsstrategien 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 wartet auf die Einsatzbereitschaft der neuen Pods (indem es diese \u00fcberpr\u00fcft mit <noindex><a rel=\"nofollow\" href=\"https:\/\/www.weave.works\/blog\/resilient-apps-with-liveness-and-readiness-probes-in-kubernetes\">Readiness-Tests<\/a><\/noindex>), bevor es mit der Stilllegung der alten beginnt. Wenn ein Problem auftritt, kann dieses rollende Update unterbrochen werden, ohne das gesamte Cluster zu stoppen. In der YAML-Datei zur Beschreibung des Deployment-Typs ersetzt das neue Image das alte Image:<\/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>\nDie Parameter des Rolling-Updates k\u00f6nnen in der Manifestdatei spezifiziert werden:<\/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 (Neuerstellung)<\/h3>\n<p>\nIn diesem einfachsten Deploy-Typ werden die alten Pods gleichzeitig alle beendet und durch neue ersetzt:<\/p>\n<p><img decoding=\"async\" alt=\"Bereitstellungsstrategien 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 \/>\nDas entsprechende Manifest sieht ungef\u00e4hr so aus:<\/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 (Blau-Gr\u00fcne Bereitstellungen)<\/h3>\n<p>\nDie Blue-Green-Bereitstellungsstrategie (manchmal auch als Red\/Black bezeichnet) sieht die gleichzeitige Bereitstellung der alten (gr\u00fcnen) und der neuen (blauen) Version der Anwendung vor. Nach der Bereitstellung beider Versionen haben normale Benutzer Zugriff auf die gr\u00fcne Version, w\u00e4hrend die blaue f\u00fcr das QA-Team zum Testen \u00fcber einen separaten Dienst oder einen direkten Portdurchlauf verf\u00fcgbar ist:<\/p>\n<p><img decoding=\"async\" alt=\"Bereitstellungsstrategien 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>\nNachdem die blaue (neue) Version getestet und ihr Release genehmigt wurde, wird der Dienst auf diese umgeschaltet und die gr\u00fcne (alte) wird abgebaut:<\/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 (Kanaren-Bereitstellungen)<\/h3>\n<p>\nCanary-Rollouts sind \u00e4hnlich wie Blue-Green, aber besser steuerbar und verwenden <noindex><a rel=\"nofollow\" href=\"https:\/\/redmonk.com\/jgovernor\/2018\/08\/06\/towards-progressive-delivery\/\">einen progressiven<\/a><\/noindex> stufenweisen Ansatz. Zu diesem Typ geh\u00f6ren mehrere verschiedene Strategien, einschlie\u00dflich \u201eHidden\u201c Versionen und A\/B-Testing.<\/p>\n<p>Diese Strategie wird angewendet, wenn es notwendig ist, eine neue Funktionalit\u00e4t auszuprobieren, typischerweise im Backend der Anwendung. Der Ansatz besteht darin, zwei nahezu identische Server zu erstellen: Einer bedient fast alle Benutzer, w\u00e4hrend der andere mit neuen Funktionen nur eine kleine Untergruppe von Benutzern bedient, und die Ergebnisse ihrer Leistung anschlie\u00dfend verglichen werden. Wenn alles fehlerfrei verl\u00e4uft, wird die neue Version schrittweise auf die gesamte Infrastruktur ausgerollt.<\/p>\n<p>Obwohl diese Strategie ausschlie\u00dflich mit Mitteln von Kubernetes umgesetzt werden kann, indem alte Pods durch neue ersetzt werden, ist es viel bequemer und einfacher, ein Service Mesh wie Istio zu verwenden.<\/p>\n<p>Zum Beispiel k\u00f6nnen Sie zwei verschiedene Manifeste in Git haben: eines mit dem Tag 0.1.0 und ein \u201ecanary\u201c mit dem Tag 0.2.0. Durch \u00c4ndern der Gewichte im Istio Virtual Gateway-Manifest k\u00f6nnen Sie den Datenverkehr zwischen diesen beiden Deployments steuern:<\/p>\n<p><img decoding=\"async\" alt=\"Bereitstellungsstrategien 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 \/>\nEine schrittweise Anleitung zur Implementierung von Kanarienvogel-Deployments mit Istio finden Sie in dem Artikel <noindex><a rel=\"nofollow\" href=\"https:\/\/www.weave.works\/blog\/gitops-workflows-for-istio-canary-deployments\">GitOps Workflows with Istio<\/a><\/noindex>. <i>(<b>Anmerkung des \u00dcbersetzers.<\/b>: Wir haben auch Materialien zu Kanarienvogel-Rollouts in Istio \u00fcbersetzt <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/440378\/\">hier<\/a><\/noindex>.)<\/i><\/p>\n<h4>Kanarienvogel-Deployments mit Weaveworks Flagger<\/h4>\n<p>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/docs.flagger.app\/\">Weaveworks Flagger<\/a><\/noindex> erm\u00f6glicht eine einfache und effektive Verwaltung von Kanarienvogel-Rollouts.<\/p>\n<p>Flagger automatisiert deren Umgang. Er nutzt Istio oder AWS App Mesh f\u00fcr die Routen- und Traffic-Umsteuerung sowie Prometheus-Metriken zur Analyse der Ergebnisse. Dar\u00fcber hinaus kann die Analyse der Kanarienvogel-Deployments durch Webhooks erg\u00e4nzt werden, um Abnahmepr\u00fcfungen, Lasttests und andere Arten von \u00dcberpr\u00fcfungen durchzuf\u00fchren.<\/p>\n<p>Basierend auf dem Kubernetes-Deployment und, falls erforderlich, der horizontalen Skalierung der Pods (HPA), erstellt Flagger Gruppen von Objekten (Kubernetes-Deployments, ClusterIP-Services und Istio oder App Mesh Virtual Services) zur Durchf\u00fchrung von Analysen und zur Implementierung von Canary-Deployments:<\/p>\n<p><img decoding=\"async\" alt=\"Bereitstellungsstrategien 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 \/>\nIndem er den Kontrollkreis <i>(control loop)<\/i>, Flagger leitet schrittweise den Datenverkehr auf den Canary-Server um, w\u00e4hrend gleichzeitig wichtige Leistungskennzahlen wie die Erfolgsquote erfolgreicher HTTP-Anfragen, die durchschnittliche Anfragedauer und die Gesundheit der Pods gemessen werden. Basierend auf der Analyse der KPIs (Key Performance Indicators) w\u00e4chst oder schrumpft der Canary-Teil, und die Analyseergebnisse werden in Slack ver\u00f6ffentlicht. Eine Beschreibung und Demo dieses Prozesses finden Sie im Material. <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=\"Bereitstellungsstrategien 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>Dunkel (versteckt) oder A\/B-Deployment<\/h3>\n<p>\nVerstecktes Deployment ist eine weitere Variante der Kanarienstrategien (\u00fcbrigens kann Flagger auch damit arbeiten). Der Unterschied zwischen verstecktem und kanarienartigem Deployment besteht darin, dass versteckte Deployments sich mit dem Frontend und nicht mit dem Backend befassen, wie es bei kanarienartigen Deployments der Fall ist.<\/p>\n<p>Ein anderer Name f\u00fcr diese Deployments ist A\/B-Testing. Anstatt den Zugriff auf eine neue Funktion f\u00fcr alle Benutzer zu \u00f6ffnen, wird sie nur einer begrenzten Gruppe angeboten. In der Regel wissen diese Benutzer nicht, dass sie als Testpersonen agieren (daher der Begriff \u201everstecktes Deployment\u201c).<\/p>\n<p>Mit Hilfe von Funktionstastenschaltern <i>(feature toggles)<\/i> und anderen Tools kann verfolgt werden, wie Benutzer mit der neuen Funktion interagieren, ob sie ansprechend ist oder ob die neue Benutzeroberfl\u00e4che verwirrend erscheint, sowie andere Arten von Metriken.<\/p>\n<p><img decoding=\"async\" alt=\"Bereitstellungsstrategien 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 und A\/B-Deployments<\/h4>\n<p>\nNeben der Gewichtung der Routing-Parameter kann Flagger auch den Traffic auf einen kanarienartigen Server basierend auf HTTP-Parametern lenken. Beim A\/B-Testing k\u00f6nnen HTTP-Header oder Cookies verwendet werden, um einen bestimmten Benutzersegment zu leiten. Dies ist besonders effektiv bei Frontend-Anwendungen, die eine Sitzungsbindung an den Server erfordern <i>(session affinity)<\/i>. Weitere Informationen finden Sie in der Dokumentation von Flagger.<\/p>\n<p><i>Der Autor bedankt sich bei <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/stefanprodan\">Stefan Prodan<\/a><\/noindex>, Ingenieur bei Weaveworks (und Sch\u00f6pfer von Flagger), f\u00fcr all diese erstaunlichen Deployment-Schemata.<\/i><\/p>\n<h2>P.S. vom \u00dcbersetzer<\/h2>\n<p>\nLesen Sie auch in unserem Blog:<\/p>\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/447180\/\">\u00dcberblick und Vergleich von Ingress-Controllern f\u00fcr Kubernetes<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/460351\/\">Release des Konsolen-XMPP\/Jabber-Clients profanity 0.7.0<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/469541\/\">Bau und Deployment identischer Mikrodienste mit werf und GitLab CI<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/458878\/\">Was ist GitOps?<\/a><\/noindex>\u00bb.<\/li>\n<\/ul>\n<p>Quelle: <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\/de\/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=\"de_DE\" \/>\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\/de\/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\udd47Deployment-Strategien in Kubernetes: rolling, recreate, blue\/green, canary, dark (A\/B-Testing) | ProHoster","description":"z.B.","canonical_url":"https:\/\/prohoster.info\/de\/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":"de_DE","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\/de\/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\/de\/wp-json\/wp\/v2\/posts\/52688","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/comments?post=52688"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/52688\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=52688"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=52688"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=52688"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}