Eine einfache und sichere Möglichkeit, Canary-Bereitstellungen mit Helm zu automatisieren

Die Canary-Bereitstellung ist eine sehr effektive Möglichkeit, neuen Code an einer Teilmenge von Benutzern zu testen. Dadurch wird die Verkehrslast, die während des Bereitstellungsprozesses problematisch sein kann, erheblich reduziert, da sie nur innerhalb einer bestimmten Teilmenge auftritt. Dieser Hinweis befasst sich mit der Organisation einer solchen Bereitstellung mithilfe von Kubernetes und Bereitstellungsautomatisierung. Wir gehen davon aus, dass Sie etwas über Helm- und Kubernetes-Ressourcen wissen.



Eine einfache Canary-Bereitstellung für Kubernetes umfasst zwei wichtige Ressourcen: den Dienst selbst und das Bereitstellungstool. Die Canary-Bereitstellung erfolgt über einen einzigen Dienst, der mit zwei verschiedenen Ressourcen interagiert, die den Update-Verkehr bereitstellen. Eine dieser Ressourcen funktioniert mit der „canary“-Version und die zweite mit der stabilen Version. In dieser Situation können wir die Anzahl der Canary-Versionen regulieren, um den für die Bereitstellung erforderlichen Datenverkehr zu reduzieren. Wenn Sie beispielsweise lieber Yaml verwenden, dann sieht das in Kubernetes so aus:

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 will route traffic to both deployments.

Noch einfacher kann man sich diese Option mit kubectl und in vorstellen Kubernetes-Dokumentation Es gibt sogar ein vollständiges Tutorial zu diesem Szenario. Die Hauptfrage dieses Beitrags ist jedoch, wie wir diesen Prozess mithilfe von Helm automatisieren werden.

Automatisierung der Canary-Bereitstellung

Zunächst benötigen wir eine Helm-Diagrammkarte, die bereits die oben besprochenen Ressourcen enthält. Es sollte ungefähr so ​​aussehen:

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

Grundlage des Helm-Konzepts ist die Verwaltung von Multiversions-Releases. Die stabile Version ist unser wichtigster stabiler Zweig des Projektcodes. Aber mit Helm können wir mit unserem experimentellen Code eine Canary-Version bereitstellen. Die Hauptsache besteht darin, den Datenverkehr zwischen der stabilen Version und der Canary-Version aufrechtzuerhalten. All dies verwalten wir mit einem speziellen Selektor:

selector:
  app.kubernetes.io/name: myapp

Unsere „kanarischen“ und stabilen Bereitstellungsressourcen weisen dieses Etikett auf den Modulen auf. Wenn alles richtig konfiguriert ist, werden wir während der Bereitstellung der Canary-Version unserer Helm-Chart-Map feststellen, dass der Datenverkehr an die neu bereitgestellten Module weitergeleitet wird. Die stabile Version dieses Befehls sieht folgendermaßen aus:

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

Schauen wir uns nun unsere kanarische Veröffentlichung an. Um die Canary-Version bereitzustellen, müssen wir zwei Dinge beachten. Der Release-Name muss unterschiedlich sein, damit wir kein Update auf die aktuelle stabile Version ausrollen. Auch die Version und das Tag müssen unterschiedlich sein, damit wir anderen Code bereitstellen und Unterschiede anhand der Ressourcen-Tags erkennen können.

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

Das ist alles! Wenn Sie den Dienst anpingen, können Sie sehen, dass das Canary-Update den Datenverkehr nur zeitweise weiterleitet.

Wenn Sie nach Tools zur Bereitstellungsautomatisierung suchen, die die beschriebene Logik enthalten, dann achten Sie auf Lieferbot und Helm-Automatisierungstools auf GitHub. Die zur Implementierung der oben beschriebenen Methode verwendeten Helm-Charts befinden sich auf Github. hierher. Im Allgemeinen handelte es sich um einen theoretischen Überblick darüber, wie die Automatisierung der Bereitstellung von Canary-Versionen in der Praxis umgesetzt werden kann, mit spezifischen Konzepten und Beispielen.

Source: habr.com