🥇Canary Deployment in Kubernetes #2: Argo Rollouts

Wir werden den k8s-nativen Deployment-Controller Argo Rollouts und GitlabCI verwenden, um ein Canary-Deployment in Kubernetes zu starten.

https://unsplash.com/photos/V41PulGL1z0

Artikel dieser Reihe

Canary Deployment in Kubernetes #1: Gitlab CI
(Dieser Artikel)
Canary Deployment mit Istio
Canary Deployment mit Jenkins-X Istio Flagger

Canary Deployment

Wir hoffen, dass Sie gelesen haben den ersten Teil, wo wir kurz erklärt haben, was Canary-Deployments sind. Wir haben auch gezeigt, wie man sie mit Standardressourcen von Kubernetes umsetzt.

Argo Rollouts

Argo Rollouts ist ein Kubernetes-native Deployment-Controller. Er bietet CRD (Custom Resource Definition) für Kubernetes. Damit können wir eine neue Entität verwenden: Rollout, die blue-green und canary Deployments mit verschiedenen Konfigurationsoptionen verwaltet.

Der Argo Rollouts-Controller, der mit der benutzerdefinierten Ressource Rollout, ermöglicht die Verwendung zusätzlicher Deployment-Strategien wie blue-green und canary für Kubernetes. Die Ressource Rollout bietet eine Funktionalität, die gleichwertig ist Deployment, nur mit zusätzlichen Deployment-Strategien.
Ressource Deployments hat zwei Strategien für das Deployment: RollingUpdate und Recreate. Obwohl diese Strategien für die meisten Fälle geeignet sind, verwenden große Skalen-Deployments zusätzliche Strategien wie blue-green oder canary, die im Deployment-Controller nicht vorhanden sind. Um diese Strategien in Kubernetes zu nutzen, mussten die Benutzer Skripte über ihre Deployments schreiben. Der Argo Rollouts-Controller stellt diese Strategien in Form einfacher deklarativer konfigurierbarer Parameter zur Verfügung.
https://argoproj.github.io/argo-rollouts

Es gibt auch Argo CI, das eine benutzerfreundliche Weboberfläche für die Verwendung mit Rollouts bereitstellt; wir werden uns dies im nächsten Artikel ansehen.

Installation von Argo Rollouts

Auf der Serverseite

kubectl create namespace argo-rollouts kubectl apply -n argo-rollouts -f https://raw.githubusercontent.com/argoproj/argo-rollouts/stable/manifests/install.yaml

In unserem Infrastruktur-Repo (siehe unten) haben wir die install.yaml bereits als i/k8s/argo-rollouts/install.yaml hinzugefügt. So wird GitlabCI es im Cluster installieren.

Auf der Client-Seite (kubectl-plugin)

https://argoproj.github.io/argo-rollouts/features/kubectl-plugin

Anwendungsbeispiel

Es ist eine gute Praxis, separate Repositories für den Anwendungscode und die Infrastruktur zu haben.

Repository für die Anwendung

Kim Wuestkamp / k8s-deployment-example-app

Dies ist eine sehr einfache API in Python+Flask, die eine Antwort im JSON-Format zurückgibt. Wir werden das Paket mit GitlabCI erstellen und das Ergebnis in das Gitlab-Registry pushen. Im Registry haben wir zwei verschiedene Versionen der Releases:

wuestkamp/k8s-deployment-example-app:v1
wuestkamp/k8s-deployment-example-app:v2

Der einzige Unterschied zwischen ihnen ist die zurückgegebene JSON-Datei. Wir verwenden diese Anwendung für eine möglichst einfache Visualisierung, mit welcher Version wir kommunizieren.

Infrastruktur-Repository

In diesem Repository nutzen wir GitlabCI für das Deployment in Kubernetes, .gitlab-ci.yml sieht wie folgt aus:

image: traherom/kustomize-dockerbefore_script:
   - printenv
   - kubectl versionstages:
 - deploydeploy test:
   stage: deploy
   before_script:
     - echo $KUBECONFIG
   script:
     - kubectl get all
     - kubectl apply -f i/k8s    only:
     - master

Um ihn selbst auszuführen, benötigen Sie einen Cluster, Gcloud kann verwendet werden:

gcloud container clusters create canary --num-nodes 3 --zone europe-west3-b
gcloud compute firewall-rules create incoming-80 --allow tcp:80

Sie müssen einen Fork erstellen https://gitlab.com/wuestkamp/k8s-deployment-example-canary-infrastructure und eine Variable KUBECONFIG in GitlabCI anlegen, die die Konfiguration für den Zugriff enthält kubectl auf Ihren Cluster.

Hier Sie können lesen, wie Sie Zugangsdaten für den Cluster erhalten (Gcloud).

Infrastruktur-YAML

Innerhalb des Infrastruktur-Repositorys haben wir den Service:

apiVersion: v1
kind: Service
metadata:
 labels:
   id: rollout-canary
 name: app
spec:
 ports:
 - port: 80
   protocol: TCP
   targetPort: 5000
 selector:
   id: app
 type: LoadBalancer

und rollout.yaml:

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
 name: rollout-canary
spec:
 replicas: 10
 revisionHistoryLimit: 2
 selector:
   matchLabels:
     id: rollout-canary
 template:
   metadata:
     labels:
       id: rollout-canary
   spec:
     containers:
     - name: rollouts-demo
       image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v1
       imagePullPolicy: Always
 strategy:
   canary:
     steps:
     - setWeight: 10
     # Rollouts können manuell fortgesetzt werden durch Ausführen von `kubectl argo rollouts promote ROLLOUT`
     - pause: {}
     - setWeight: 50
     - pause: { duration: 120 } # zwei Minuten

Rollout funktioniert genauso wie ein Deployment. Wenn wir keine Aktualisierungsstrategie festlegen (wie canary hier), verhält er sich wie das standardmäßige Rolling-Update-Deployment.

Wir definieren zwei Schritte im YAML für das Canary-Deployment:

10 % des Traffics auf Canary (auf manuelles OK warten)
50 % des Traffics auf Canary (2 Minuten warten und dann auf 100 % fortfahren)

Durchführung des initialen Deployments

Nach dem initialen Deployment sehen unsere Ressourcen so aus:

Und wir erhalten eine Antwort nur von der ersten Version der Anwendung:

Durchführung des Canary-Deployments

Schritt 1: 10 % Traffic

Um das Canary-Deployment zu starten, müssen wir einfach die Version des Images ändern, wie wir es normalerweise bei Deployments tun:

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
 name: rollout-canary
spec:
...
 template:
   metadata:
     labels:
       id: rollout-canary
   spec:
     containers:
     - name: rollouts-demo
       image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v2
...

Und wir pushen die Änderungen, daher macht Gitlab CI das Deployment und wir sehen die Änderungen:

Jetzt, wenn wir auf den Service zugreifen:

Ausgezeichnet! Wir sind mitten in unserem Canary-Deployment. Wir können den Fortschritt mit dem Befehl sehen:

kubectl argo rollouts get rollout rollout-canary

Schritt 2: 50% Verkehr:

Jetzt gehen wir zum nächsten Schritt über: 50% des Verkehrs umleiten. Wir haben eingestellt, dass dieser Schritt manuell gestartet wird:

kubectl argo rollouts promote rollout-canary # weiter zu Schritt 2

Und unsere Anwendung hat 50% der Antworten von neuen Versionen zurückgegeben:

Und die Übersicht des Rollouts:

Ausgezeichnet.

Schritt 3: 100% Verkehr:

Wir haben eingestellt, dass nach 2 Minuten der Schritt mit 50% automatisch beendet und der Schritt mit 100% gestartet wird:

Und die Ausgabe der Anwendung:

Und die Übersicht des Rollouts:

Canary-Deployment abgeschlossen.

Weitere Beispiele mit Argo Rollouts

Hier gibt es noch weitere Beispiele, zum Beispiel, wie man eine Vorschau der Umgebung und Vergleiche auf der Basis von Canary einrichtet:

https://github.com/argoproj/argo-rollouts/tree/master/examples

Video über Argo Rollouts und Argo CI

Ich empfehle wirklich dieses Video, da es zeigt, wie Argo Rollouts und Argo CI zusammenarbeiten:

Fazit

Mir gefällt die Idee, CRDs zu verwenden, die die Erstellung zusätzlicher Arten von Deployments oder ReplicaSets verwalten, den Verkehr umleiten etc. Die Arbeit mit ihnen verläuft reibungslos. Als nächstes würde ich gerne die Integration mit Argo CI testen.

Allerdings deutet alles darauf hin, dass eine große Fusion von Argo CI und Flux CI bevorsteht, daher könnte ich warten, bis die neue Version herauskommt: Argo Flux.

Hatten Sie Erfahrungen mit Argo Rollouts oder Argo CI?

Lesen Sie auch andere Artikel in unserem Blog:

Quelle: habr.com