Automatisieren Sie Canary Release-Entscheidungen in Ihrem Kubernetes-Cluster

Chao Zhang

Chao Zhang

December 30, 2022

Technology

Hintergrund

Heutzutage ist Microservices eine typische und weit verbreitete Softwarearchitektur. Dienste sind lose gekoppelt und arbeiten über APIs zusammen. Das Microservice-Muster macht jede Anwendung unabhängig bereitstellbar und wartbar, sodass die Veröffentlichung häufiger erfolgt. Wie wir alle wissen, ist die Veröffentlichung riskant; man weiß nie, ob es in der neuen Version Fehler gibt. Deshalb verwenden Menschen Strategien wie Canary Release und Blue-Green Deployment, um ihre neueste Version schrittweise auszurollen und das Risiko zu verringern.

Canary Release teilt den Datenverkehr in zwei Gruppen des Zielservices auf: die stabile Gruppe und die Canary-Gruppe. API-Gateways wie Apache APISIX stellen die Microservice-Architektur effizient und sicher über APIs bereit. Sie sind mit der Funktion des Canary Release ausgestattet. Typischerweise gibt es zwei Möglichkeiten, die Aufteilung des Datenverkehrs zu bestimmen: die gewichtsbasierte Methode und die prädikative Ausdrucksmethode.

Gewichtsbasierte Methode

Gewichtsbasierte Methode

Benutzer müssen den Anteil des Datenverkehrs angeben, der die Canary-Gruppe erreichen soll. Im obigen Bild werden 95 % des Datenverkehrs an den stabilen Dienst weitergeleitet, während die anderen 5 % an die Canary-Gruppe weitergeleitet werden.

Prädikative Ausdrucksmethode

Prädikative Ausdrucksmethode

Die prädikative Ausdrucksmethode zeigt an, dass nur Datenverkehr, der den angegebenen Merkmalen entspricht, die Canary-Gruppe erreicht. Zum Beispiel erreichen nur HTTP-Anfragen mit dem Anfrageheader X-Debug und seinem tatsächlichen Wert den Canary-Dienst.

Automatisierung des Canary Release

Wenn Sie das API-Gateway durch Aufrufen der API oder des Dashboards betreiben, gibt es eine zeitliche Verzögerung bei der Anpassung des Datenverkehrsverhältnisses (für die gewichtsbasierte Methode) oder der Prädikate (für die prädikative Ausdrucksmethode). Heutzutage verwenden immer mehr Benutzer Kubernetes, um ihre Microservices zu orchestrieren. Können Benutzer den Canary Release starten, sobald die neue Dienstversion erstellt wird? In diesem Artikel zeige ich Ihnen, wie Sie API7 Cloud verwenden können, um den Canary Release in Ihrem Kubernetes-Cluster zu automatisieren.

Was ist API7 Cloud

API7 Cloud ist eine Any-Cloud, Multi-Location SaaS-Plattform für die Bereitstellung, Steuerung, Visualisierung und Überwachung von APIs in großem Maßstab. Führen Sie Ihre APIs überall aus, verwalten Sie sie jedoch an einem Ort. API7 Cloud verwendet Apache APISIX als API-Gateway, um Ihre APIs effizient und sicher bereitzustellen.

API7 Cloud

Um API7 Cloud zu verwenden, müssen Sie Apache APISIX auf Ihrer Infrastruktur bereitstellen, wie z.B. Docker und Kubernetes. Sie können Cloud CLI verwenden, um die Bereitstellung zu vereinfachen.

# Konfigurieren Sie ein Zugriffstoken aus der API7 Cloud-Konsole.
cloud-cli configure --token {YOUR TOKEN}

# Stellen Sie Apache APISIX (Version 2.15.1) im Namespace apisix bereit, mit nur einer Replik.
cloud-cli deploy kubernetes \
  --name my-apisix \
  --namespace apisix \
  --replica-count 1 \
  --apisix-image apache/apisix:2.15.1-centos

Canary Release ist eine der integrierten Funktionen von API7 Cloud. Benutzer können die Canary Release-Regeln entweder über die Konsole konfigurieren oder die API7 Cloud Open API aufrufen. Unser Ziel ist es, die Canary Release-Entscheidungen zu automatisieren, daher verwenden wir die letztere Methode.

Szenario

Nehmen wir an, in unserem Kubernetes-Cluster gibt es eine einfache Error-Page-Anwendung, die immer eine Fehlermeldung zurückgibt. Wir rollen die Version 2.0 aus und möchten die Canary Release-Strategie verwenden, um das Veröffentlichungsrisiko zu verringern. Darüber hinaus möchten wir den gesamten Prozess automatisieren. Daher erstellen wir einen Canary Release-Controller, der die Änderungen in den Kubernetes-Service-Ressourcen überwacht und dann die Canary Releases auf API7 Cloud über das API7 Cloud Go SDK erstellt oder ändert. Wir verwenden nur die gewichtsbasierte Methode, um den Datenverkehr aufzuteilen. Alle Komponenten, einschließlich des Apache APISIX API-Gateways, werden auf Kubernetes bereitgestellt, sodass das Diagramm wie folgt aussieht:

Diagramm

Der Canary Release-Controller überwacht die Service-Änderungen und reagiert entsprechend einiger Annotationen, insbesondere:

  • Wenn der Service die Annotation api7.cloud/published-service enthält, versucht der Canary Release-Controller, eine Anwendung auf API7 Cloud zu erstellen.
  • Wenn der Service die Annotation api7.cloud/published-canary-service hat, versucht der Canary Release-Controller, die Canary Release-Regel auf API7 Cloud einzurichten, und die Annotation api7.cloud/published-service-canary-percentage bestimmt den Prozentsatz.

Beachten Sie, dass dieser Controller nicht eigenständig ist (er löscht die Anwendung nicht, wenn der Service gelöscht wird), aber er reicht aus, um den automatisierten Canary Release-Prozess zu zeigen.

Los geht's!

Beginnen wir mit der Bereitstellung von Apache APISIX und dem Canary Release-Controller. Wie oben erwähnt, verwenden wir Cloud CLI, um Apache APISIX bereitzustellen. Wir haben auch zwei YAML-Dateien (error-page/manifest-v1.yaml und controller/manifest.yaml) für die Bereitstellung der Error-Page-Anwendung und des Canary Release-Controllers.

  1. Bitte bereiten Sie einen verfügbaren Kubernetes-Cluster vor, wenn Sie die folgenden Befehle ausführen möchten.
  2. Der Canary Release-Controller benötigt ein Zugriffstoken für den Aufruf der API7 Cloud API. Wir holen ein Token gemäß diesem Dokument und speichern das Token in einem K8s-Secret.
kubectl create namespace canary-release-demo
# Stellen Sie die Error-Page v1-Version bereit.
kubectl apply -f https://raw.githubusercontent.com/tokers/canary-release-automation-demo/main/error-page/manifest-v1.yaml -n canary-release-demo

# Erstellen Sie ein K8s-Secret, um das API7 Cloud-Zugriffstoken zu speichern.
kubectl create secret generic api7-cloud --namespace canary-release-demo --from-literal token={Ihr Zugriffstoken}

# Stellen Sie den Canary Release-Controller bereit.
kubectl apply -f https://raw.githubusercontent.com/tokers/canary-release-automation-demo/main/controller/manifest.yaml -n canary-release-demo

# Überprüfen Sie, ob alle Workloads normal sind.
kubectl get all -n canary-release-demo

Überprüfen Sie den Proxy

Lassen Sie uns diesen Service durch Annotation veröffentlichen.

kubectl annotate service -n canary-release-demo error-page-v1 "api7.cloud/published-service=error-page"

Der Canary Release-Controller wird diese Änderung überwachen und eine Anwendung auf API7 Cloud erstellen. Jetzt greifen wir auf Apache APISIX zu, um zu sehen, ob der Proxy normal funktioniert.

kubectl port-forward -n canary-release-demo service/apisix-gateway 10080:80
curl http://127.0.0.1:10080/api/error_page -H 'Host: error-page' -s

Wenn alles in Ordnung ist, sehen Sie {"error": "injected by error_page service", "version": "v1"}.

Derzeit erstellt der Canary Release-Controller eine "match-everything"-API in der Anwendung, und der Host ist derselbe wie der Anwendungsname (error-page).

Rollout von V2

Wir möchten Version 2 für die Error-Page-Anwendung ausrollen. Zuerst stellen wir Version 2 durch Anwenden der manifest-v2.yaml bereit. Wir annotieren den error-page-v2-Service mit den Canary Release-Annotationen.

kubectl apply -f https://raw.githubusercontent.com/tokers/canary-release-automation-demo/main/error-page/manifest-v2.yaml -n canary-release-demo

# Informieren Sie den Canary Release-Controller, dass wir den Canary Release für error-page-v2 aktivieren und der Prozentsatz 10 % beträgt.
kubectl annotate service -n canary-release-demo error-page-v2 "api7.cloud/published-canary-service=true" "api7.cloud/published-service-canary-percentage=10"

# Starten Sie den Canary.
kubectl annotate service -n canary-release-demo error-page-v2 "api7.cloud/published-service=error-page"

Jetzt senden wir erneut 100 Anfragen an Apache APISIX und sehen, ob einige Anfragen an den Canary-Service error-page-v2 weitergeleitet wurden.

kubectl port-forward -n canary-release-demo service/apisix-gateway 10080:80
for ((i=0; i<100; i++)); do
  curl http://127.0.0.1:10080/api/error_page -H 'Host: error-page' -s
done

Nur etwa 10 % der Anfragen erreichen error-page-v2 (nicht genau 10 % aufgrund der internen Strategie, die Apache APISIX zur Auswahl des Backends verwendet), wenn alles gut läuft.

Rollback

Wir haben festgestellt, dass Version 2 instabil ist und möchten sie zurückrollen. Bevor wir dies tun, stoppen wir den Canary, indem wir den Prozentsatz auf 0 setzen. Dann senden wir erneut Anfragen an Apache APISIX.

kubectl annotate service -n canary-release-demo error-page-v2 "api7.cloud/published-service-canary-percentage=0" --overwrite
for ((i=0; i<100; i++)); do
  curl http://127.0.0.1:10080/api/error_page -H 'Host: error-page' -s
done

Sie werden sehen, dass alle Anfragen jetzt an error-page-v1 gehen.

Veröffentlichung

Nach einer langen Zeit glauben wir, dass Version 2 stabil genug ist, und wir möchten, dass alle Anfragen Version 2 erreichen. Dann können wir die Error-Page-Anwendung Version 1 außer Betrieb nehmen. Daher setzen wir den Prozentsatz auf 100 %.

kubectl annotate service -n canary-release-demo error-page-v2 "api7.cloud/published-service-canary-percentage=100" --overwrite
for ((i=0; i<100; i++)); do
  curl http://127.0.0.1:10080/api/error_page -H 'Host: error-page' -s
done

Jetzt werden alle Anfragen an error-page-v2 weitergeleitet. Und error-page-v1 kann sicher außer Betrieb genommen werden.

Zusammenfassung

Canary Release ist eine effektive Waffe für die Veröffentlichung. Das Anpassen der Canary Release-Strategie kann jedoch verzögert sein. Dieser Artikel zeigt, wie man Canary Releases deklarativ betreibt und den Canary Release bis zu einem gewissen Grad automatisiert. Einige Leute streben möglicherweise einen vollständig automatischen Canary Release mit Hilfe von GitOps-Komponenten an. Zum Beispiel kann man mit Argo Rollouts Dienste automatisch fördern oder zurückrollen. Argo Rollouts fragt die Dienstmetriken ab und integriert sich mit Ingress-Controllern, um ihre CRDs zu ändern. Letztendlich leitet das API-Gateway Anfragen in den richtigen Anteilen an die Canary-Version weiter.

Referenz

Quellcode für die Error-Page und den Canary Release-Controller: https://github.com/tokers/canary-release-automation-demo.

Tags:
API Gateway Concept
API7 Cloud
Kubernetes