Argo Rollouts : canary et blue-green natifs sur Kubernetes

Votre Deployment Kubernetes part en rolling update, remplace les Pods un par un, et trente secondes plus tard les 5xx grimpent. Le temps que vous compreniez, la nouvelle version tourne partout. Vous rollbackez à la main, en sueur. Le rolling update natif fait ça : il déroule, sans regarder si ça casse. C'est tout ce qu'il sait faire.

L'objet Deployment n'expose qu'une stratégie utile : RollingUpdate. Il monte les nouveaux Pods, descend les anciens, selon maxSurge et maxUnavailable. Aucune notion de pourcentage de trafic contrôlé, aucune pause conditionnée à une métrique, aucun rollback automatique sur dérive d'un indicateur. Le Deployment déroule à l'aveugle et considère le job fait dès que les Pods sont Ready. Or Ready ne dit rien du taux d'erreur applicatif.

Sur un déploiement à risque, ça ne tient pas. On veut envoyer 10 % du trafic sur la nouvelle version, regarder les SLO pendant cinq minutes, et continuer seulement si le taux de succès tient. Le Deployment ne sait pas faire. Si vous débutez sur l'orchestrateur, notre introduction aux concepts Kubernetes pose les bases avant d'attaquer la suite.

Argo Rollouts est un contrôleur Kubernetes accompagné d'un jeu de Custom Resource Definitions. La pièce centrale, le CRD Rollout, remplace le Deployment. Sa spec reprend celle du Deployment (selector, template, replicas), et ajoute un bloc strategy qui change tout. On migre un Deployment existant en changeant le kind et en déclarant la stratégie. Le reste du manifeste bouge à peine.

Deux stratégies au menu : canary et blueGreen. Le contrôleur pilote les ReplicaSets, le routage du trafic et l'analyse des métriques pour décider d'avancer ou d'avorter.

La stratégie canary déroule la nouvelle version par incréments. On enchaîne des steps : setWeight fixe le pourcentage de trafic envoyé sur le canary, pause arrête la progression. Si pause porte un duration, le contrôleur attend ce délai puis continue. Sans duration, il attend indéfiniment jusqu'à promotion manuelle. C'est le garde-fou : on inspecte, puis on décide.

strategy:
  canary:
    steps:
      - setWeight: 20
      - pause: { duration: 5m }
      - setWeight: 50
      - pause: {}
      - setWeight: 100

Ici, 20 % du trafic pendant cinq minutes, puis 50 % avec une pause indéfinie (validation humaine), puis bascule complète. Chaque palier est une fenêtre d'observation. Si ça part en vrille à 20 %, l'impact reste borné à un cinquième des utilisateurs.

La stratégie blueGreen garde deux versions en parallèle. La version stable sert le activeService. La nouvelle version est exposée via un previewService, sur lequel on valide hors trafic de production. Quand le feu est vert, le contrôleur bascule l'activeService vers la nouvelle version d'un coup. Le rollback est immédiat : on repointe sur l'ancien ReplicaSet, qui tourne toujours.

Le blue-green coûte plus cher en ressources, deux versions complètes en même temps, mais offre un basculement et un retour arrière instantanés. À réserver aux cas où la latence de rollback prime sur le coût d'infra.

Découper le trafic à 20 % suppose une couche capable de le faire. Argo Rollouts ne route pas lui-même : il pilote un fournisseur de trafic. L'ingress NGINX gère le poids via des annotations sur l'Ingress. Un service mesh comme Istio découpe finement au niveau du VirtualService. L'abstraction SMI (Service Mesh Interface) couvre les meshes compatibles, et le contrôleur supporte aussi des cibles cloud comme l'AWS ALB.

Le choix du routeur n'est pas neutre. Sans mesh ni ingress capable de pondérer, le canary se réduit à un découpage approximatif au prorata des Pods. Avec Istio, on obtient un contrôle au pourcentage près. On a détaillé cette mécanique côté mesh dans notre guide du canary avec Istio.

C'est là que Rollouts devient sérieux. L'AnalysisTemplate (à portée namespace) ou le ClusterAnalysisTemplate (à portée cluster) décrit des requêtes vers un fournisseur de métriques : Prometheus, Datadog, CloudWatch. Pendant le rollout, ces requêtes tournent et le contrôleur interprète les résultats pour promouvoir ou avorter automatiquement.

Concrètement, on insère un step analysis dans la stratégie canary, qui lance un AnalysisRun sur le template. Un template type interroge Prometheus sur le taux de succès HTTP, par échantillons de cinq minutes. Chaque métrique fixe son interval, son count, et ses limites : failureLimit, inconclusiveLimit, consecutiveErrorLimit.

metrics:
  - name: success-rate
    interval: 5m
    failureLimit: 3
    provider:
      prometheus:
        address: http://prometheus.monitoring:9090
        query: |
          sum(rate(http_requests_total{status!~"5.."}[5m]))
          / sum(rate(http_requests_total[5m]))

Si l'analyse échoue, le Rollout passe en état aborted : le poids du canary retombe à zéro et le Rollout est marqué Degraded. En blue-green, si l'analyse post-promotion échoue, le trafic revient sur le ReplicaSet stable précédent. Le rollback se déclenche sur une dérive de SLO, sans humain. C'est la différence entre un déploiement piloté par le temps et un déploiement piloté par la donnée. Pour bâtir des SLO qui veulent dire quelque chose, nos métriques DORA cadrent les indicateurs qui comptent vraiment.

Au-delà de l'analyse, Rollouts propose les experiments : faire tourner une ou plusieurs versions éphémères en parallèle, le temps d'une analyse, pour comparer avant d'engager un vrai rollout. Utile pour un A/B technique sur deux implémentations.

Les deux font de la progressive delivery, l'approche diffère sur un point structurant. Argo Rollouts remplace le Deployment par son CRD Rollout. Flagger garde le Deployment standard et ajoute un CRD Canary autour. Flagger touche donc moins aux manifestes existants. Rollouts donne un contrôle plus fin et un plugin d'interface dédié.

La règle qu'on applique : les équipes sous Argo CD prennent Rollouts, celles sous Flux CD prennent Flagger. Ce n'est pas qu'une question de goût, c'est l'alignement de l'outillage. Flagger pousse l'automatisation totale, zéro intervention par release. Rollouts mise sur le contrôle explicite et la visibilité. Sur un déploiement à risque, on préfère voir et décider à chaque palier. Si vous êtes côté Flux, notre guide GitOps avec Flux CD trace l'autre branche.

Rollouts et Argo CD forment un duo naturel. Argo CD synchronise l'état déclaré dans Git vers le cluster, Rollouts gère la stratégie de déploiement progressif de chaque application. Le CRD Rollout est un manifeste comme un autre : il vit dans Git, Argo CD le réconcilie. On garde la traçabilité GitOps tout en pilotant des canary et des blue-green analysés. Pour le socle GitOps qui porte le tout, voir notre guide Argo CD.

Pour tout déploiement à risque ou piloté par SLO, Argo Rollouts s'impose. Le rolling update natif suffit pour un service interne sans enjeu : on déroule, si ça casse on s'en aperçoit aux logs. Mais dès qu'il y a du trafic réel et des SLO à tenir, le canary analysé change la donne : impact borné par palier, promotion ou rollback automatique sur métrique Prometheus, retour arrière instantané en blue-green.

Le coût existe : un CRD de plus, une couche de routage à maîtriser, des AnalysisTemplate à écrire et à tenir. Sur une infra qu'on opère, ce coût se rembourse au premier déploiement raté qui se rollback tout seul à 3 h du matin sans réveiller personne.

• Argo Rollouts | Documentation officielle : référence du contrôleur, CRD Rollout, stratégies canary et blue-green.
• Canary | Argo Rollouts : steps setWeight, pause et comportement de progression.
• Analysis | Argo Rollouts : AnalysisTemplate, AnalysisRun, providers et limites de métriques.
• argoproj/argo-rollouts | GitHub : code source, fournisseurs de trafic et de métriques supportés.