Eine einfache und sichere Methode zur Automatisierung von Canary-Deployments mit Helm

Ein Canary-Deploy ist eine äußerst effektive Methode, um neuen Code bei einer bestimmten Benutzergruppe zu testen. Es reduziert erheblich die Verkehrslast, mit der Probleme während des Deployments auftreten können, da es nur innerhalb einer definierten Untergruppe erfolgt. Diese Notiz widmet sich der Organisation eines solchen Deployments mithilfe von Kubernetes und Deployment-Automatisierung. Es wird vorausgesetzt, dass Sie etwas über Helm und Kubernetes-Ressourcen wissen..



Ein einfaches Canary-Deployment in Kubernetes umfasst zwei zentrale Ressourcen: den Service selbst und das Deployment-Tool. Das Canary-Deployment funktioniert über einen Dienst, der mit zwei verschiedenen Ressourcen interagiert, die den Aktualisierungstraffic bedienen. Eine dieser Ressourcen wird mit der "Canary"-Version arbeiten, die andere mit der stabilen Version. In dieser Situation können wir die Anzahl der Canary-Versionen regulieren, um das benötigte Verkehrsvolumen zu minimieren. Wenn Sie beispielsweise Yaml verwenden möchten, wird das 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 # Der Selector leitet den Verkehr an beide Deployments weiter.

Ein solches Beispiel lässt sich sogar einfach über kubectl darstellen, während in der Dokumentation zu Kubernetes es sogar ein vollständiges Tutorial zu diesem Szenario gibt. Die zentrale Frage dieses Beitrags ist, wie wir diesen Prozess mit Helm automatisieren wollen.

Automatisierung des Canary-Deployments

Zunächst benötigen wir eine Helm-Chart-Datei, in der 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

Das Grundkonzept von Helm ist die Verwaltung mehrerer Versionen von Releases. Die stabile Version ist unser Hauptzweig des stabilen Codes für das Projekt. Aber mit Helm können wir ein Canary-Release mit unserem experimentellen Code bereitstellen. Das Wichtigste ist, den Traffic zwischen der stabilen Version und dem Canary-Release zu steuern. Wir werden dies mit einem speziellen Selector verwalten:

selector:
  app.kubernetes.io/name: myapp

Unsere Deployment-Ressourcen, sowohl Canary- als auch Stable-Versionen, werden dieses Label in den Modulen anzeigen. Wenn alles korrekt konfiguriert ist, werden wir während des Deployments der Canary-Version unserer Helm-Charts sehen, dass der Verkehr auf die neu bereitgestellten Module geleitet wird. Die Stable-Version dieses Kommandos sieht folgendermaßen 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 unseren Canary-Release überprüfen. Um die Canary-Version bereitzustellen, müssen wir uns an zwei Dinge erinnern. Der Name des Releases muss unterschiedlich sein, damit wir kein Update auf die aktuelle Stable-Version anwenden. Die Version und das Tag müssen ebenfalls unterschiedlich sein, damit wir einen anderen Code bereitstellen und die Unterschiede anhand der Ressourcen-Labels 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 man den Dienst anpingt, kann man sehen, dass das Canary-Update den Verkehr nur zeitweise umleitet.

Wenn Sie nach Automatisierungswerkzeugen für Deployments suchen, die die beschriebene Logik beinhalten, sollten Sie sich auf Deliverybot und auf der Automatisierungstools von Helm auf GitHub. Die Helm-Charts, die zur Umsetzung der oben beschriebenen Methode verwendet werden, finden Sie auf GitHub, hier nachlesen. Insgesamt war dies ein theoretischer Überblick darüber, wie man die Automatisierung von Canary-Deployments in der Praxis umsetzen kann, mit konkreten Konzepten und Beispielen.

Quelle: habr.com