Progressive Delivery avec Argo Rollouts

Le Rolling Update natif de Kubernetes remplace les pods un par un. Pas de contrôle sur le pourcentage de trafic, pas d’analyse de métriques, pas de rollback automatique. Pour de la vraie production, il faut du Progressive Delivery — et c’est exactement ce qu’Argo Rollouts apporte.

Pourquoi le Deployment natif ne suffit pas

Le Deployment Kubernetes fait du rolling update : il crée de nouveaux pods et détruit les anciens progressivement. Ça fonctionne, mais avec des limites critiques en production.

Pas de split de trafic — tu ne peux pas envoyer 5% du trafic vers la nouvelle version pour tester. Pas d’analyse automatique — si le taux d’erreur explose, personne ne rollback tout seul. Et pas de Blue/Green propre — impossible de maintenir deux versions actives avec un switch instantané.

🔥 Argo Rollouts remplace le Deployment par un CRD Rollout qui supporte Blue/Green, Canary, et Progressive Delivery avec analyse automatique. Il s’intègre nativement avec ArgoCD.

# Installation d'Argo Rollouts
kubectl create namespace argo-rollouts
kubectl apply -n argo-rollouts \
  -f https://github.com/argoproj/argo-rollouts/releases/latest/download/install.yaml

# Plugin kubectl (indispensable pour le suivi)
curl -LO https://github.com/argoproj/argo-rollouts/releases/latest/download/kubectl-argo-rollouts-linux-amd64
chmod +x kubectl-argo-rollouts-linux-amd64
sudo mv kubectl-argo-rollouts-linux-amd64 /usr/local/bin/kubectl-argo-rollouts

# Dashboard web (optionnel mais pratique)
kubectl argo rollouts dashboard &
# → http://localhost:3100

Blue/Green : switch instantané entre deux versions

Le principe : deux ReplicaSets coexistent. Le service active pointe vers la version stable, le service preview vers la nouvelle. Tu testes la preview, puis tu switch le trafic d’un coup.

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: myapp
spec:
  replicas: 3
  revisionHistoryLimit: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
        - name: myapp
          image: ghcr.io/org/myapp:1.3.0
          ports:
            - containerPort: 8080
          readinessProbe:
            httpGet:
              path: /healthz
              port: 8080
  strategy:
    blueGreen:
      activeService: myapp-active
      previewService: myapp-preview
      autoPromotionEnabled: false
      prePromotionAnalysis:
        templates:
          - templateName: smoke-tests
      scaleDownDelaySeconds: 30

💡 autoPromotionEnabled: false est la clé — ça force la validation manuelle avant de basculer le trafic. En staging tu peux mettre true, en prod c’est false obligatoire.

Le workflow : tu push une nouvelle image → ArgoCD sync → Argo Rollouts crée les pods preview → prePromotionAnalysis lance les smoke tests → si OK, tu promeus manuellement → le service active bascule → l’ancien ReplicaSet est gardé 30 secondes (rollback rapide).

# Promouvoir la preview en active
kubectl argo rollouts promote myapp

# Annuler un rollout en cours
kubectl argo rollouts abort myapp

# Suivre la progression en temps réel
kubectl argo rollouts get rollout myapp --watch

Canary : montée progressive du trafic

Le canary envoie un pourcentage croissant de trafic vers la nouvelle version. Entre chaque palier, une pause et/ou une analyse automatique valident que tout va bien.

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: myapp
spec:
  replicas: 5
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
        - name: myapp
          image: ghcr.io/org/myapp:1.3.0
          ports:
            - containerPort: 8080
  strategy:
    canary:
      canaryService: myapp-canary
      stableService: myapp-stable
      trafficRouting:
        nginx:
          stableIngress: myapp-ingress
      steps:
        - setWeight: 5
        - pause: { duration: 5m }
        - analysis:
            templates:
              - templateName: error-rate-check
        - setWeight: 20
        - pause: { duration: 10m }
        - analysis:
            templates:
              - templateName: error-rate-check
              - templateName: latency-check
        - setWeight: 50
        - pause: { duration: 10m }
        - setWeight: 100

Chaque setWeight ajuste le pourcentage de trafic. Chaque pause donne le temps d’observer. Chaque analysis lance un AnalysisRun qui query Prometheus et décide : continuer ou rollback.

⚠️ Sans trafficRouting, Argo Rollouts fait du canary basé sur les replicas (1 pod canary sur 5 = ~20%). Avec trafficRouting (NGINX, Istio, AWS ALB), tu contrôles le pourcentage exact de trafic — c’est nettement plus précis.

AnalysisTemplate : le rollback automatique

C’est le cerveau du Progressive Delivery. Tu définis des requêtes Prometheus qui s’exécutent pendant le canary. Si les métriques dépassent les seuils, Argo Rollouts rollback automatiquement.

apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: error-rate-check
spec:
  args:
    - name: service-name
      value: myapp-canary
  metrics:
    - name: error-rate
      interval: 60s
      count: 5
      successCondition: result[0] < 0.05
      failureCondition: result[0] >= 0.10
      failureLimit: 3
      provider:
        prometheus:
          address: http://prometheus.monitoring:9090
          query: |
            sum(rate(http_requests_total{
              service="{{args.service-name}}",
              status=~"5.."
            }[5m]))
            /
            sum(rate(http_requests_total{
              service="{{args.service-name}}"
            }[5m]))
    - name: latency-p99
      interval: 60s
      count: 5
      successCondition: result[0] < 500
      failureLimit: 3
      provider:
        prometheus:
          address: http://prometheus.monitoring:9090
          query: |
            histogram_quantile(0.99,
              sum(rate(http_request_duration_seconds_bucket{
                service="{{args.service-name}}"
              }[5m])) by (le)
            ) * 1000

🎯 Deux métriques essentielles : le taux d’erreur 5xx (< 5% pour passer) et la latence P99 (< 500ms). Si l’une échoue 3 fois (failureLimit: 3), c’est rollback automatique. Pas besoin d’humain à 3h du matin.

Les providers supportés vont au-delà de Prometheus : Datadog, New Relic, CloudWatch, Kayenta (Google), ou même un simple Job Kubernetes qui retourne un exit code.

Cas entreprise : e-commerce avec canary automatisé

Une plateforme e-commerce avec 50K requêtes/minute déploie un nouveau moteur de recherche. Avant Argo Rollouts, chaque release mobilisait 3 personnes pendant 2 heures pour surveiller les dashboards manuellement.

Leur setup Progressive Delivery :

• Canary 5 étapes : 2% → 10% → 25% → 50% → 100%, avec 10 minutes entre chaque palier
• 3 AnalysisTemplates : taux d’erreur, latence P99, taux de conversion (métrique business via Datadog)
• Header routing activé : les QA testent la version canary via X-Canary: true avant même le split de trafic public

Un déploiement bugué est arrivé : la latence P99 a explosé à 2 secondes au palier 10%. L’AnalysisRun a détecté le dépassement en 3 minutes et déclenché le rollback automatique. Impact : 10% des utilisateurs touchés pendant 3 minutes, contre 100% pendant 30+ minutes avec l’ancien process.

# Suivre un rollout en temps réel
kubectl argo rollouts get rollout myapp --watch

# Voir l'historique des AnalysisRuns
kubectl argo rollouts list analysisruns

# Forcer la promotion (skip analysis)
kubectl argo rollouts promote myapp --full

Pièges classiques et résumé

⚠️ Le canary sans traffic routing — Sans NGINX/Istio configuré, le split de trafic est basé uniquement sur le nombre de pods. Avec 5 replicas et 1 canary, tu es à ~20% de trafic — impossible de descendre à 2%. Active le traffic routing pour un contrôle fin.

⚠️ Les AnalysisTemplates trop strictes — Un failureLimit: 1 avec des métriques volatiles = rollback intempestif. Commence avec failureLimit: 3 et count: 5 pour lisser les faux positifs.

🔥 Intégration ArgoCD — Argo Rollouts s’intègre nativement avec ArgoCD. Dans l’UI ArgoCD, tu vois l’état du Rollout, les steps en cours, et les résultats d’analyse. Assure-toi juste d’installer le plugin ArgoCD pour Rollouts.

💡 Experiments pour l’A/B testing — Au-delà du canary, Argo Rollouts supporte les Experiments : deux versions tournent en parallèle avec des replicas dédiés. Parfait pour comparer les performances entre baseline et canary avant de router du vrai trafic.

Le Progressive Delivery transforme un déploiement en processus contrôlé et observable. Le Blue/Green offre un switch instantané avec rollback en 30 secondes. Le Canary monte progressivement le trafic avec des paliers configurables.

L’AnalysisTemplate est le game changer — elle automatise la décision go/no-go en queryant Prometheus, Datadog, ou n’importe quel provider de métriques. Plus besoin de surveiller des dashboards manuellement.

En production, combine canary + traffic routing (NGINX ou Istio) + AnalysisTemplates sur les métriques critiques (erreurs, latence, métriques business). Le rollback automatique sur seuil te protège 24/7, même à 3h du matin.