Hinw. Ü.: Dieses Überblicksmaterial von Weaveworks stellt die beliebtesten Strategien für die Bereitstellung von Anwendungen vor und erläutert, wie die fortschrittlichsten von ihnen mit dem Kubernetes-Operator Flagger umgesetzt werden können. Es ist in einfacher Sprache verfasst und enthält anschauliche Diagramme, die selbst Anfängern helfen, die Thematik zu verstehen.
Das Diagramm stammt aus zu Bereitstellungsstrategien, die von Container Solutions erstellt wurde.
Eines der größten Probleme bei der Entwicklung von Cloud-Native-Anwendungen heute ist die Beschleunigung des Deployments. Bei einem Microservices-Ansatz 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 Bereitstellungen bieten folgende Vorteile:
- Die Markteinführungszeit wird verkürzt.
- Neue Funktionen erreichen die Nutzer schneller.
- Nutzerfeedback gelangt schneller zum Entwicklerteam. Das bedeutet, dass das Team Funktionen ergänzen und Probleme schneller beheben kann.
- Die Moral der Entwickler steigt: Mit einer größeren Anzahl von Funktionen macht die Arbeit mehr Spaß.
Doch mit einer erhöhten Release-Häufigkeit steigen auch die Chancen, negative Auswirkungen auf die Zuverlässigkeit der Anwendung oder das Nutzererlebnis zu haben. Aus diesem Grund ist es für Betriebs- und DevOps-Teams wichtig, Prozesse zu gestalten und Bereitstellungsstrategien so zu managen, dass Risiken für das Produkt und die Nutzer minimiert werden. (Mehr über die Automatisierung von CI/CD-Pipelines erfahren Sie .)
In dieser Veröffentlichung werden wir verschiedene Bereitstellungsstrategien in Kubernetes diskutieren, einschließlich Rolling-Bereitstellungen und fortgeschrittenere Methoden wie Canary-Deployments und deren Varianten.
Bereitstellungsstrategien
Es gibt mehrere verschiedene Arten von Bereitstellungsstrategien, die je nach Ziel genutzt werden können. Zum Beispiel könnte es notwendig sein, Änderungen an einer bestimmten Umgebung für weitere Tests vorzunehmen, oder an einer Teilmenge von Nutzern/Kunden, oder es könnte erforderlich sein, beschränkte Tests an Nutzern durchzuführen, bevor eine Funktion öffentlich zugänglich gemacht wird..
Rolling (schrittweises, 'aufschichtendes' Deployment)
Dies ist eine Standard-Bereitstellungsstrategie in Kubernetes. Sie ersetzt nach und nach, eins nach dem anderen, die Pods mit der alten Version der Anwendung durch Pods mit der neuen Version — ohne Ausfall des Clusters.
Kubernetes wartet darauf, dass die neuen Pods betriebsbereit sind (prüft sie mit Hilfe von ), bevor es mit dem Abbau der alten Pods beginnt. Bei Problemen kann dieses Rolling-Update unterbrochen werden, ohne das gesamte Cluster anzuhalten. In der YAML-Datei, die den Deployment-Typ 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 des Rolling-Updates können in der Manifestdatei spezifiziert werden:
spec:
replicas: 3
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
template:
...
Recreate (Neuerstellung)
Bei diesem einfachsten Bereitstellungstyp werden die alten Pods alle auf einmal beendet und durch neue ersetzt:
Das entsprechende Manifest sieht ungefähr so aus:
spec:
replicas: 3
strategy:
type: Recreate
template:
...Blue/Green (Blau-Grüne Bereitstellungen)
Die Blue-Green-Bereitstellungsstrategie (manchmal auch als Red/Black bezeichnet) sieht die gleichzeitige Bereitstellung der alten (grünen) und der neuen (blauen) Version der Anwendung vor. Nach der Bereitstellung beider Versionen haben normale Benutzer Zugriff auf die grüne Version, während die blaue für das QA-Team zum Testen über einen separaten Dienst oder einen direkten Portdurchlauf 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 Dienst auf diese umgeschaltet und die grüne (alte) wird abgebaut:
apiVersion: v1
kind: Service
metadata:
name: awesomeapp
spec:
selector:
app: awesomeapp
version: "02"
...Canary (Kanaren-Bereitstellungen)
Canary-Rollouts sind ähnlich wie Blue-Green, aber besser steuerbar und verwenden stufenweisen Ansatz. Zu diesem Typ gehören mehrere verschiedene Strategien, einschließlich „Hidden“ Versionen und A/B-Testing.
Diese Strategie wird angewendet, wenn es notwendig ist, eine neue Funktionalität auszuprobieren, typischerweise im Backend der Anwendung. Der Ansatz besteht darin, zwei nahezu identische Server zu erstellen: Einer bedient fast alle Benutzer, während der andere mit neuen Funktionen nur eine kleine Untergruppe von Benutzern bedient, und die Ergebnisse ihrer Leistung anschließend verglichen werden. Wenn alles fehlerfrei verläuft, wird die neue Version schrittweise auf die gesamte Infrastruktur ausgerollt.
Obwohl diese Strategie ausschließlich mit den 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.
Zum Beispiel könnten Sie zwei verschiedene Manifeste in Git haben: das reguläre mit dem Tag 0.1.0 und das 'kanarienvogel'-Manifest mit dem Tag 0.2.0. Durch Anpassen der Gewichte im Manifest des virtuellen Gateways von Istio kann der Datenverkehr zwischen diesen beiden Deployments gesteuert werden:
Eine schrittweise Anleitung zur Implementierung von Kanarienvogel-Deployments mit Istio finden Sie in dem Artikel . (Anmerkung des Übersetzers.: Wir haben auch Materialien zu Kanarienvogel-Rollouts in Istio übersetzt .)
Kanarienvogel-Deployments mit Weaveworks Flagger
ermöglicht eine einfache und effektive Verwaltung von Kanarienvogel-Rollouts.
Flagger automatisiert deren Umgang. Er nutzt Istio oder AWS App Mesh für die Routen- und Traffic-Umsteuerung sowie Prometheus-Metriken zur Analyse der Ergebnisse. Darüber hinaus kann die Analyse der Kanarienvogel-Deployments durch Webhooks ergänzt werden, um Abnahmeprüfungen, Lasttests und andere Arten von Überprüfungen durchzuführen.
Basierend auf dem Kubernetes-Deployment und, falls erforderlich, der horizontalen Skalierung von Pods (HPA) erstellt Flagger Sätze von Objekten (Kubernetes-Deployments, ClusterIP-Dienste und virtuelle Istio- oder App Mesh-Services) für die Analyse und Implementierung von Kanarienvogel-Deployments:
Indem er den Kontrollkreis (control loop)realisierte, wechselt Flagger schrittweise den Verkehr zum Kanarienvogel-Server, während er gleichzeitig Schlüsselkennzahlen wie die Erfolgsquote von HTTP-Anfragen, die durchschnittliche Anfragedauer und die Gesundheit der Pods misst. Basierend auf der Analyse der KPI (Key Performance Indicators) wächst oder schrumpft der kanarienvogelähnliche Teil, und die Ergebnisse der Analyse werden in Slack veröffentlicht. Eine Beschreibung und Demonstration dieses Prozesses finden Sie in dem Artikel .
Dunkel (versteckt) oder A/B-Deployment
Verstecktes Deployment ist eine weitere Variante der Kanarienstrategien (übrigens 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.
Ein anderer Name für diese Deployments ist A/B-Testing. Anstatt den Zugriff auf eine neue Funktion für alle Benutzer zu öffnen, wird sie nur einer begrenzten Gruppe angeboten. In der Regel wissen diese Benutzer nicht, dass sie als Testpersonen agieren (daher der Begriff „verstecktes Deployment“).
Mit Hilfe von Funktionstastenschaltern (feature toggles) und anderen Tools kann verfolgt werden, wie Benutzer mit der neuen Funktion interagieren, ob sie ansprechend ist oder ob die neue Benutzeroberfläche verwirrend erscheint, sowie andere Arten von Metriken.
Flagger und A/B-Deployments
Neben der Gewichtung der Routing-Parameter kann Flagger auch den Traffic auf einen kanarienartigen Server basierend auf HTTP-Parametern lenken. Beim A/B-Testing können 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 (session affinity). Weitere Informationen finden Sie in der Dokumentation von Flagger.
Der Autor bedankt sich bei , Ingenieur bei Weaveworks (und Schöpfer von Flagger), für all diese erstaunlichen Deployment-Schemata.
P.S. vom Übersetzer
Lesen Sie auch in unserem Blog:
- «»;
- «»;
- «»;
- «».
Quelle: habr.com
