Hinweis zur Übersetzung: Dieses Übersichtsmaterial von Weaveworks stellt die beliebtesten Strategien für das Deployment von Anwendungen vor und erklärt, wie die fortschrittlichsten dieser Strategien mit dem Kubernetes-Operator Flagger realisiert werden können. Es ist in einfacher Sprache verfasst und enthält anschauliche Diagramme, die es selbst Einsteigern ermöglichen, die Materie zu verstehen.
Das Diagramm wurde aus über Strategien für das Deployment, erstellt bei Container Solutions, entnommen.
Eine der größten Herausforderungen bei der Entwicklung von Cloud-Native-Anwendungen ist heute die Beschleunigung des Deployments. Mit dem Mikrodienstansatz arbeiten Entwickler bereits mit vollständig modularen Anwendungen und gestalten diese so, dass verschiedene Teams gleichzeitig Code schreiben und Änderungen an der Anwendung vornehmen können.
Kürzere und häufigere Deployments bieten folgende Vorteile:
- Die Markteinführungszeit verkürzt sich.
- Neue Funktionen erreichen die Benutzer schneller.
- Benutzerfeedback gelangt schneller zum Entwicklerteam. Das bedeutet, dass das Team Funktionen schneller ergänzen und Probleme zügiger beheben kann.
- Die Moral der Entwickler steigt: Mit mehr Funktionen macht die Arbeit an der Entwicklung mehr Spaß.
Mit der erhöhten Freigabefrequenz steigen jedoch auch die Risiken, die Zuverlässigkeit der Anwendung oder die Benutzererfahrung negativ zu beeinflussen. Daher ist es für Betriebsteams und DevOps wichtig, Prozesse zu gestalten und Bereitstellungsstrategien so zu verwalten, dass Risiken für das Produkt und die Nutzer minimiert werden. (Erfahren Sie mehr über die Automatisierung von CI/CD-Pipelines .)
In diesem Beitrag werden wir verschiedene Bereitstellungsstrategien in Kubernetes diskutieren, einschließlich Rolling Deployments und fortgeschrittenerer Methoden wie Canary Releases und deren Variationen.
Deployment-Strategien
Es gibt mehrere verschiedene Arten von Bereitstellungsstrategien, die je nach Ziel eingesetzt werden können. Zum Beispiel müssen Sie möglicherweise Änderungen in einer Umgebung für weitere Tests vornehmen, oder in einer Teilmenge von Nutzern/Kunden, oder es kann erforderlich sein, umfangreiche Tests mit Nutzern durchzuführen, bevor eine Funktion öffentlich zugänglich gemacht wird..
Rolling (schrittweiser, "laufender" Deployment)
Dies ist eine Standardbereitstellungsstrategie in Kubernetes. Sie ersetzt schrittweise, einer nach dem anderen, Pods mit der alten Version der Anwendung durch Pods mit der neuen Version – ohne Ausfallzeiten für den Cluster.
Kubernetes wartet, bis die neuen Pods betriebsbereit sind (indem es diese überprüft mit ), bevor es mit dem Herunterfahren der alten Pods beginnt. Wenn ein Problem auftritt, kann ein solches Rolling-Update abgebrochen werden, ohne den gesamten Cluster anzuhalten. In der YAML-Datei, die den Typ der Bereitstellung beschreibt, ersetzt das neue Image das alte Image:
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: awesomeapp
spec:
replicas: 3
template:
metadata:
labels:
app: awesomeapp
spec:
containers:
- name: awesomeapp
image: imagerepo-user/awesomeapp:new
ports:
- containerPort: 8080Die Parameter für das Rolling-Update können im Manifestdatei spezifiziert werden:
spec:
replicas: 3
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
template:
...
Recreate (Wiederherstellung)
Bei diesem einfachsten Bereitstellungstyp werden die alten Pods alle auf einmal beendet und durch neue ersetzt:
Das entsprechende Manifest sieht etwa so aus:
spec:
replicas: 3
strategy:
type: Recreate
template:
...Blue/Green (Blue/Green Deployments)
Die Blue-Green-Deployment-Strategie (auch als Red/Black-Deployment bekannt) ermöglicht das gleichzeitige Bereitstellen der alten (grünen) und der neuen (blauen) Version einer Anwendung. Nach der Bereitstellung beider Versionen haben die regulären Benutzer Zugang zur grünen Version, während die blaue für das QA-Team zur Automatisierung von Tests über einen separaten Service oder durch direkten Port-Durchlauf verfügbar ist.
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: awesomeapp-02
spec:
template:
metadata:
labels:
app: awesomeapp
version: "02"Nachdem die blaue (neue) Version getestet und ihr Release genehmigt wurde, wird der Service auf diese umgeschaltet, während die grüne (alte) Version abgeschaltet wird:
apiVersion: v1
kind: Service
metadata:
name: awesomeapp
spec:
selector:
app: awesomeapp
version: "02"
...Canary-Deployments
Canary-Deployments ähneln Blue-Green-Deployments, sind jedoch besser steuerbar und nutzen stufenweisen Ansatz. Zu diesem Typ gehören verschiedene Strategien, einschließlich „versteckter“ Launches und A/B-Tests.
Diese Strategie wird angewendet, wenn eine neue Funktionalität getestet werden muss, typischerweise im Backend der Anwendung. Der Ansatz besteht darin, zwei nahezu identische Server zu erstellen: Einer bedient fast alle Benutzer, während der andere, der die neuen Funktionen enthält, nur eine kleine Benutzergruppe bedient. Anschließend werden die Ergebnisse verglichen. Wenn alles fehlerfrei verläuft, wird die neue Version schrittweise auf die gesamte Infrastruktur ausgerollt.
Obwohl diese Strategie ausschließlich mit Kubernetes realisiert werden kann, indem alte Pods durch neue ersetzt werden, ist es viel einfacher und bequemer, ein Service Mesh wie Istio zu verwenden.
Zum Beispiel könnten 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 Ändern der Gewichte im Istio-Virtual-Gateway-Manifest können Sie den Datenverkehr zwischen diesen beiden Deployments steuern:
Eine Schritt-für-Schritt-Anleitung zur Umsetzung von Canary-Deployments mit Istio finden Sie in dem Material . (Hinweis.: Wir haben auch das Material zu Canary-Rollouts in Istio übersetzt .)
Canary-Deployments mit Weaveworks Flagger
ermöglicht eine einfache und effektive Verwaltung von Canary-Deployments.
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änzt werden, um Akzeptanztests, Lasttests und andere Arten von Überprüfungen durchzuführen.
Basierend auf dem Kubernetes-Deployment und bei Bedarf der horizontalen Skalierung von Pods (HPA), erstellt Flagger Gruppen von Objekten (Kubernetes-Deployments, ClusterIP-Services und virtuelle Istio- oder App Mesh-Services) für die Analyse und Umsetzung von Canary-Deployments:
Durch Implementierung des (Steuerungszyklus), lenkt Flagger schrittweise den Verkehr auf den Canary-Server und misst gleichzeitig Schlüsselkennzahlen wie den Anteil erfolgreicher HTTP-Anfragen, die durchschnittliche Anfragedauer und die Gesundheit der Pods. Basierend auf der KPI-Analyse (Key Performance Indicators) wächst oder schrumpft der Canary-Anteil, und die Analyseergebnisse werden in Slack veröffentlicht. Eine Beschreibung und Demonstration dieses Prozesses finden Sie im Material. .
Dark (versteckte) oder A/B-Deployments
Verstecktes Deployment ist eine weitere Variation der Kanarienstrategie (übrigens kann Flagger auch damit arbeiten). Der Unterschied zwischen verstecktem und Kanarien-Deployment besteht darin, dass versteckte Deployments sich mit dem Frontend befassen, während Kanarien-Deployments sich auf das Backend konzentrieren.
Ein anderer Begriff für diese Deployments ist A/B-Testing. Anstatt einer neuen Funktion allen Nutzern Zugang zu gewähren, wird sie nur einer begrenzten Anzahl von ihnen angeboten. Normalerweise wissen diese Nutzer nicht, dass sie als Testpersonen auftreten (daher der Begriff "verstecktes Deployment").
Mit Hilfe von Funktionstüchern (feature toggles) und anderen Werkzeugen kann verfolgt werden, wie Nutzer mit der neuen Funktion interagieren, ob sie sie ansprechend finden oder ob sie die neue Benutzeroberfläche verwirrend empfinden, sowie andere Arten von Metriken.
Flagger und A/B-Deployments
Neben der gewichteten Weiterleitung kann Flagger auch den Traffic zu einem Canary-Server basierend auf HTTP-Parametern leiten. Bei A/B-Tests können 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. (Sitzungsbindung). Weitere Informationen finden Sie in der Flagger-Dokumentation.
Der Autor dankt , Ingenieur bei Weaveworks (und Schöpfer von Flagger), für all diese großartigen Deployment-Schemata.
P.S. vom Übersetzer
Lesen Sie auch in unserem Blog:
- «»;
- «»;
- «»;
- «».
Quelle: habr.com
