Eine einfache und sichere Möglichkeit zur Automatisierung von Canary-Deployments mit Helm

Ein Canary-Deploy ist eine sehr effektive Methode zum Testen neuer Codes an einer bestimmten Nutzergruppe. Er reduziert deutlich die Traffic-Belastung, bei der es während des Rollouts zu Problemen kommen könnte, da er nur innerhalb einer bestimmten Untergruppe erfolgt. Dieser Artikel widmet sich der Organisation eines solchen Deploys mit Hilfe von Kubernetes und Automatisierung. Es wird vorausgesetzt, dass Sie etwas über Helm und Kubernetes-Ressourcen wissen..



Ein einfacher Canary-Deploy in Kubernetes umfasst zwei Schlüsselressourcen: den Dienst selbst und das Bereitstellungstool. Der Canary-Deploy funktioniert über einen einzelnen Dienst, der mit zwei verschiedenen Ressourcen interagiert, die den Traffic der Aktualisierung bedienen. Eine dieser Ressourcen wird mit der "canary"-Version arbeiten, während die andere mit der stabilen Version arbeitet. In dieser Situation können wir die Anzahl der Canary-Versionen regulieren, um das benötigte Traffic-Volumen zu senken. Wenn Sie zum Beispiel Yaml bevorzugen, würde es in Kubernetes folgendermaßen aussehen:

kind: Deployment
metadata:
  name: app-canary
  labels:
    app: app
spec:
  replicas: 1
  ...
    image: myapp:canary
---
kind: Deployment
metadata:
  name: app
  labels:
    app: app
spec:
  replicas: 5
  ...
    image: myapp:stable
---
kind: Service
selector:
  app: app # Selector routet den Traffic zu beiden Deployments.

Einen solchen Ansatz kann man auch auf kubectl anwenden, und in der Kubernetes-Dokumentation gibt es sogar ein vollständiges Tutorial zu diesem Szenario. Aber die zentrale Frage dieses Beitrags ist, wie wir diesen Prozess automatisieren möchten, indem wir Helm verwenden.

Automatisierung des Canary-Deploys

Zunächst benötigen wir eine Helm-Chart-Datei, in die die oben besprochenen Ressourcen bereits aufgenommen sind. Sie sollte ungefähr so aussehen:

~\/charts\/app
├── Chart.yaml
├── README.md
├── templates
│   ├── NOTES.txt
│   ├── _helpers.tpl
│   ├── deployment.yaml
│   └── service.yaml
└── values.yaml

Die Grundlage des Helm-Konzepts ist die Verwaltung von Mehrversions-Deployments. Die Stable-Version ist unser stabiler Hauptzweig des Projektcodes. Aber mit Helm können wir ein Canary-Release mit unserem experimentellen Code bereitstellen. Das Wichtigste ist, den Traffic-Austausch zwischen der stabilen Version und dem Canary-Release aufrechtzuerhalten. Wir werden all dies mithilfe eines speziellen Selektors verwalten:

selector:
  app.kubernetes.io\/name: myapp

Unsere sowohl „kanarienvogelartigen“ als auch stabilen Rollout-Ressourcen werden dieses Label in den Modulen angeben. Wenn alles richtig eingerichtet ist, werden wir während des Deployments der kanarienvogelartigen Version unserer Helm-Chart sehen, dass der Traffic an die neu bereitgestellten Module geleitet wird. Die stabile Version dieses Befehls sieht so aus:

helm upgrade
  --install myapp 
  --namespace default 
  --set app.name=myapp       # Geht in app.kubernetes.io/name
  --set app.version=v1       # Geht in app.kubernetes.io/version
  --set image.tag=stable 
  --set replicaCount=5

Jetzt lassen Sie uns unser kanarienvogelartiges Release überprüfen. Um die kanarienvogelartige Version zu deployen, müssen wir an zwei Dinge denken. Der Name des Releases muss sich unterscheiden, damit wir kein Update auf die aktuelle stabile Version anwenden. Die Version und das Tag müssen ebenfalls unterschiedlich sein, damit wir anderen Code bereitstellen und Unterschiede anhand von Ressourcengruppen feststellen können.

helm upgrade
  --install myapp-canary 
  --namespace default 
  --set app.name=myapp       # Geht in app.kubernetes.io/name
  --set app.version=v2       # Geht in app.kubernetes.io/version
  --set image.tag=canary 
  --set replicaCount=1

Das ist es auch schon! Wenn Sie den Service pingen, können Sie sehen, dass das kanarienvogelartige Update den Traffic nur zeitweise leitet.

Wenn Sie nach Automatisierungstools für Deployments suchen, die die beschriebene Logik beinhalten, schauen Sie sich an, Deliverybot und auf Helm-Automatisierungstools auf GitHub. Die Helm-Charts, die zur Umsetzung der oben beschriebenen Methode verwendet werden, liegen auf GitHub, hier. Insgesamt war dies eine theoretische Betrachtung, wie man die Automatisierung des Deployments von kanarienvogelartigen Versionen in der Praxis implementiert, mit konkreten Konzepten und Beispielen.

Quelle: habr.com