Hinweis perev .: Dieses Überprüfungsmaterial von Weaveworks stellt die beliebtesten Anwendungs-Rollout-Strategien vor und spricht über die Möglichkeit, die fortschrittlichsten davon mithilfe des Kubernetes-Operators Flagger zu implementieren. Es ist in einfacher Sprache verfasst und enthält visuelle Diagramme, die es auch unerfahrenen Ingenieuren ermöglichen, das Problem zu verstehen.
Das Diagramm stammt aus einer weiteren Überprüfung der bei Container Solutions durchgeführten Roll-out-Strategien.Eines der größten Probleme bei der Entwicklung nativer Cloud-Anwendungen ist heute die Bereitstellung. Mit dem Microservice-Ansatz arbeiten Entwickler bereits mit vollständig modularen Anwendungen und entwerfen sie, sodass verschiedene Teams gleichzeitig Code schreiben und Änderungen an der Anwendung vornehmen können.
Kürzere und häufigere Bereitstellungen bieten die folgenden Vorteile:
- Die Markteinführungszeit wird verkürzt.
- Neue Funktionen erreichen Benutzer schneller.
- Benutzerfeedback erreicht das Entwicklungsteam schneller. Dies bedeutet, dass das Team Funktionen ergänzen und Probleme schneller beheben kann.
- Die Moral der Entwickler steigt: Es ist interessanter, mit einer Vielzahl von Funktionen in der Entwicklung zu arbeiten.
Mit zunehmenden Freigabefrequenzen steigt jedoch auch die Wahrscheinlichkeit, dass die Zuverlässigkeit der Anwendung oder die Benutzererfahrung beeinträchtigt werden. Aus diesem Grund ist es für Betriebsteams und DevOps wichtig, Prozesse zu erstellen und Bereitstellungsstrategien so zu verwalten, dass das Risiko für das Produkt und die Benutzer minimiert wird. (Weitere Informationen zur Automatisierung der CI / CD-Pipeline finden Sie
hier .)
In diesem Beitrag werden wir verschiedene Bereitstellungsstrategien bei Kubernetes diskutieren, einschließlich fortlaufender Bereitstellungen und fortschrittlicherer Methoden wie kanarischer Rollouts und ihrer Variationen.
Bereitstellungsstrategien
Es gibt verschiedene Arten von Bereitstellungsstrategien, die Sie je nach Ziel verwenden können. Beispielsweise müssen Sie möglicherweise Änderungen an einer bestimmten Umgebung für weitere Tests oder an einer Teilmenge von Benutzern / Clients vornehmen, oder Sie müssen möglicherweise eingeschränkte Tests für Benutzer durchführen, bevor Sie eine Funktion
öffentlich verfügbar machen .
Rollen (schrittweise, "rollende" Bereitstellung)
Dies ist eine Standardbereitstellungsstrategie in Kubernetes. Nach und nach werden Pods nacheinander durch die alte Version der Anwendung durch Pods durch die neue Version ersetzt - ohne Cluster-Ausfallzeiten.
Kubernetes wartet, bis die neuen Pods für die Arbeit bereit sind (überprüfen Sie sie mit
Bereitschaftstests ), bevor Sie mit dem Zusammenbruch der alten beginnen. Wenn ein Problem auftritt, kann ein solches fortlaufendes Update unterbrochen werden, ohne den gesamten Cluster anzuhalten. In der YAML-Datei vom Bereitstellungstyp 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: 8080
Die Parameter für ein fortlaufendes Update können in der Manifestdatei angegeben werden:
spec: replicas: 3 strategy: type: RollingUpdate rollingUpdate: maxSurge: 25% maxUnavailable: 25% template: ...
Neu erstellen (Neuerstellung)
Bei dieser einfachsten Art der Bereitstellung werden alte Pods auf einmal getötet und durch neue ersetzt:
Das entsprechende Manifest sieht ungefähr so aus:
spec: replicas: 3 strategy: type: Recreate template: ...
Blau / Grün (blaugrüner Einsatz)
Die blau-grüne Bereitstellungsstrategie (manchmal auch als rot / schwarz, d. H. Rot-schwarz bezeichnet) umfasst die gleichzeitige Bereitstellung der alten (grün) und neuen (blau) Version der Anwendung. Nach dem Platzieren beider Versionen erhalten normale Benutzer Zugriff auf die grüne Version, während die blaue Version für das QA-Team verfügbar ist, um Tests über einen separaten Dienst oder eine direkte Portweiterleitung zu automatisieren:
apiVersion: apps/v1beta1 kind: Deployment metadata: name: awesomeapp-02 spec: template: metadata: labels: app: awesomeapp version: "02"
Nachdem die blaue (neue) Version getestet und ihre Freigabe genehmigt wurde, wechselt der Dienst zu ihr und die grüne (alte) wird minimiert:
apiVersion: v1 kind: Service metadata: name: awesomeapp spec: selector: app: awesomeapp version: "02" ...
Kanarienvogel (Kanarienvogeleinsatz)
Kanarische Brötchen sehen blaugrün aus, werden aber besser verwaltet und
gehen schrittweise vor. Dieser Typ umfasst verschiedene Strategien, einschließlich „versteckter“ Starts und A / B-Tests.
Diese Strategie wird verwendet, wenn im Anwendungs-Backend in der Regel neue Funktionen erforderlich sind. Das Wesentliche des Ansatzes besteht darin, zwei nahezu identische Server zu erstellen: Einer dient fast allen Benutzern und der andere mit neuen Funktionen dient nur einer kleinen Teilmenge von Benutzern, wonach ihre Ergebnisse verglichen werden. Wenn alles reibungslos verläuft, wird die neue Version schrittweise auf die gesamte Infrastruktur ausgeweitet.
Obwohl diese Strategie nur mit Kubernetes-Tools implementiert werden kann, bei denen alte Pods durch neue ersetzt werden, ist es viel bequemer und einfacher, ein Service-Mesh wie Istio zu verwenden.
Zum Beispiel können Sie in Git zwei verschiedene Manifeste haben: das reguläre mit dem 0.1.0-Tag und das "kanarische" mit dem 0.2.0-Tag. Durch Ändern der Gewichte im Manifest des virtuellen Istio-Gateways können Sie die Verteilung des Datenverkehrs zwischen diesen beiden Bereitstellungen steuern:
Eine exemplarische Vorgehensweise zum Implementieren kanarischer Bereitstellungen mit Istio finden Sie unter
GitOps-Workflows mit Istio .
( Anmerkung Übersetzung : Wir haben hier auch Material über Kanarienbrötchen in Istio übersetzt.)Kanarische Einsätze mit Weaveworks Flagger
Mit Weaveworks Flagger ist es einfach und effizient, kanarische Rollouts zu verwalten.
Flagger automatisiert die Arbeit mit ihnen. Es verwendet das Istio oder AWS App Mesh zum Weiterleiten und Wechseln des Datenverkehrs sowie die Prometheus-Metriken zum Analysieren der Ergebnisse. Darüber hinaus kann die Analyse kanarischer Bereitstellungen durch Webhooks zur Durchführung von Abnahmetests, Belastungstests und anderen Arten von Überprüfungen ergänzt werden.
Basierend auf der Kubernetes-Bereitstellung und gegebenenfalls der horizontalen Pod-Skalierung (HPA) erstellt Flagger Objektgruppen (Kubernetes-Bereitstellungen, ClusterIP-Dienste und virtuelle Istio- oder App Mesh-Dienste) zur Analyse und Implementierung kanarischer Bereitstellungen:
Durch die Implementierung eines
Regelkreises schaltet Flagger den Datenverkehr schrittweise auf den kanarischen Server um und misst gleichzeitig wichtige Leistungsindikatoren wie den Prozentsatz erfolgreicher HTTP-Anforderungen, die durchschnittliche Anforderungsdauer und den Pod-Zustand. Basierend auf der Analyse des KPI (Key Performance Indicators) wächst oder kollabiert der kanarische Anteil, und die Ergebnisse der Analyse werden in Slack veröffentlicht. Eine Beschreibung und Demonstration dieses Prozesses finden Sie in der
progressiven Bereitstellung für App Mesh .
Dunkle (versteckte) oder A / B-Bereitstellung
Die verdeckte Bereitstellung ist eine weitere Variante der kanarischen Strategie (Flagger kann übrigens auch damit arbeiten). Der Unterschied zwischen verdeckten und kanarischen Bereitstellungen besteht darin, dass verdeckte Bereitstellungen das Frontend und nicht das Backend wie kanarische betreffen.
Ein anderer Name für diese Bereitstellungen ist A / B-Test. Anstatt allen Benutzern den Zugriff auf die neue Funktion zu ermöglichen, wird sie nur einem begrenzten Teil von ihnen angeboten. In der Regel wissen diese Benutzer nicht, dass sie Pioniertester sind (daher der Begriff „verdeckte Bereitstellung“).
Mithilfe von Funktionsumschaltern und anderen Tools können Sie überwachen, wie Benutzer mit der neuen Funktion interagieren, ob sie sie fesselt oder ob sie die neue Benutzeroberfläche verwirrend finden und andere Arten von Metriken.
Flagger- und A / B-Bereitstellungen
Zusätzlich zum gewichteten Routing kann Flagger abhängig von den HTTP-Einstellungen auch Datenverkehr zum kanarischen Server leiten. Für A / B-Tests können Sie HTTP-Header oder Cookies verwenden, um ein bestimmtes Benutzersegment umzuleiten. Dies ist besonders effektiv für Frontend-Anwendungen, die eine
Sitzungsaffinität für den Server erfordern. Weitere Informationen finden Sie in der Flagger-Dokumentation.
Der Autor dankt Stefan Prodan , Weaveworks-Ingenieur (und Schöpfer von Flagger), für all diese großartigen Bereitstellungen.PS vom Übersetzer
Lesen Sie auch in unserem Blog: