Notiz. Übersetzung: In dieser exemplarischen Vorgehensweise von Weaveworks werden die gängigsten Anwendungs-Rollout-Strategien vorgestellt und erläutert, wie Sie die fortschrittlichsten davon mit dem Flagger Kubernetes-Operator implementieren können. Es ist in einfacher Sprache verfasst und enthält visuelle Diagramme, die es auch unerfahrenen Ingenieuren ermöglichen, das Problem zu verstehen.
Diagramm entnommen aus Rollout-Strategien aus Container Solutions
Eine der größten Herausforderungen bei der Entwicklung cloudnativer Anwendungen ist heute die Bereitstellungsgeschwindigkeit. Mit einem Microservice-Ansatz arbeiten Entwickler bereits mit vollständig modularen Anwendungen und entwerfen diese, sodass verschiedene Teams gleichzeitig Code schreiben und Änderungen an der Anwendung vornehmen können.
Kürzere und häufigere Bereitstellungen haben folgende Vorteile:
- Reduzierte Zeit bis zur Markteinführung.
- Neue Funktionen gelangen schneller zu den Benutzern.
- Benutzerfeedback erreicht das Entwicklungsteam schneller. Das bedeutet, dass das Team Funktionen hinzufügen und Probleme schneller beheben kann.
- Die Moral der Entwickler steigt: Es macht mehr Spaß, mit mehr Funktionen in der Entwicklung zu arbeiten.
Mit zunehmender Häufigkeit der Veröffentlichungen steigt jedoch auch die Wahrscheinlichkeit, dass die Zuverlässigkeit oder das Benutzererlebnis der App negativ beeinflusst wird. Aus diesem Grund ist es für Betriebs- und DevOps-Teams wichtig, Prozesse so aufzubauen und Bereitstellungsstrategien zu verwalten, dass das Risiko für das Produkt und die Benutzer minimiert wird. (Weitere Informationen zur Automatisierung der CI/CD-Pipeline finden Sie unter .)
In diesem Beitrag besprechen wir verschiedene Kubernetes-Bereitstellungsstrategien, einschließlich rollierender Bereitstellungen und fortgeschrittenerer Methoden wie Canary-Rollouts und deren Variationen.
Bereitstellungsstrategien
Es gibt verschiedene Arten von Bereitstellungsstrategien, die je nach Zweck verwendet werden können. Beispielsweise müssen Sie möglicherweise Änderungen an einer Umgebung für weitere Tests oder an einer Teilmenge von Benutzern/Clients vornehmen, oder Sie müssen möglicherweise begrenzte Tests an Benutzern durchführen, bevor Sie eine Funktion erstellen öffentlich zugänglich.
Rolling (schrittweiser, rollierender Einsatz)
Dies ist die Standardbereitstellungsstrategie für Kubernetes. Es ersetzt nach und nach die Pods mit der alten Version der Anwendung nach und nach durch Pods mit der neuen Version – ohne Ausfallzeit des Clusters.
Kubernetes wartet darauf, dass neue Pods einsatzbereit sind (überprüft sie mit ), bevor Sie mit dem Aufrollen der alten fortfahren. Tritt ein Problem auf, kann ein solches Rolling Update abgebrochen werden, ohne dass der gesamte Cluster gestoppt wird. In der YAML-Datei des Bereitstellungstyps 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 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 gelöscht und durch neue ersetzt:
Das entsprechende Manifest sieht etwa so aus:
spec:
replicas: 3
strategy:
type: Recreate
template:
...Blau/Grün (blau-grüne Bereitstellungen)
Die Blau-Grün-Bereitstellungsstrategie (manchmal auch als Rot/Schwarz, also Rot-Schwarz bezeichnet) beinhaltet die gleichzeitige Bereitstellung der alten (grünen) und neuen (blauen) Version der Anwendung. Sobald beide Versionen gehostet sind, steht die grüne Version dem allgemeinen Benutzer zur Verfügung, während die blaue Version dem QA-Team zur Verfügung steht, um Tests über einen separaten Dienst oder 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 zur Veröffentlichung freigegeben wurde, wird der Dienst auf diese umgestellt und die grüne (alte) minimiert:
apiVersion: v1
kind: Service
metadata:
name: awesomeapp
spec:
selector:
app: awesomeapp
version: "02"
...Canary (kanarische Bereitstellungen)
Canary-Rollouts ähneln Blue-Green, werden jedoch besser kontrolliert und genutzt Schritt-für-Schritt-Ansatz. In diese Kategorie fallen verschiedene Strategien, darunter verdeckte Markteinführungen und A/B-Tests.
Diese Strategie wird verwendet, wenn einige neue Funktionen getestet werden müssen, normalerweise im Backend der Anwendung. Der Kern des Ansatzes besteht darin, zwei nahezu identische Server zu erstellen: Einer bedient fast alle Benutzer und der andere bedient mit neuen Funktionen nur eine kleine Untergruppe von Benutzern, woraufhin die Ergebnisse ihrer Arbeit verglichen werden. Läuft alles fehlerfrei, wird die neue Version nach und nach auf die gesamte Infrastruktur ausgerollt.
Obwohl diese Strategie ausschließlich mit Kubernetes umgesetzt werden kann und alte Pods durch neue ersetzt werden, ist es viel bequemer und einfacher, ein Service-Mesh wie Istio zu verwenden.
Beispielsweise könnten Sie zwei verschiedene Git-Manifeste haben: ein reguläres mit einem 0.1.0-Tag und ein Canary-Manifest mit einem 0.2.0-Tag. Durch Ändern der Gewichtungen im Istio Virtual Gateway-Manifest können Sie die Verteilung des Datenverkehrs zwischen diesen beiden Bereitstellungen steuern:
Eine Schritt-für-Schritt-Anleitung zur Implementierung von Canary-Bereitstellungen mit Istio finden Sie in . (Notiz. übersetzen: Wir haben auch Material über Kanarienbrötchen in Istio übersetzt .)
Canary-Bereitstellungen mit Weaveworks Flagger
ermöglicht eine einfache und effiziente Kontrolle von Kanarienrollen.
Flagger automatisiert die Arbeit damit. Es verwendet Istio oder AWS App Mesh, um den Datenverkehr weiterzuleiten und zu schalten, und Prometheus-Metriken, um die Ergebnisse zu analysieren. Darüber hinaus kann die Analyse von Canary-Deployments durch Webhooks zur Durchführung von Akzeptanztests, Lasttests und anderen Arten von Prüfungen ergänzt werden.
Basierend auf der Bereitstellung von Kubernetes und ggf. Scale-out-Pods (HPA) erstellt Flagger Objektsätze (Kubernetes-Bereitstellungen, ClusterIP-Dienste und virtuelle Istio- oder App Mesh-Dienste), um Canary-Bereitstellungen zu analysieren und zu implementieren:
Implementierung eines Regelkreises (Regelkreis)Flagger leitet den Datenverkehr nach und nach auf den Canary-Server um und misst dabei wichtige Leistungsmetriken wie die Erfolgsrate von HTTP-Anfragen, die durchschnittliche Anfragedauer und den Pod-Zustand. Basierend auf der Analyse von KPIs (Key Performance Indicators) wächst oder schrumpft der kanarische Teil und die Ergebnisse der Analyse werden in Slack veröffentlicht. Eine Beschreibung und Demonstration dieses Prozesses finden Sie im Material .
Dunkle (versteckte) oder A/B-Bereitstellungen
Der Stealth-Einsatz ist eine weitere Variante der Canary-Strategie (mit der Flagger übrigens auch arbeiten kann). Der Unterschied zwischen Stealth- und Canary-Bereitstellungen besteht darin, dass sich Stealth-Bereitstellungen mit dem Front-End und nicht mit dem Backend befassen, wie dies bei Canary-Bereitstellungen der Fall ist.
Ein anderer Name für diese Bereitstellungen ist A/B-Tests. Anstatt den Zugriff auf eine neue Funktion allen Benutzern zu ermöglichen, wird sie nur einem begrenzten Teil von ihnen angeboten. Normalerweise sind sich diese Benutzer nicht darüber im Klaren, dass sie Pioniertester sind (daher der Begriff „stille Bereitstellung“).
Mit Funktionsschaltern (Funktion schaltet um) und anderen Tools können Sie überwachen, wie Benutzer mit einer neuen Funktion interagieren, ob sie davon abhängig sind oder die neue Benutzeroberfläche verwirrend finden, sowie andere Arten von Metriken.
Flagger- und A/B-Bereitstellungen
Zusätzlich zum gewichteten Routing kann Flagger den Datenverkehr auch basierend auf HTTP-Parametern an den Canary-Server weiterleiten. A/B-Tests können HTTP-Header oder Cookies verwenden, um ein bestimmtes Benutzersegment umzuleiten. Dies ist besonders effektiv bei Frontend-Anwendungen, die eine Bindung der Sitzung an den Server erfordern. (Sitzungsaffinität). Weitere Informationen finden Sie in der Flagger-Dokumentation.
Der Autor ist dankbar , Ingenieur von Weaveworks (und Schöpfer von Flagger), für all diese erstaunlichen Bereitstellungspläne.
PS vom Übersetzer
Lesen Sie auch auf unserem Blog:
- «";
- «";
- «";
- «".
Source: habr.com