🥇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 durchzuführen.

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, in dem wir kurz erklärt haben, was Canary Deployments sind. Wir haben auch gezeigt, wie man es mit den Standardressourcen von Kubernetes umsetzt.

Argo Rollouts

Argo Rollouts ist ein k8s-nativer Deployment-Controller. Er bietet CRDs (Custom Resource Definitions) für Kubernetes an. Mit ihm können wir eine neue Entität nutzen: Rollout, die blue-green und canary Deployments mit verschiedenen Konfigurationsoptionen verwaltet.

Der von der benutzerdefinierten Ressource verwendete Controller Argo Rollouts 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, jedoch mit zusätzlichen Deployment-Strategien.
Ressource Deployments verfügt über zwei Strategien für die Bereitstellung: RollingUpdate und Recreate. Obwohl diese Strategien für die meisten Fälle geeignet sind, werden für die Bereitstellung auf sehr großen Servern zusätzliche Strategien verwendet, wie beispielsweise 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, anpassbarer Parameter zur Verfügung.
https://argoproj.github.io/argo-rollouts

Es gibt auch Argo CI, das eine benutzerfreundliche Weboberfläche für die Verwendung zusammen mit Rollouts bietet, die wir im nächsten Artikel näher betrachten werden.

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-Repository (siehe unten) haben wir bereits install.yaml als i/k8s/argo-rollouts/install.yaml hinzugefügt. So wird GitlabCI es im Cluster installieren.

Auf der Clientseite (kubectl-Plugin)

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

Beispielanwendung

Eine gute Praxis besteht darin, 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 ein Paket mit GitlabCI erstellen und das Ergebnis im Gitlab-Registry pushen. Im Registry haben wir zwei verschiedene Versionsveröffentlichungen:

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

Der einzige Unterschied zwischen ihnen ist die zurückgegebene JSON-Datei. Wir nutzen diese Anwendung zur maximal einfachen Visualisierung, mit welcher Version wir kommunizieren.

Infrastruktur-Repository

In diesem Repository werden wir GitlabCI für das Deployment in Kubernetes verwenden. Die .gitlab-ci.yml sieht folgendermaßen 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 es selbst zu starten, benötigen Sie ein Cluster, Sie können Gcloud verwenden:

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 erstellen KUBECONFIG in GitlabCI, die die Konfiguration für den Zugriff enthält kubectl auf Ihren Cluster.

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

Infrastruktur Yaml

Innerhalb des Infrastruktur-Repositories haben wir einen 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, indem Sie `kubectl argo rollouts promote ROLLOUT` ausführen
     - pause: {}
     - setWeight: 50
     - pause: { duration: 120 } # zwei Minuten

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

Wir definieren zwei Schritte in YAML für den Canary Deployment:

10% Traffic auf Canary (auf manuelle Genehmigung warten)
50% Traffic auf Canary (2 Minuten warten, dann auf 100% fortfahren)

Durchführung des initialen Deployments

Nach dem anfänglichen Deployment sehen unsere Ressourcen so aus:

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

Führen wir das Canary Deployment durch

Schritt 1: 10% Traffic

Um das Canary-Deployment zu starten, müssen wir lediglich 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, sodass Gitlab CI das Deployment vornimmt und wir die Änderungen sehen:

Jetzt, wenn wir den Dienst aufrufen:

Ausgezeichnet! Wir sind in der Mitte unseres Canary Deployments. Wir können den Fortschritt sehen, indem wir folgendes ausführen:

kubectl argo rollouts get rollout rollout-canary

Schritt 2: 50% des Traffics:

Jetzt gehen wir zum nächsten Schritt über: Umleitung von 50% des Traffics. Wir haben dies so konfiguriert, dass dieser Schritt manuell gestartet wird:

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

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

Und die Übersicht des Rollouts:

Perfekt.

Schritt 3: 100% des Traffics:

Wir haben dies so eingestellt, dass nach 2 Minuten der Schritt mit 50% automatisch abgeschlossen wird 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 sind weitere Beispiele, wie man Vorschau-Umgebungen und Vergleiche basierend auf Canary einrichtet:

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

Video über Argo Rollouts und Argo CI

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

Zusammenfassung

Ich mag die Idee, CRDs zu verwenden, die für die Erstellung zusätzlicher Deployment-Typen oder Replicasets verantwortlich sind, den Traffic umleiten usw. Die Zusammenarbeit mit ihnen funktioniert reibungslos. Darüber hinaus möchte ich die Integration mit Argo CI testen.

Es sieht jedoch so aus, als stünde eine große Fusion von Argo CI und Flux CI bevor, daher könnte ich warten, bis die neue Version herauskommt: Argo Flux.

Hatten Sie bereits Erfahrungen mit Argo Rollouts oder Argo CI?

Lesen Sie auch andere Artikel in unserem Blog:

Quelle: habr.com