Un canary qui passe tous ses tests sur le cluster eu-west ne dit rien sur ce qui va se passer sur us-east : latence réseau différente vers les dépendances externes, charge différente, parfois une version de Kubernetes différente de quelques mineures. Traiter un rollout multi-cluster comme un rollout mono-cluster répété plusieurs fois, en parallèle, revient à supprimer exactement le garde-fou que le canary était censé apporter.

Le rollout séquentiel entre clusters, pas seulement entre pods

Un rolling deployment classique séquence le remplacement des pods à l’intérieur d’un cluster. À l’échelle multi-cluster, la même logique s’applique un niveau au-dessus : déployer d’abord sur un cluster à faible impact (trafic interne, région à faible volume), observer, puis étendre progressivement aux clusters suivants par vagues, jamais tous en même temps. Le mécanisme de génération repose sur le même ApplicationSet que celui détaillé dans l’article sur le GitOps à l’échelle ; ici, c’est l’ordre de propagation entre vagues qui compte, pas la génération elle-même.

# ArgoCD ApplicationSet : rollout par vagues via un générateur de liste
# combiné à une stratégie de rollout progressif
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: payment-api
spec:
  generators:
    - list:
        elements:
          - cluster: canary-eu-west
            wave: "1"
          - cluster: prod-eu-west
            wave: "2"
          - cluster: prod-us-east
            wave: "3"
          - cluster: prod-ap-south
            wave: "3"
  template:
    metadata:
      annotations:
        argocd.argoproj.io/sync-wave: "{{wave}}"
    spec:
      destination:
        server: "{{cluster}}"

Les clusters de la même vague se déploient en parallèle entre eux ; une vague n’avance vers la suivante que si celle qui précède est saine. Cette structure transforme une checklist manuelle (« a-t-on vérifié eu-west avant de toucher us-east ? ») en contrainte du système de déploiement lui-même.

Ce qui décide qu’une vague est saine

Une vague qui avance automatiquement sans critère de santé explicite n’est qu’un rollout parallèle déguisé. Le critère doit être mesurable et automatisé, typiquement un taux d’erreur ou une latence percentile comparés à une fenêtre de référence, pas une simple présence de pods Ready :

# Analyse Argo Rollouts, référencée par chaque vague avant promotion
apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: error-rate-check
spec:
  metrics:
    - name: error-rate
      interval: 2m
      successCondition: result[0] < 0.01
      provider:
        prometheus:
          address: http://prometheus.monitoring:9090
          query: |
            sum(rate(http_requests_total{status=~"5..",cluster="{{args.cluster}}"}[5m]))
            / sum(rate(http_requests_total{cluster="{{args.cluster}}"}[5m]))

Sans ce garde-fou automatisé, la vitesse de propagation entre clusters devient le seul levier de sécurité disponible : ralentir manuellement en espérant repérer un problème à l’œil, ce qui ne tient pas à l’échelle d’une organisation avec plus de deux ou trois clusters.

Le rollback qui suit la même topologie

Un rollback multi-cluster mal pensé revient en arrière partout à la fois, ce qui annule le seul avantage du déploiement par vagues : limiter le rayon d’impact. La règle symétrique au rollout par vagues s’applique au rollback : revenir en arrière uniquement sur les clusters où l’analyse a échoué, laisser les clusters déjà validés en place. Un pipeline qui ne distingue pas ce cas traite chaque anomalie comme un incident global, même quand un seul cluster sur cinq est concerné.

Ce que la latence réseau change à l’analyse

Un même seuil d’erreur appliqué uniformément à tous les clusters ignore une réalité opérationnelle : un cluster distant d’une dépendance externe critique (une base de données centralisée, par exemple) a structurellement une latence plus élevée que le cluster où elle est hébergée. Fixer un seuil unique pour tous force soit un seuil trop lâche pour le cluster proche, soit un seuil trop strict qui déclenche des rollbacks intempestifs sur le cluster distant. Le seuil doit être calibré par cluster, contre sa propre fenêtre de référence historique, pas contre une valeur globale unique.

À retenir

Un canary multi-cluster n’est une garantie que si le rollout progresse par vagues mesurées, avec un critère de santé automatisé et calibré par cluster, jamais en parallèle sur toute la flotte. Le rollback doit suivre la même granularité que le rollout : cibler les clusters en échec, laisser les autres en l’état. C’est la même discipline que le déploiement progressif depuis la CI, étendue au niveau où elle protège réellement une infrastructure répartie sur plusieurs régions.