{"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":"Deployment-Strategien in Kubernetes: rolling, recreate, blue\/green, canary, dark (A\/B-Testing)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><i><b>Hinweis zur \u00dcbersetzung:<\/b> Dieses \u00dcbersichtsmaterial von Weaveworks stellt die beliebtesten Strategien f\u00fcr das Deployment von Anwendungen vor und erkl\u00e4rt, wie die fortschrittlichsten dieser Strategien mit dem Kubernetes-Operator Flagger realisiert werden k\u00f6nnen. Es ist in einfacher Sprache verfasst und enth\u00e4lt anschauliche Diagramme, die es selbst Einsteigern erm\u00f6glichen, die Materie zu verstehen.<\/i><\/p>\n<p><img decoding=\"async\" alt=\"Deployment-Strategien 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 wurde aus <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.container-solutions.com\/kubernetes-deployment-strategies\">einer anderen \u00dcbersicht<\/a><\/noindex> \u00fcber Strategien f\u00fcr das Deployment, erstellt bei Container Solutions, entnommen.<\/i><\/p>\n<p>Eine der gr\u00f6\u00dften Herausforderungen bei der Entwicklung von Cloud-Native-Anwendungen ist heute die Beschleunigung des Deployments. Mit dem Mikrodienstansatz 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 Deployments bieten folgende Vorteile:<\/p>\n<ul>\n<li> Die Markteinf\u00fchrungszeit verk\u00fcrzt sich.<\/li>\n<li> Neue Funktionen erreichen die Benutzer schneller.<\/li>\n<li> Benutzerfeedback gelangt schneller zum Entwicklerteam. Das bedeutet, dass das Team Funktionen schneller erg\u00e4nzen und Probleme z\u00fcgiger beheben kann.<\/li>\n<li> Die Moral der Entwickler steigt: Mit mehr Funktionen macht die Arbeit an der Entwicklung mehr Spa\u00df.<\/li>\n<\/ul>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\nMit der erh\u00f6hten Freigabefrequenz steigen jedoch auch die Risiken, die Zuverl\u00e4ssigkeit der Anwendung oder die Benutzererfahrung negativ zu beeinflussen. Daher ist es f\u00fcr Betriebsteams und DevOps wichtig, Prozesse zu gestalten und Bereitstellungsstrategien so zu verwalten, dass Risiken f\u00fcr das Produkt und die Nutzer minimiert werden. (Erfahren Sie mehr \u00fcber die Automatisierung von CI\/CD-Pipelines <noindex><a rel=\"nofollow\" href=\"https:\/\/www.weave.works\/assets\/images\/blta8084030436bce24\/CICD_eBook_Web.pdf\">hier<\/a><\/noindex>.)<\/p>\n<p>In diesem Beitrag werden wir verschiedene Bereitstellungsstrategien in Kubernetes diskutieren, einschlie\u00dflich Rolling Deployments und fortgeschrittenerer Methoden wie Canary Releases und deren Variationen.<\/p>\n<h2>Deployment-Strategien<\/h2>\n<p>\nEs gibt mehrere verschiedene Arten von Bereitstellungsstrategien, die je nach Ziel eingesetzt werden k\u00f6nnen. Zum Beispiel m\u00fcssen Sie m\u00f6glicherweise \u00c4nderungen in einer Umgebung f\u00fcr weitere Tests vornehmen, oder in einer Teilmenge von Nutzern\/Kunden, oder es kann erforderlich sein, umfangreiche Tests mit Nutzern durchzuf\u00fchren, bevor eine Funktion <i>\u00f6ffentlich zug\u00e4nglich gemacht wird.<\/i>.<\/p>\n<h3>Rolling (schrittweiser, \"laufender\" Deployment)<\/h3>\n<p>\nDies ist eine Standard-Deployment-Strategie in Kubernetes. Sie ersetzt schrittweise, ein Pod 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=\"Deployment-Strategien 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 darauf, dass die neuen Pods betriebsbereit sind (indem es sie 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 Au\u00dferbetriebnahme der alten Pods beginnt. Wenn ein Problem auftritt, kann ein solches rollierendes Update unterbrochen werden, ohne das gesamte Cluster zu stoppen. In der YAML-Datei, die den Deployment-Typ beschreibt, 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 f\u00fcr das Rolling-Update k\u00f6nnen im 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 (Wiederherstellung)<\/h3>\n<p>\nBei diesem einfachsten Deployment-Typ werden die alten Pods auf einmal beendet und durch neue ersetzt:<\/p>\n<p><img decoding=\"async\" alt=\"Deployment-Strategien 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 etwa 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 (Blue\/Green Deployments)<\/h3>\n<p>\nDie Blue-Green-Deployment-Strategie (auch als Red\/Black-Deployment bekannt) erm\u00f6glicht das gleichzeitige Bereitstellen der alten (gr\u00fcnen) und der neuen (blauen) Version einer Anwendung. Nach der Bereitstellung beider Versionen haben die regul\u00e4ren Benutzer Zugang zur gr\u00fcnen Version, w\u00e4hrend die blaue f\u00fcr das QA-Team zur Automatisierung von Tests \u00fcber einen separaten Service oder durch direkten Port-Durchlauf verf\u00fcgbar ist.<\/p>\n<p><img decoding=\"async\" alt=\"Deployment-Strategien 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 Service auf diese umgeschaltet, w\u00e4hrend die gr\u00fcne (alte) Version abgeschaltet wird:<\/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-Deployments<\/h3>\n<p>\nCanary-Deployments \u00e4hneln Blue-Green-Deployments, sind jedoch besser steuerbar und nutzen <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 verschiedene Strategien, einschlie\u00dflich \u201eversteckter\u201c Launches und A\/B-Tests.<\/p>\n<p>Diese Strategie wird angewendet, wenn eine neue Funktionalit\u00e4t getestet werden muss, typischerweise im Backend der Anwendung. Der Ansatz besteht darin, zwei nahezu identische Server zu erstellen: Einer bedient fast alle Benutzer, w\u00e4hrend der andere, der die neuen Funktionen enth\u00e4lt, nur eine kleine Benutzergruppe bedient. Anschlie\u00dfend werden die Ergebnisse verglichen. Wenn alles fehlerfrei verl\u00e4uft, wird die neue Version schrittweise auf die gesamte Infrastruktur ausgerollt.<\/p>\n<p>Obwohl diese Strategie rein 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\u00f6nnten Sie zwei verschiedene Manifeste in Git haben: eines mit dem Tag 0.1.0 und ein \"canary\"-Manifest mit dem Tag 0.2.0. Durch \u00c4ndern der Gewichte im Manifest des virtuellen Istio-Gateways k\u00f6nnen Sie den Traffic zwischen diesen beiden Deployments steuern:<\/p>\n<p><img decoding=\"async\" alt=\"Deployment-Strategien 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 Schritt-f\u00fcr-Schritt-Anleitung zur Umsetzung von Canary-Deployments mit Istio finden Sie in dem Material <noindex><a rel=\"nofollow\" href=\"https:\/\/www.weave.works\/blog\/gitops-workflows-for-istio-canary-deployments\">GitOps-Workflows mit Istio<\/a><\/noindex>. <i>(<b>Hinweis.<\/b>: Wir haben auch das Material zu Canary-Rollouts in Istio \u00fcbersetzt <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/440378\/\">hier<\/a><\/noindex>.)<\/i><\/p>\n<h4>Canary-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 Canary-Deployments.<\/p>\n<p>Flagger automatisiert die Arbeit mit ihnen. Er verwendet Istio oder AWS App Mesh zur Verkehrslenkung und -umleitung sowie Prometheus-Metriken zur Analyse der Ergebnisse. Zudem kann die Analyse der Canary-Deployments durch Webhooks erg\u00e4nzt werden, um Akzeptanztests, Lasttests und andere Arten von \u00dcberpr\u00fcfungen durchzuf\u00fchren.<\/p>\n<p>Basierend auf dem Kubernetes-Deployment und, falls notwendig, der horizontalen Skalierung der Pods (HPA), erstellt Flagger S\u00e4tze von Objekten (Kubernetes-Deployments, ClusterIP-Dienste und virtuelle Istio- oder App Mesh-Dienste) zur Analyse und Durchf\u00fchrung von Canary-Deployments:<\/p>\n<p><img decoding=\"async\" alt=\"Deployment-Strategien 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 \/>\nDurch Implementierung des <i>(Steuerungszyklus)<\/i>, Flagger leitet schrittweise den Traffic auf den Canary-Server um, w\u00e4hrend es wichtige Leistungskennzahlen (KPI) wie die Erfolgsquote der HTTP-Anfragen, die durchschnittliche Anforderungsdauer und den Zustand der Pods misst. Basierend auf der Analyse der KPI w\u00e4chst oder schrumpft der Canary-Teil, und die Analyseergebnisse werden in Slack ver\u00f6ffentlicht. Eine Beschreibung und Demonstration dieses Prozesses finden Sie im Material. <noindex><a rel=\"nofollow\" href=\"https:\/\/www.weave.works\/blog\/progressive-delivery-for-aws-app-mesh\">Progressive Delivery f\u00fcr App Mesh<\/a><\/noindex>.<\/p>\n<p><img decoding=\"async\" alt=\"Deployment-Strategien 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>Dark (versteckte) oder A\/B-Deployments<\/h3>\n<p>\nVerstecktes Deployment ist eine weitere Variation der Kanarienstrategie (\u00fcbrigens kann Flagger auch damit arbeiten). Der Unterschied zwischen verstecktem und Kanarien-Deployment besteht darin, dass versteckte Deployments sich mit dem Frontend befassen, w\u00e4hrend Kanarien-Deployments sich auf das Backend konzentrieren.<\/p>\n<p>Ein anderer Begriff f\u00fcr diese Deployments ist A\/B-Testing. Anstatt einer neuen Funktion allen Nutzern Zugang zu gew\u00e4hren, wird sie nur einer begrenzten Anzahl von ihnen angeboten. Normalerweise wissen diese Nutzer nicht, dass sie als Testpersonen auftreten (daher der Begriff \"verstecktes Deployment\").<\/p>\n<p>Mit Hilfe von Funktionst\u00fcchern <i>(feature toggles)<\/i> und anderen Werkzeugen kann verfolgt werden, wie Nutzer mit der neuen Funktion interagieren, ob sie sie ansprechend finden oder ob sie die neue Benutzeroberfl\u00e4che verwirrend empfinden, sowie andere Arten von Metriken.<\/p>\n<p><img decoding=\"async\" alt=\"Deployment-Strategien 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 gewichteten Weiterleitung kann Flagger auch den Traffic zu einem Canary-Server basierend auf HTTP-Parametern leiten. Bei A\/B-Tests k\u00f6nnen HTTP-Header oder Cookies verwendet werden, um einen bestimmten Benutzersegment umzuleiten. Dies ist besonders effektiv bei Frontend-Anwendungen, die eine Sitzungsbindung an den Server erfordern. <i>(Sitzungsbindung)<\/i>. Weitere Informationen finden Sie in der Flagger-Dokumentation.<\/p>\n<p><i>Der Autor dankt <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 gro\u00dfartigen 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\/\">werf \u2014 unser Tool f\u00fcr CI\/CD in Kubernetes (\u00dcbersicht und Video des Vortrags)<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/469541\/\">Der Aufbau und das Deployment \u00e4hnlicher 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.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\/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.0.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-Tests) | ProHoster","description":"Hinweis:","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}]}}