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 Deployment par un Rollout et 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’image observability-demo construite 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 dashboard puis http://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-registre par votre image dans les manifests de rollouts/, 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-preview les cible, demo-active reste 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

Canary par paliers avec analyse Prometheus et rollback automatique Canary par paliers avec analyse Prometheus et rollback automatique

  • Supprimer le Rollout Blue/Green, compléter 30-rollout-canary.yaml.example (paliers 10, 25, 50, 100 %) et l’appliquer sous le nom 30-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 avec kubectl 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=v3 et ERROR_RATE=0.5. Observer :
    • l’AnalysisRun qui échoue (kubectl -n tp23 get analysisrun, kubectl argo rollouts get rollout demo -n tp23) ;
    • le rollback automatique vers la version stable et l’état Degraded du Rollout ;
    • la courbe du taux d’erreur dans Grafana : combien de requêtes ont été affectées ?
  • Comparer avec ce qui se serait passé avec un Deployment classique.

7. Partie 5 : Feature Flags avec OpenFeature

Déployer n’est pas activer : le flag pilote la fonctionnalité sans redéploiement Déployer n’est pas activer : le flag pilote la fonctionnalité sans redéploiement

  • Compléter les TODO de feature-app/server.js (provider flagd, évaluation du flag new-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 defaultVariant en on dans flags.json : flagd recharge le fichier, l’application n’est pas redémarrée.

  • Remettre off par défaut et activer la fonctionnalité uniquement pour alice grâce à une règle targeting ("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

  1. Faire piloter des poids exacts au routeur Traefik de K3s par Argo Rollouts (trafficRouting.traefik avec un TraefikService pondéré), et vérifier la répartition avec curl en boucle.
  2. 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.