Wir werden den k8s-nativen Argo Rollouts Deployment Controller und GitlabCI verwenden, um Canary-Bereitstellungen auf Kubernetes auszuführen
Artikel dieser Reihe
- (Dieser Artikel)
- Canary-Bereitstellung mit Istio
- Canary-Bereitstellung mit Jenkins-X Istio Flagger
Canary-Bereitstellung
Wir hoffen, dass Sie lesen , wo wir kurz erklärt haben, was Canary Deployments sind. Wir haben auch gezeigt, wie man es mit Standard-Kubernetes-Ressourcen implementiert.
Argo-Rollouts
Argo Rollouts ist ein nativer Kubernetes-Bereitstellungscontroller. Es stellt eine CRD (Custom Resource Definition) für Kubernetes bereit. Dank dessen können wir eine neue Entität verwenden: Rollout, das Blue-Green- und Canary-Bereitstellungen mit verschiedenen Konfigurationsoptionen verwaltet.
Argo Rollouts-Controller, der von einer benutzerdefinierten Ressource verwendet wird
Rollout,Ermöglicht zusätzliche Bereitstellungsstrategien wie Blue-Green und Canary für Kubernetes. RessourceRolloutBietet eine gleichwertige FunktionalitätDeployment, nur mit zusätzlichen Einsatzstrategien.
RessourceDeploymentsverfügt über zwei Strategien für die Bereitstellung:RollingUpdateиRecreate. Obwohl diese Strategien für die meisten Fälle geeignet sind, werden für die Bereitstellung auf Servern in sehr großem Umfang zusätzliche Strategien verwendet, z. B. Blaugrün oder Kanarisch, die im Bereitstellungscontroller nicht verfügbar sind. Um diese Strategien in Kubernetes nutzen zu können, mussten Benutzer zusätzlich zu ihren Bereitstellungen Skripte schreiben. Der Argo Rollouts Controller stellt diese Strategien als einfache, deklarative, konfigurierbare Parameter bereit.
Es gibt auch Argo CI, das eine praktische Weboberfläche für die Verwendung mit Rollouts bereitstellt, darauf gehen wir im nächsten Artikel ein.
Installieren von Argo-Rollouts
Serverseitig
kubectl create namespace argo-rolloutskubectl apply -n argo-rollouts -f https://raw.githubusercontent.com/argoproj/argo-rollouts/stable/manifests/install.yaml
In unserer Infrastruktur-Rübe (siehe unten) haben wir install.yaml bereits als i/k8s/argo-rollouts/install.yaml hinzugefügt. Auf diese Weise installiert GitlabCI es im Cluster.
Client-Seite (kubectl-Plugin)
Beispielanwendung
Es empfiehlt sich, separate Repositorys für Anwendungscode und Infrastruktur zu haben.
Repository für die Anwendung
Dies ist eine sehr einfache Python+Flask-API, die eine Antwort als JSON zurückgibt. Wir werden das Paket mit GitlabCI erstellen und das Ergebnis an die Gitlab-Registrierung übertragen. In der Registry haben wir zwei verschiedene Release-Versionen:
- wuestkamp/k8s-deployment-example-app:v1
- wuestkamp/k8s-deployment-example-app:v2
Der einzige Unterschied zwischen ihnen besteht in der zurückgegebenen JSON-Datei. Wir nutzen diese Anwendung, um möglichst einfach zu visualisieren, mit welcher Version wir kommunizieren.
Infrastruktur-Repository
In diesem Repository verwenden wir GitlabCI für die Bereitstellung auf Kubernetes. .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:
- masterUm es selbst auszuführen, benötigen Sie einen 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:80Du musst forken und eine Variable erstellen KUBECONFIG in GitlabCI, das die Konfiguration für den Zugriff enthält kubectl zu Ihrem Cluster.
Sie können lesen, wie Sie Anmeldeinformationen für einen Cluster (Gcloud) erhalten.
Infrastruktur Yaml
Im Infrastruktur-Repository haben wir folgende Dienste:
apiVersion: v1
kind: Service
metadata:
labels:
id: rollout-canary
name: app
spec:
ports:
- port: 80
protocol: TCP
targetPort: 5000
selector:
id: app
type: LoadBalancerund 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 can be manually resumed by running `kubectl argo rollouts promote ROLLOUT`
- pause: {}
- setWeight: 50
- pause: { duration: 120 } # two minutesRollout funktioniert genauso wie die Bereitstellung. Wenn wir keine Update-Strategie festlegen (wie hier Canary), verhält es sich wie die standardmäßige Rolling-Update-Bereitstellung.
Wir definieren in Yaml zwei Schritte für die Canary-Bereitstellung:
- 10 % des Traffics zu Canary (auf manuelles OK warten)
- 50 % Verkehr zu Canary (2 Minuten warten, dann weiter bis 100 %)
Durchführen der Erstbereitstellung
Nach der ersten Bereitstellung sehen unsere Ressourcen folgendermaßen aus:
Und wir erhalten eine Antwort nur von der ersten Version der Anwendung:
Canary-Bereitstellung durchführen
Schritt 1: 10 % Traffic
Um eine Canary-Bereitstellung zu starten, müssen wir lediglich die Image-Version ändern, wie wir es normalerweise bei Bereitstellungen 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 Änderungen, sodass Gitlab CI bereitgestellt wird und wir die Änderungen sehen:
Wenn wir nun auf den Dienst zugreifen:
Großartig! Wir sind mitten in unserem Canary-Einsatz. Wir können den Fortschritt sehen, indem wir Folgendes ausführen:
kubectl argo rollouts get rollout rollout-canary
Schritt 2: 50 % Traffic:
Kommen wir nun zum nächsten Schritt: der Umleitung von 50 % des Datenverkehrs. Wir haben diesen Schritt so konfiguriert, dass er manuell ausgeführt wird:
kubectl argo rollouts promote rollout-canary # continue to step 2
Und unsere Anwendung hat 50 % der Antworten von neuen Versionen zurückgegeben:
Und Rollout-Rezension:
Gut
Schritt 3: 100 % Traffic:
Wir haben es so eingerichtet, dass nach 2 Minuten der 50 %-Schritt automatisch endet und der 100 %-Schritt beginnt:
Und die Anwendungsausgabe:
Und Rollout-Rezension:
Die Canary-Bereitstellung ist abgeschlossen.
Weitere Beispiele mit Argo Rollouts
Weitere Beispiele finden Sie hier, beispielsweise zum Einrichten von Umgebungsvorschauen und -vergleichen basierend auf Canary:
Video über Argo Rollouts und Argo CI
Ich kann dieses Video wirklich empfehlen, es zeigt, wie Argo Rollouts und Argo CI zusammenarbeiten:
Ergebnis
Mir gefällt die Idee, CRDs zu verwenden, die die Erstellung zusätzlicher Bereitstellungstypen oder Replikatsätze, die Umleitung des Datenverkehrs usw. verwalten, sehr gut. Die Zusammenarbeit mit ihnen verläuft reibungslos. Als nächstes möchte ich die Integration mit Argo CI testen.
Es scheint jedoch, dass eine große Fusion von Argo CI und Flux CI bevorsteht, also werde ich vielleicht warten, bis die neue Version herauskommt: .
Haben Sie Erfahrungen mit Argo Rollouts oder Argo CI?
Lesen Sie auch andere Artikel in unserem Blog:
Source: habr.com