Die kanarische Bereitstellung ist eine sehr effektive Methode, um neuen Code für eine Untergruppe von Benutzern zu testen. Dadurch wird die Verkehrslast erheblich reduziert, was während des Bereitstellungsprozesses zu Problemen führen kann, da sie nur innerhalb einer bestimmten Untergruppe auftritt. Dieser Artikel befasst sich mit der Organisation einer ähnlichen Bereitstellung mithilfe von Kubernetes und der Bereitstellungsautomatisierung.
Es wird davon ausgegangen, dass Sie etwas ĂĽber die Ressourcen von Helm und Kubernetes wissen .
Die einfache kanarische Bereitstellung von Kubernetes umfasst zwei wichtige Ressourcen: den Dienst selbst und das Bereitstellungstool. Die kanarische Bereitstellung erfolgt über einen Dienst, der mit zwei verschiedenen Ressourcen interagiert, die den Aktualisierungsverkehr bedienen. Eine dieser Ressourcen funktioniert mit der "kanarischen" Version und die zweite mit der stabilen. In dieser Situation können wir die Anzahl der kanarischen Versionen anpassen, um den für die Wartung erforderlichen Datenverkehr zu reduzieren. Wenn Sie beispielsweise Yaml bevorzugen, sieht dies in Kubernetes folgendermaßen 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.
Es ist noch einfacher, sich eine solche Option in kubectl vorzustellen, und die
Kubernetes-Dokumentation enthält sogar ein vollständiges Tutorial zu diesem Szenario. Die Hauptfrage dieses Beitrags ist jedoch, wie wir diesen Prozess mit Helm automatisieren können.
Automatisierung eines kanarischen Einsatzes
Zunächst benötigen wir die Helmkartenkarte, die bereits die von uns oben diskutierten 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 Versionen mit mehreren Versionen. Die stabile Version ist unser stabiler Hauptzweig des Projektcodes. Aber mit Helm können wir mit unserem experimentellen Code eine kanarische Version bereitstellen. Die Hauptsache ist, den Verkehrsaustausch zwischen der stabilen Version und der kanarischen Version aufrechtzuerhalten. Wir werden dies alles mit einem speziellen Selektor verwalten:
selector: app.kubernetes.io/name: myapp
Unsere "kanarischen" und stabilen Bereitstellungsressourcen geben dieses Etikett auf den Modulen an. Wenn alles richtig eingerichtet ist, werden wir während der Bereitstellung der kanarischen Version unserer Helmkarte sehen, dass der Datenverkehr zu frisch bereitgestellten Modulen geleitet wird. Eine 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 jetzt unsere kanarische Veröffentlichung an. Um die kanarische Version bereitzustellen, müssen wir uns zwei Dinge merken. Der Versionsname muss unterschiedlich sein, damit das Update für die aktuelle stabile Version nicht aufgerollt wird. Die Version und das Tag müssen auch unterschiedlich sein, damit wir unterschiedlichen Code bereitstellen und Unterschiede anhand von Ressourcenbezeichnungen identifizieren 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 eigentlich alles! Wenn Sie den Dienst anpingen, können Sie sehen, dass das kanarische Update den Verkehr nur teilweise weiterleitet.
Wenn Sie nach Tools fĂĽr die Bereitstellungsautomatisierung suchen, die die beschriebene Logik enthalten, lesen Sie
Deliverybot und die
Helm-Automatisierungstools auf GitHub . Die Helm-Diagramme, die zur Implementierung der oben beschriebenen Methode verwendet wurden, befinden sich hier auf Github. Im Allgemeinen war dies ein theoretischer Ăśberblick ĂĽber die praktische Umsetzung des Einsatzes kanarischer Versionen mit spezifischen Konzepten und Beispielen.