TP23 : Progressive Delivery (Argo Rollouts, Blue/Green, Canary, analyse, Feature Flags)
Un Deployment Kubernetes remplace les Pods progressivement, mais il ne sait pas juger la nouvelle version : si elle renvoie 30 % d’erreurs tout en passant ses probes, le rolling update va jusqu’au bout. La livraison progressive expose la nouvelle version à une petite partie du trafic, mesure son comportement et décide automatiquement de poursuivre ou d’annuler. Ce TP met en œuvre Argo Rollouts (Blue/Green, Canary, analyse Prometheus et rollback automatique), puis sépare le déploiement du code de l’activation d’une fonctionnalité grâce aux Feature Flags (OpenFeature + flagd).
Fichiers de départ :
feature-app.zip,rollouts.zip
1. Objectifs pédagogiques
À l’issue du TP, vous serez capable de :
- comparer rolling update, Blue/Green et Canary (risque, coût, retour arrière) ;
- remplacer un
Deploymentpar unRolloutet piloter une mise en production (promote,abort,undo) ; - définir des paliers de canary et une AnalysisTemplate fondée sur une requête PromQL ;
- obtenir un rollback automatique quand le taux d’erreur dépasse un seuil ;
- activer une fonctionnalité sans redéployer avec OpenFeature et flagd, et cibler des utilisateurs.
Les images de cette page sont des schémas explicatifs, pas des captures d’écran.
2. Environnement du TP
-
Le cluster K3s avec la pile d’observabilité du TP21 (Prometheus de la release
kps) et l’imageobservability-democonstruite dans ce TP. -
Installer Argo Rollouts et son plugin
kubectl:kubectl create namespace argo-rollouts kubectl apply -n argo-rollouts -f https://github.com/argoproj/argo-rollouts/releases/latest/download/install.yaml curl -LO https://github.com/argoproj/argo-rollouts/releases/latest/download/kubectl-argo-rollouts-linux-amd64 sudo install -m 0755 kubectl-argo-rollouts-linux-amd64 /usr/local/bin/kubectl-argo-rollouts kubectl argo rollouts version -
Ouvrir le tableau de bord (facultatif) :
kubectl argo rollouts dashboardpuishttp://localhost:3100.
| Stratégie | Principe | Retour arrière | Coût |
|---|---|---|---|
| Rolling update | Remplacement progressif des Pods (Deployment) | lent | faible |
| Blue/Green | Deux versions complètes ; bascule du Service en une fois | instantané | ×2 ressources |
| Canary | Petite part du trafic vers la nouvelle version, puis augmentation | rapide | faible |
3. Partie 1 : Préparation
-
Remplacer
TODO-registrepar votre image dans les manifests derollouts/, puis appliquer le namespace, les Services et le ServiceMonitor :kubectl apply -f rollouts/00-namespace-svc.yaml -
Lancer un générateur de trafic permanent (laissez-le tourner pendant tout le TP) :
kubectl -n tp23 run load --image=busybox:1.37 --restart=Never -- sh -c \ 'while true; do wget -qO- http://demo-active/api/orders >/dev/null 2>&1; sleep 0.1; done'
4. Partie 2 : Blue/Green
-
Compléter
10-rollout-bluegreen.yaml(scaleDownDelaySeconds: 60), appliquer, puis suivre le Rollout :kubectl apply -f rollouts/10-rollout-bluegreen.yaml kubectl argo rollouts get rollout demo -n tp23 --watch -
Déployer la version « green » :
kubectl argo rollouts set env rollout/demo -n tp23 APP_VERSION=green(ou modifier le manifest). Observer : les Pods green démarrent,demo-previewles cible,demo-activereste sur blue. -
Tester la preview (
kubectl -n tp23 port-forward svc/demo-preview 8081:80), puis promouvoir :kubectl argo rollouts promote demo -n tp23 -
Revenir instantanément en arrière :
kubectl argo rollouts undo demo -n tp23. Pourquoi le retour est-il immédiat pendant 60 s ?
5. Partie 3 : Canary
-
Supprimer le Rollout Blue/Green, compléter
30-rollout-canary.yaml.example(paliers 10, 25, 50, 100 %) et l’appliquer sous le nom30-rollout-canary.yaml. -
Déclencher une nouvelle version saine (
APP_VERSION=v2) et observer la progression palier par palier, le nombre de Pods canary et stables :kubectl argo rollouts get rollout demo -n tp23 --watch -
Pendant une pause, interrompre manuellement (
kubectl argo rollouts abort demo -n tp23) : que devient le trafic ? Relancer aveckubectl argo rollouts retry rollout demo -n tp23.Sans routeur de trafic, le pourcentage est approché par le nombre de Pods (10 replicas : 1 Pod = 10 %). Avec un Ingress ou un service mesh, Argo Rollouts règle des poids exacts sans modifier le nombre de Pods (défi).
6. Partie 4 : Analyse automatique et rollback
- Compléter
20-analysis-template.yaml(successCondition: result[0] < 0.05), l’appliquer et activer l’analyse en arrière-plan dans le canary (analysis.templates,startingStep: 1). - Tester la requête PromQL dans Prometheus avant de lui confier une décision.
- Déployer une version défaillante :
APP_VERSION=v3etERROR_RATE=0.5. Observer :- l’
AnalysisRunqui échoue (kubectl -n tp23 get analysisrun,kubectl argo rollouts get rollout demo -n tp23) ; - le rollback automatique vers la version stable et l’état
Degradeddu Rollout ; - la courbe du taux d’erreur dans Grafana : combien de requêtes ont été affectées ?
- l’
- Comparer avec ce qui se serait passé avec un
Deploymentclassique.
7. Partie 5 : Feature Flags avec OpenFeature
-
Compléter les
TODOdefeature-app/server.js(provider flagd, évaluation du flagnew-checkout), puis démarrer flagd et l’application :cd feature-app && docker compose up -d curl -s localhost:3001/?user=alice -
Activer la fonctionnalité pour tout le monde en changeant
defaultVariantenondansflags.json: flagd recharge le fichier, l’application n’est pas redémarrée. -
Remettre
offpar défaut et activer la fonctionnalité uniquement pouralicegrâce à une règletargeting("if": [{ "==": [{ "var": "targetingKey" }, "alice"] }, "on", "off"]). -
Activer la fonctionnalité pour 20 % des utilisateurs avec l’opérateur
fractional, et vérifier qu’un même utilisateur obtient toujours la même réponse. -
Expliquer la différence entre déploiement (technique, géré par Argo Rollouts) et release (fonctionnelle, gérée par les flags). Quelle dette technique les flags créent-ils, et comment l’éviter ?
Défi
- Faire piloter des poids exacts au routeur Traefik de K3s par Argo Rollouts (
trafficRouting.traefikavec unTraefikServicepondéré), et vérifier la répartition aveccurlen boucle.- Déployer flagd dans Kubernetes avec ses flags dans une ConfigMap gérée en GitOps (TP19) : activer une fonctionnalité devient une Pull Request.
8. Livrables
Captures à déposer dans captures/ :
| Fichier | Contenu attendu |
|---|---|
bluegreen-preview.png |
Rollout en pause : preview sur green, active sur blue |
bluegreen-undo.png |
Retour arrière instantané |
canary-steps.png |
Progression du canary palier par palier |
analysis-failed.png |
AnalysisRun en échec et rollback automatique |
grafana-error-rate.png |
Pic du taux d’erreur limité dans le temps |
flags-targeting.png |
Réponses différentes pour alice et pour les autres utilisateurs |
Ainsi que les manifests complétés, server.js et flags.json.