🥇Déploiement Canary dans Kubernetes #2 : Argo Rollouts

Nous allons utiliser le contrôleur de déploiement natif k8s Argo Rollouts et GitlabCI pour exécuter un déploiement Canary dans Kubernetes

https://unsplash.com/photos/V41PulGL1z0

Articles de ce cycle

Déploiement Canary dans Kubernetes #1 : Gitlab CI
(Cet article)
Déploiement Canary avec Istio
Déploiement Canary avec Jenkins-X Istio Flagger

Déploiement Canary

Nous espérons que vous avez lu la première partie, où nous avons brièvement expliqué ce qu'est un déploiement Canary. Nous avons également montré comment le mettre en œuvre en utilisant les ressources standard de Kubernetes.

Argo Rollouts

Argo Rollouts est un contrôleur de déploiement natif de Kubernetes. Il fournit une CRD (Custom Resource Definition) pour Kubernetes. Grâce à celui-ci, nous pouvons utiliser une nouvelle entité : Rollout, qui gère les déploiements blue-green et canary avec diverses options de configuration.

Le contrôleur Argo Rollouts, utilisé par la ressource personnalisée Rollout, permet d'utiliser des stratégies de déploiement supplémentaires, comme blue-green et canary pour Kubernetes. La ressource Rollout fournit des fonctionnalités équivalentes Déploiement, mais avec des stratégies de déploiement supplémentaires.
Ressource Déploiements possède deux stratégies de déploiement : RollingUpdate et Recreate. Bien que ces stratégies conviennent à la plupart des cas, des déploiements dans des serveurs à très grande échelle nécessitent des stratégies supplémentaires, telles que blue-green ou canary, qui ne sont pas présentes dans le contrôleur Deployment. Pour utiliser ces stratégies dans Kubernetes, les utilisateurs devaient écrire des scripts au-dessus de leurs Deployments. Le contrôleur Argo Rollouts fournit ces stratégies sous forme de paramètres déclaratifs simples et configurables.
https://argoproj.github.io/argo-rollouts

Il existe également Argo CI, qui fournit une interface web conviviale à utiliser avec Rollouts, nous y jetterons un coup d'œil dans l'article suivant.

Installation d'Argo Rollouts

Côté serveur

kubectl create namespace argo-rolloutskubectl apply -n argo-rollouts -f https://raw.githubusercontent.com/argoproj/argo-rollouts/stable/manifests/install.yaml

Dans notre dépôt d'infrastructure (voir ci-dessous), nous avons déjà ajouté install.yaml comme i/k8s/argo-rollouts/install.yaml. Ainsi, GitlabCI l'installera dans le cluster.

Du côté client (plugin kubectl)

https://argoproj.github.io/argo-rollouts/features/kubectl-plugin

Exemple d'application

Il est bon de pratiquer d'avoir des dépôts séparés pour le code de l'application et pour l'infrastructure.

Dépôt pour l'application

Kim Wuestkamp / k8s-deployment-example-app

C'est une API très simple en Python+Flask, renvoyant une réponse au format JSON. Nous allons construire le paquet, en utilisant GitlabCI et pousser le résultat dans le registre Gitlab. Dans le registre, nous avons deux versions différentes des releases :

wuestkamp/k8s-deployment-example-app:v1
wuestkamp/k8s-deployment-example-app:v2

La seule différence entre eux est le fichier JSON retourné. Nous utilisons cette application pour visualiser le plus simplement possible avec quelle version nous interagissons.

Dépôt d'infrastructure

Dans ce dépôt, nous allons utiliser GitlabCI pour le déploiement dans Kubernetes, le fichier .gitlab-ci.yml ressemble à ceci :

image: traherom/kustomize-dockerbefore_script:
   - printenv
   - kubectl versionstages:
 - deploydeploy test:
   stage: deploy
   before_script:
     - echo $KUBECONFIG
   script:
     - kubectl get all
     - kubectl apply -f i/k8s    only:
     - master

Pour le lancer par vous-même, vous aurez besoin d'un cluster, vous pouvez utiliser Gcloud :

gcloud container clusters create canary --num-nodes 3 --zone europe-west3-b
gcloud compute firewall-rules create incoming-80 --allow tcp:80

Vous devez faire un fork https://gitlab.com/wuestkamp/k8s-deployment-example-canary-infrastructure et créer une variable KUBECONFIG dans GitlabCI, qui contiendra la configuration d'accès kubectl à votre cluster.

Ici Vous pouvez lire comment obtenir des informations d'identification pour le cluster (Gcloud).

Yaml d'infrastructure

À l'intérieur du dépôt d'infrastructure, nous avons un service :

apiVersion: v1
kind: Service
metadata:
 labels:
   id: rollout-canary
 name: app
spec:
 ports:
 - port: 80
   protocol: TCP
   targetPort: 5000
 selector:
   id: app
 type: LoadBalancer

et rollout.yaml :

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
 name: rollout-canary
spec:
 replicas: 10
 revisionHistoryLimit: 2
 selector:
   matchLabels:
     id: rollout-canary
 template:
   metadata:
     labels:
       id: rollout-canary
   spec:
     containers:
     - name: rollouts-demo
       image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v1
       imagePullPolicy: Always
 strategy:
   canary:
     steps:
     - setWeight: 10
     # Les déploiements peuvent être repris manuellement en exécutant `kubectl argo rollouts promote ROLLOUT`
     - pause: {}
     - setWeight: 50
     - pause: { duration: 120 } # deux minutes

Rollout fonctionne de la même manière que Deployment. Si nous ne spécifions pas de stratégie de mise à jour (comme canary ici), il se comportera comme un déploiement de mise à jour continue par défaut.

Nous définissons deux étapes dans le yaml pour le déploiement canary :

10 % du trafic sur canary (attendre l'OK manuel)
50 % du trafic sur canary (attendre 2 minutes puis continuer jusqu'à 100 %)

Exécution du déploiement initial

Après le déploiement initial, nos ressources ressembleront à ceci :

Et nous obtenons une réponse uniquement de la première version de l'application :

Exécuter le déploiement canary

Étape 1 : 10 % du trafic

Pour commencer le déploiement canary, il nous suffit de changer la version de l'image, comme nous le faisons habituellement avec les déploiements :

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
 name: rollout-canary
spec:
...
 template:
   metadata:
     labels:
       id: rollout-canary
   spec:
     containers:
     - name: rollouts-demo
       image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v2
...

Et nous poussons les modifications, donc Gitlab CI effectue le déploiement et nous voyons les changements :

Maintenant, si nous accédons au service :

Super ! Nous sommes en plein milieu de notre déploiement canary. Nous pouvons voir les progrès en exécutant :

kubectl argo rollouts get rollout rollout-canary

Étape 2 : 50 % du trafic :

Passons maintenant à l'étape suivante : rediriger 50 % du trafic. Nous avons configuré cette étape pour qu'elle soit lancée manuellement :

kubectl argo rollouts promote rollout-canary # passer à l'étape 2

Et notre application a renvoyé 50 % de réponses des nouvelles versions :

Et un aperçu du déploiement :

Parfait.

Étape 3 : 100 % du trafic :

Nous avons configuré pour qu'après 2 minutes, l'étape avec 50 % se termine automatiquement et lance l'étape avec 100 % :

Et la sortie de l'application :

Et un aperçu du déploiement :

Le déploiement Canary est terminé.

Encore des exemples avec Argo Rollouts

Voici encore des exemples, comme comment configurer un aperçu de l'environnement et des comparaisons basées sur le canary :

https://github.com/argoproj/argo-rollouts/tree/master/examples

Vidéo sur Argo Rollouts et Argo CI

Je recommande vraiment cette vidéo, elle montre comment Argo Rollouts et Argo CI fonctionnent ensemble :

Conclusion

J'aime beaucoup l'idée d'utiliser des CRDs qui gèrent la création de types de déploiements supplémentaires ou de replicasets, redirigent le trafic, etc. Travailler avec eux se fait en douceur. Ensuite, je voudrais tester l'intégration avec Argo CI.

Cependant, apparemment, une grande fusion entre Argo CI et Flux CI est à venir, donc je pourrais attendre la sortie de la nouvelle version : Argo Flux.

Avez-vous eu de l'expérience avec Argo Rollouts ou Argo CI ?

Lisez aussi d'autres articles sur notre blog :

Source : habr.com