Déploiements progressifs avec ArgoCD et Argo Rollouts (canary, blue-green)

Le rolling update de Kubernetes remplace vos pods sans jamais mesurer si la nouvelle version tient la route. Le déploiement progressif corrige ça : il n'envoie la nouvelle version qu'à une fraction du trafic, observe, puis étend, avec un retour arrière automatique si ça se dégrade. Ce guide met en place un canary avec Argo Rollouts, piloté en GitOps par ArgoCD, avec des sorties réelles capturées sur un cluster k3d (Argo Rollouts v1.9.0). Public : personnes qui exploitent ArgoCD et veulent des déploiements sûrs. Prérequis : ArgoCD installé et une première application.

Ce que vous allez apprendre

Distinguer rolling update, canary et blue-green
Installer Argo Rollouts et comprendre son lien avec ArgoCD
Écrire un Rollout avec une stratégie canary par paliers
Observer un canary en cours (deux versions en parallèle)
Automatiser la promotion ou l'annulation avec l'analyse de métriques

Rolling update, canary, blue-green

Le Deployment Kubernetes ne connaît qu'une stratégie utile : le rolling update. Il remplace les pods par lots, sans jamais se demander si la nouvelle version fonctionne. S'il y a un bug, il déploie le bug à 100 %, vite.

Stratégie	Comment	Ce qu'elle apporte
Rolling update	Remplace les pods progressivement	Rien de plus : aucune mesure, aucun garde-fou
Canary	Envoie X % du trafic à la nouvelle version, puis étend	Détecte un problème sur une fraction des utilisateurs
Blue-green	Déploie la v2 à côté (green), bascule tout le trafic d'un coup	Bascule et retour arrière instantanés

Le canary limite le rayon de souffle (peu d'utilisateurs touchés si ça casse). Le blue-green privilégie la bascule nette et le rollback immédiat, au prix du double des ressources le temps de la bascule.

Argo Rollouts : le complément d'ArgoCD

ArgoCD sait déployer, pas orchestrer un canary. C'est le rôle d'Argo Rollouts, un projet distinct de la même famille Argo. Il ajoute un objet Rollout qui remplace le Deployment et prend en charge canary et blue-green.

La répartition des rôles est nette :

ArgoCD synchronise le manifeste Rollout depuis Git (le GitOps habituel).
Argo Rollouts exécute la stratégie progressive une fois le Rollout déployé.

Les deux se complètent sans se marcher dessus. ArgoCD sait d'ailleurs évaluer la santé d'un Rollout nativement, donc la vue arbre d'ArgoCD reflète l'état de la progression.

L'installation se fait dans son propre namespace :

kubectl create namespace argo-rollouts
kubectl apply -n argo-rollouts \
  -f https://github.com/argoproj/argo-rollouts/releases/download/v1.9.0/install.yaml

Le plugin kubectl argo rollouts (binaire à part) offre une vue lisible de la progression, indispensable pour piloter et diagnostiquer.

Écrire un Rollout canary

Un Rollout ressemble à un Deployment, avec un bloc strategy.canary qui décrit les paliers. Ici, on monte le trafic par étapes de 25 %, avec une pause à chaque palier :

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: demo-canary
spec:
  replicas: 4
  strategy:
    canary:
      steps:
        - setWeight: 25
        - pause: { duration: 30s }
        - setWeight: 50
        - pause: { duration: 30s }
        - setWeight: 75
        - pause: { duration: 30s }
  selector:
    matchLabels: { app: demo-canary }
  template:
    # ... identique à un Deployment (metadata + spec du pod)

Chaque setWeight fixe la part de trafic dirigée vers la nouvelle version ; chaque pause laisse le temps d'observer. Une pause sans duration attend une promotion manuelle (kubectl argo rollouts promote demo-canary), utile pour un point de contrôle humain.

Observer un canary en cours

C'est là que le déploiement progressif prend tout son sens. Après avoir changé l'image (kubectl argo rollouts set image demo-canary demo=...:blue), le canary démarre. Voici l'état réel au premier palier :

Name:            demo-canary
Status:          ॥ Paused
Message:         CanaryPauseStep
Strategy:        Canary
  Step:          1/6
  SetWeight:     25
  ActualWeight:  25
Images:          argoproj/rollouts-demo:blue (canary)
                 argoproj/rollouts-demo:yellow (stable)

NAME                                KIND        STATUS     INFO
⟳ demo-canary                       Rollout     ॥ Paused
├──# revision:2
│  └──⧉ demo-canary-849cb776b9      ReplicaSet  ✔ Healthy  canary
│     └──□ ...-658xc                Pod         ✔ Running  ready:1/1
└──# revision:1
   └──⧉ demo-canary-dcf768bc7       ReplicaSet  ✔ Healthy  stable
      ├──□ ...-pm9qn                Pod         ✔ Running  ready:1/1
      ├──□ ...-xcvfr                Pod         ✔ Running  ready:1/1
      └──□ ...-xt8w9                Pod         ✔ Running  ready:1/1

Tout est là : deux versions cohabitent (blue canary, yellow stable), le trafic est à 25 % (ActualWeight), et la répartition des pods suit (1 canary, 3 stables). Le Rollout est en pause sur le premier palier ; il reprendra après la duration, ou attend votre feu vert.

Automatiser la décision avec l'analyse

Pauser puis promouvoir à la main ne passe pas à l'échelle. Argo Rollouts sait décider tout seul grâce à l'AnalysisTemplate : à chaque palier, il interroge une source de métriques (Prometheus, Datadog...) et promeut si la métrique est bonne, annule sinon.

strategy:
  canary:
    steps:
      - setWeight: 25
      - analysis:
          templates:
            - templateName: taux-erreur
    # promotion auto si le taux d'erreur reste sous le seuil, abort sinon

L'AnalysisTemplate définit la requête (par exemple, un taux d'erreur HTTP 5xx sous 1 %) et le seuil d'échec. C'est le vrai intérêt du déploiement progressif : un rollback automatique sur métrique, sans intervention humaine, avant que la panne ne se généralise. Reliez-le à votre supervision Prometheus.

Blue-green en bref

La stratégie blue-green déploie la nouvelle version en parallèle sans lui donner de trafic, puis bascule le Service d'un coup :

strategy:
  blueGreen:
    activeService: demo-active       # le Service qui reçoit le trafic
    previewService: demo-preview     # un Service pour tester la green avant bascule
    autoPromotionEnabled: false      # bascule sur validation manuelle

On teste la version green via previewService, puis on promeut. Le retour arrière consiste à rebasculer le Service vers l'ancienne version, toujours présente. Le coût : deux fois les ressources le temps de la coexistence.

Dépannage

Symptôme	Cause probable	Solution
Le `Rollout` reste `Degraded`	Image ou sonde en échec sur le canary	Inspecter les pods de la revision canary
Canary bloqué en `Paused`	`pause` sans `duration`	Promouvoir manuellement (`promote`) ou ajouter une durée
Le trafic ne se répartit pas	Pas de contrôleur de trafic (ingress/mesh)	Sans mesh, la répartition suit le nombre de pods ; pour un vrai poids, brancher un provider (NGINX, Istio)
ArgoCD voit le Rollout `OutOfSync` en boucle	Champs mutés par le contrôleur Rollouts	Ajouter les champs concernés en `ignoreDifferences`

À retenir

Le rolling update ne mesure rien : un bug part à 100 %. Le déploiement progressif limite le rayon de souffle.
Argo Rollouts est un projet distinct d'ArgoCD : il apporte l'objet Rollout (qui remplace le Deployment) et les stratégies canary et blue-green.
ArgoCD déploie le Rollout en GitOps, Argo Rollouts orchestre la progression. Les deux se complètent.
Un canary avance par paliers (setWeight + pause) ; on suit l'état avec kubectl argo rollouts get rollout.
promote avance, abort revient à la version stable instantanément (elle est toujours là).
L'AnalysisTemplate automatise la décision sur métriques : promotion ou rollback sans humain.

Pour aller plus loin

Superviser ArgoCD : les métriques Prometheus qui alimentent l'analyse automatique du canary.
Rollback et reprise : revenir en arrière quand le déploiement progressif n'a pas suffi.