Automatisez les décisions de déploiement Canary dans votre cluster Kubernetes

Contexte

Aujourd'hui, les microservices sont devenus un modèle d'architecture logicielle typique et largement utilisé. Les services sont faiblement couplés et collaborent via des API. Le modèle de microservices permet à chaque application d'être déployée et maintenue de manière indépendante, ce qui rend les versions plus fréquentes. Comme nous le savons tous, la publication est risquée ; vous ne savez jamais s'il y a des bogues dans la nouvelle version. C'est pourquoi les gens utilisent des stratégies comme le déploiement canari et le déploiement bleu-vert pour déployer progressivement leur dernière version et réduire le risque.

Le déploiement canari divise le trafic en deux groupes de services cibles, le groupe stable et le groupe canari. Une passerelle API, comme Apache APISIX, expose efficacement et en toute sécurité l'architecture de microservices via des API. Elle est équipée de la fonctionnalité de déploiement canari. Généralement, il existe deux façons de décider comment diviser le trafic : la méthode basée sur le poids et la méthode basée sur les expressions de prédicat.

Méthode Basée sur le Poids

Les utilisateurs doivent spécifier la proportion du trafic qui atteindra le groupe canari. Dans l'image ci-dessus, 95 % du trafic sera redirigé vers le service stable, tandis que les 5 % restants seront redirigés vers le service canari.

Méthode Basée sur les Expressions de Prédicat

La méthode basée sur les expressions de prédicat de requête indique que seul le trafic qui correspond aux caractéristiques spécifiées atteindra le groupe canari. Par exemple, seules les requêtes HTTP avec l'en-tête de requête X-Debug et sa valeur réelle atteindront le service canari.

Automatisation du Déploiement Canari

Lorsque vous opérez la passerelle API en appelant l'API ou le tableau de bord, il y aura un décalage temporel dans l'ajustement du ratio de trafic (pour la méthode basée sur le poids) ou des prédicats (pour la méthode basée sur les expressions de prédicat). Aujourd'hui, de plus en plus d'utilisateurs utilisent Kubernetes pour orchestrer leurs microservices. Les gens peuvent-ils démarrer le déploiement canari une fois que la nouvelle version du service est créée ? Dans cet article, je vais vous montrer comment utiliser API7 Cloud pour automatiser le déploiement canari dans votre cluster Kubernetes.

Qu'est-ce que API7 Cloud

API7 Cloud est une plateforme SaaS multi-cloud et multi-localisation pour déployer, contrôler, visualiser et surveiller des API à grande échelle. Exécutez vos API n'importe où, mais gérez-les en un seul endroit. API7 Cloud utilise Apache APISIX comme passerelle API pour exposer vos API de manière efficace et sécurisée.

Pour utiliser API7 Cloud, vous devez déployer Apache APISIX sur vos infrastructures, comme Docker et Kubernetes. Vous pouvez utiliser Cloud CLI pour faciliter le déploiement.

# Configurez un jeton d'accès depuis la console API7 Cloud.
cloud-cli configure --token {VOTRE JETON}

# Déployez Apache APISIX (version 2.15.1) dans l'espace de noms apisix, avec un seul réplica.
cloud-cli deploy kubernetes \
  --name my-apisix \
  --namespace apisix \
  --replica-count 1 \
  --apisix-image apache/apisix:2.15.1-centos

Le déploiement canari est l'une des fonctionnalités intégrées d'API7 Cloud. Les utilisateurs peuvent configurer les règles de déploiement canari via la console ou appeler l'API ouverte d'API7 Cloud. Notre objectif est d'automatiser les décisions de déploiement canari, nous utiliserons donc la deuxième méthode.

Scénario

Supposons que dans notre cluster Kubernetes, il y ait une application simple de page d'erreur, qui renvoie toujours un message d'erreur. Nous déployons la version 2.0 et souhaitons utiliser la stratégie de déploiement canari pour réduire le risque de publication. De plus, nous souhaitons également automatiser l'ensemble du processus. Par conséquent, nous créons un contrôleur de déploiement canari, qui surveille les changements dans les ressources de service Kubernetes, puis crée/modifie les déploiements canari sur API7 Cloud via le SDK Go d'API7 Cloud. Nous n'utilisons que la méthode basée sur le poids pour diviser le trafic. Tous les composants, y compris la passerelle API Apache APISIX, seront déployés sur Kubernetes, donc le diagramme sera comme suit :

Le contrôleur de déploiement canari surveille les changements de service et réagit en fonction de certaines annotations, spécifiquement :

• Si le service contient l'annotation api7.cloud/published-service, le contrôleur de déploiement canari essaiera de créer une Application sur API7 Cloud.
• Si le service a l'annotation api7.cloud/published-canary-service, le contrôleur de déploiement canari essaiera de configurer la règle de déploiement canari sur API7 Cloud et l'annotation api7.cloud/published-service-canary-percentage décidera du pourcentage.

Notez que ce contrôleur n'est pas autonome (il ne supprime pas l'Application si le service est supprimé), mais il est suffisant pour montrer le processus de déploiement canari automatisé.

C'est parti !

Commençons par déployer Apache APISIX et le contrôleur de déploiement canari. Comme mentionné ci-dessus, nous utilisons Cloud CLI pour déployer Apache APISIX. Nous avons également deux fichiers YAML (error-page/manifest-v1.yaml et controller/manifest.yaml) pour déployer l'application de page d'erreur et le contrôleur de déploiement canari.

1. Veuillez préparer un cluster Kubernetes disponible si vous souhaitez exécuter les commandes suivantes.
2. Le contrôleur de déploiement canari a besoin d'un jeton d'accès pour appeler l'API d'API7 Cloud. Nous récupérons un jeton selon ce document et stockons le jeton dans un secret K8s.

kubectl create namespace canary-release-demo
# Déployez la version v1 de la page d'erreur.
kubectl apply -f https://raw.githubusercontent.com/tokers/canary-release-automation-demo/main/error-page/manifest-v1.yaml -n canary-release-demo

# Créez un secret K8s pour enregistrer le jeton d'accès d'API7 Cloud.
kubectl create secret generic api7-cloud --namespace canary-release-demo --from-literal token={Votre Jeton d'Accès}

# Déployez le contrôleur de déploiement canari.
kubectl apply -f https://raw.githubusercontent.com/tokers/canary-release-automation-demo/main/controller/manifest.yaml -n canary-release-demo

# Vérifiez si toutes les charges de travail sont normales.
kubectl get all -n canary-release-demo

Vérifiez le proxy

Publions ce service en l'annotant.

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

Le contrôleur de déploiement canari surveillera ce changement et créera une Application sur API7 Cloud. Maintenant, accédons à Apache APISIX pour voir si le proxy fonctionne normalement.

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

Si tout est OK, vous verrez {"error": "injected by error_page service", "version": "v1"}.

Actuellement, le contrôleur de déploiement canari crée une API "match-everything" dans l'Application, et l'hôte est le même que le nom de l'Application (error-page).

Déployez V2

Nous voulons déployer la version 2 de l'application de page d'erreur. Tout d'abord, nous déployons la version 2 en appliquant le fichier manifest-v2.yaml. Nous annotons le service error-page-v2 avec les annotations de déploiement canari.

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

# Dites au contrôleur de déploiement canari que nous activons le déploiement canari pour error-page-v2, et le pourcentage est de 10%.
kubectl annotate service -n canary-release-demo error-page-v2 "api7.cloud/published-canary-service=true" "api7.cloud/published-service-canary-percentage=10"

# Démarrez le canari.
kubectl annotate service -n canary-release-demo error-page-v2 "api7.cloud/published-service=error-page"

Maintenant, envoyons 100 requêtes à Apache APISIX et voyons si certaines requêtes ont été redirigées vers le service canari error-page-v2.

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

Environ 10 % des requêtes atteindront error-page-v2 (pas exactement 10 % en raison de la stratégie interne qu'Apache APISIX utilise pour sélectionner le backend) si tout se passe bien.

Retour en arrière

Nous avons constaté que la version 2 est instable et souhaitons revenir en arrière. Avant de le faire, nous arrêterons d'abord le canari, donc nous changeons le pourcentage à 0. Ensuite, envoyons à nouveau des requêtes à 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

Vous verrez que toutes les requêtes vont maintenant vers error-page-v1.

Publication

Après un certain temps, nous pensons que la version 2 est suffisamment stable, et nous voulons que toutes les requêtes atteignent la version 2. Ensuite, nous pouvons mettre hors ligne l'application de page d'erreur version 1. Nous changeons donc le pourcentage à 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

Maintenant, toutes les requêtes sont redirigées vers error-page-v2. Et error-page-v1 peut être mise hors ligne en toute sécurité.

Résumé

Le déploiement canari est une arme efficace pour la publication. Cependant, ajuster la stratégie de déploiement canari peut être hystérique. Cet article montre comment opérer les déploiements canari de manière déclarative et automatiser le déploiement canari dans une certaine mesure. Certains pourraient rechercher un déploiement canari entièrement automatique avec l'aide de composants GitOps. Par exemple, en utilisant Argo Rollouts, on peut automatiquement promouvoir ou revenir en arrière sur les services. Argo Rollouts interroge les métriques du service et s'intègre avec les contrôleurs d'entrée pour modifier leurs CRD. En fin de compte, la passerelle API redirigera les requêtes dans les bonnes proportions vers la version canari.

Référence

Code source pour la page d'erreur et le contrôleur de déploiement canari : https://github.com/tokers/canary-release-automation-demo.